Wasn't the 360 assembler before F the Basic Assembler Language - the
origin of the BAL acronym. It was designed so that it could be used on
small machines where memory was at a premium. The scheme of sorting the
literal pool according to size probably originated with it. In the early
360s, the Byte Oriented Operand feature was an extra cost option.
Without it, a program check was the result if you violated the alignment
requirements.

Before that, there was 7080 Autocoder; however, the concept of a word
was somewhat different. IIRC, you could set a register's length (1-256
characters - it was before the word "byte" had been invented) or load
from a beginning address to a "word mark" in memory. Since starting
address and size were arbitrary, there was no alignment requirement
other than that word marks had to be in a 4 or a 9 position. If you
chose to load to a word mark and there was none in memory, the load
instruction would happily keep wrapping the register until the
instruction timed out.

The 7080 was a character machine that did decimal arithmetic. Its
contemporary was the 7094 which was strictly 36-bit word oriented.
Alignment in it was not an option.    

-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Richard Corak
Sent: Wednesday, November 22, 2006 8:23 AM
To: [email protected]
Subject: CMSCALL return code

>If your habit was to use L Rx,=X'...' you were probably lucky in the 
>old days.... the =X literal would not necessarily be word-aligned, 
>causing two fetches to load the register, or, in the days when 
>alignment really mattered... a program exception.

Not true.  Assemblers going back to F (anything before?) have always
ordered literals by alignment.  Any 8-byte-multiple literal will be
aligned on an 8-byte boundary, regardless of how defined.
Then all 4-byte-multiple literals not a multiple of 8, then all
2-byte-multiple not x4 or x8, then all 1-byte-multiple literals.

So, a literal =X'12345678' or =X'12,34,56,78', etc., will be 4-byte
aligned.

Richard Corak 

Reply via email to