| PLEX86 | ||
Little Endian 1329
That's not how it was done on the Burroughs Medium Systems; addressible to the nibble, the lowest addressed nibble was the most significant BCD digit. This, of course, made formatting numeric output quite easy - simply move the requisite number of digits to another array (twice as large) of digits preceding each digit of the input with the digit 0xF. Which since F0-F9 are EBCDIC for '0'-'9', meant you were done. And that this could be done with a single instruction (which could also either pad or fill to the requisite destination length as required based on field length and operand type). Little Endian 1330 A belated entry in the discussion. but absent all the smoke and flames that erupted in the newsgroup The reason for 'little endian' is *simple*. "simplicity" If you're... e.g. SOURCE: .digits 15253 DEST: .space for 15 bytes MVN 0515 SOURCE(UN), DEST(UA) Move Numeric, A Length=5 digits, B Length = 15 bytes result in dest would be " 15253" (in EBCDIC) MVA 0515 SOURCE(UN), DEST(UA) Move Alpha, 5digit source, 15 byte dest would result in "15253 " (in EBCDIC) Moving the other way (from Unsigned Alpha (UA) to Unsigned Numeric (UN)) would strip the EBCDIC 0xF digit leading each byte. Since this was primarily a COBOL engine, it was quite suitable for processing cobol data items in BCD form (e.g. PIC 9999). The instruction set could process BCD strings from one to one hundred digits in length with a single arithmetic three-operand instruction. Instructions that worked on bytes required addresses congruent to zero modulo two, in which case the most significant nibble is the first nibble of the byte. There was no intrinsic data type larger than a byte. scott
|
||||
Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||