🚀 go-pugleaf

From:   BRYDON@PSI%DSN@MRGATE@SNDRTR
To:     "macro32@wkuvx1.bitnet"@M_INTERNET@MRGATE@SNDRTR@SNDRTR

Derek S. Haining (DEREK@MAX.U.WASHINGTON.EDU) says:
>>        .dsect  x
>>flink:  .long
>>blink:  .long
>>data:   .blkl   n
>>bits:   .byte
>>...
>
>I have seen this already done -- with a .PSECT $$ABS$$ declaration.  Notice
>that this PSECT is based at address '00000000', and so basically generates
>offsets.  Also, you can use the "BLINK = 4" construct to accomplish this.

Yes, but if you do the first trick with the $$ABS$$ stuff, aren't you really
generating 'real' storage allocation?  Also, this restricts you to one DSECT,
unless you do assembler directives like '.=0' repeatedly.

For the second case of "BLINK = 4", of course you can do this.  But it is the
programmer's responsibility to know that a longword is 4 bytes, and to get all
the offsets correct (trivial for this example, but a bit more hairy in a large
program).  This is largely a  clerical task that can and should be taken care
of by the assembler.  Also, a data type change of one variable in the middle
of your struct/dsect causes all following offset values to change.  This
currently has to be done manually, should be done by the assembler.

A DSECT directive is trivial to implement in compiler/assembler construction
and saves an awful lot of programming effort.  I think it also makes more
appealing and maintainable code as well.
_______________________________________________________________
Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
            No main(), no brain