From: gardner_c@apollo.hp.com (Cal Gardner)
Subject: Re: The name "BSS" (Was: ASSEMBLY LANGUAGE IBM)
Date: Mon, 23 Nov 1992 04:04:27 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA

In article <jcmorris.722362695@mwunix> jcmorris@mwunix.mitre.org (Joe Morris) writes:
>rst@think.com (Robert Thau) writes:
>
>[in response to what appears to be a request for the net to do someone's 
> class assignment]
>
>>                                                                 I begin
>>with a code fragment for the type 709 electronic data-processing machine
>>(using the FAP assembler):
>
>> [...]
>
>>           However, if we want to use the calling sequence of the library 
>>routines (SINF, COSF, etc. --- we're talking FORTRAN II here, so the 'F' at 
>>the end of the name has semantic content), then the arguments will be in 
>>the AC and MQ, and we may use the following routine:
>
>> MYMIN STQ       SAVEQ
>>       CAS       SAVEQ
>>       XCA
>>       TRA       1,4
>>       TRA       1,4
>> SAVEQ PZE
>
>>Here, the XCA instruction exchanges the contents of the AC and MQ, and the
>>PZE (Plus ZEro) is a dummy operation which assembles a word of zero bits
>>to reserve space.  (I might just as well have punched
>
>> SAVEQ BSS       1
>
>>to reserve a Block (of one word) Starting with the Symbol SAVEQ, but for
>>a block of fewer than 24 words, that would have wasted space in the object 
>>deck.  FAP also supports a BES directive, for Block Ending with Symbol,
>>should you want that).
>
>Which brings up the question: did the symbol "BSS" (as a word to indicate
>a memory area allocated for variable storage in a program) originate with
>FAP?  That's where I first ran into it, and I don't recall having seen it
>in earlier languages.  

     UASAP1&2 had the storage allocation psuedocodes

>
>Incidentally, the BES pseudo-operation (the word "directive" appeared much
>later) was defined on the 704/709/etc systems because of the way the
>index registers worked:  their contents were *subtracted* from the value
>of the address field to generate the effective address.  (Since the address
>field, the index registers, and the addressing hardware were all 15-bit
>paths you could "add" an index by setting the index register to a negative
>number, 2-s complement style).  Thus, the instructions:
>
>     AXT   5,1        Address to indeX True
>     CLA   FOO,1      CLear accumulator and Add
>
>places the value 5 in index register 1, then loads into the accumulator
>the contents of (FOO-5).
>
>I don't know the reason that the hardware was designed this way, but on 
>result of the decision was that until IBSYS came around the 704/709/7090
>FORTRAN defined arrays in descending order: lower subscript values 
>represented higher storage addresses.  Thus, the FORTRAN declaration:

      Look at Fortran generated code, the end control of for loops was
      a TXI followed by a TXH where the 'increment' associated with the
      TXI was a complement value.  If it was a nested for loop, the outer
      loop would also end with the TXI - TXH sequence.
>
>     DIMENSION BAR(10)
>
>would be assembled as:
>
> BAR   BES   10
>
>and might appear in memory as:
>
>   1400   BAR(10)
>   1377   BAR(9)
>   1376   BAR(8)
>   ...
>   1367   BAR(1)
>   1366    <--- value of BAR
>
>Adding to the fun, the 709 FORTRAN assigned arrays row-wise descending,
>the 7090 (FMS) FORTRAN column-wise descending, and the (IBSYS) IBFTC
>compiler used column-wise ascending.  I have a not particularly fond
>memory of trying to rehost to an IBSYS machine a hairy statistical program
>written in assembler for a 709.  I finally told the customer that it would
>be cheaper to rewrite the entire thing from scratch.  (The user didn't
>consult us on this; he just came in and told us to convert the code.)

   I must have missed something, as I do not recall anything but column
   storage of arrays.  Can we have a reference, please?

>
>Oh yes...for readers curious about Mr. Thau's comment about the BSS
>not being appropriate for less than 24 words, I disagree slightly.  A
>little background:
>
>Binary decks were (to nobody's surprise, I hope) written as 80-byte 
>images, and in most cases were actually punched to pieces of cardboard.
>Each card image included 24 (decimal) words of information: three of 
>loader controls and up to 21 words of program image.  The loader controls
>included the address within the image of the first data word and how
>many data words (up to 21) were on the card.
>
>A BSS or BES did not store any value in memory, so if a BSS/BES appeared
>in the source program whatever was in the current binary card buffer was
>written out, and the next card was not started until somthing in the
>source program required that a memory word be initialized.
>
>A series of contiguous BSS and/or BES pseudo-ops which together reserved
>21 words or more were always more efficient than memory-initializing 
>operations like PZE.  On the average they were usually more efficient
>if they totalled 11 words or more, and usually were not as efficient if
>the total was under 11 words.

     An ORG statement would also purge the punch buffer.  Going way back to
     704, it way sometimes important that less than a full card be produced.
     For example, the DS2 on-line dump routine was loaded with a sneak-on
     sequence that managed to save the entire machine except for locations
     0 and 1 plus the MQ register.  Note: on the 704 the Load Cards button
     forced the hardwired execution of the following instruction sequence:

                 RDS  CDR    (Read Select the Card Reader)
                 CPY  0      (Copy contents of 12 row left to location 0)
                 CPY  1      (Copy contents of 12 row right to location 1)
                 TTR  0      (Trap Transfer to location 0)
                             (TTR always jumped - it ignored the trapping mode)

>
>Joe Morris / MITRE


Newsgroups: alt.folklore.computers