DXDs, aka pseudo-registers are lately somewhat generalized into "no-load" binder classes. C and other HLLs use them, but not for DSA/stack that I know of.
I think the Metal C convention of pre-setting the savearea forward pointer is pretty clever. It doesn't interfere with any traditional save area linkage, and is mighty efficient. ALL HLLs use a stack. LE handles stack overflow. With Metal C, you place your bet, test, and hope you've got it covered. If your program is complex enough to cause you doubt, maybe you should use LE. However, it's really very simple to add a stack-overflow check to entry logic, and I think IBM will have to do that someday for Metal C. Abends are infinitely better than memory corruption. sas On Tue, Dec 6, 2016 at 11:14 AM, Tony Harminc <[email protected]> wrote: > On 6 December 2016 at 10:39, Tom Marchant < > [email protected]> wrote: > > > On Tue, 6 Dec 2016 09:20:33 -0500, Steve Smith wrote: > > > > >Metal C linkage requires your own forward chain to be preset to the NAB. > > I > > >think LE C just uses the NAB. Regardless, that shouldn't cause a > problem > > >either. > > > > I never heard of such a thing, so I looked it up. > > > > It is a rather bizarre requirement that seems to me to contradict the > > standard linkage conventions that it claims to follow. > > > > It means that a program must know not only its own storage > > requirements, but the storage requirements of every program that it > > calls, and every program that they call, etc. > > > > There is no mechanism to verify that the allocated storage hasn't been > > exceeded, or to ensure that the storage that is obtained is adequate. > > > > Well, there is... The traditional approach to this is to use DXD and CXD to > have the Binder add up all the requirements at link time. This scheme is > sometimes known as "Pseudo registers", and is (was?) used by PL/I. It works > well; the only real downside is that it doesn't account for recursive > calls, whether direct or indirect. > > Tony H. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
