enrico-sorichetti wrote:... any half decently written prolog/entry macro will restore the R1 content to its original value !
Agreed, but in my career I've seen any number of variations on this theme, and most of them were pretty half baked.
One problem is the programmer is forced into whatever convention the author of the macro wants at the time. I see six immediate issues with this INITL macro
- What text string is used for the program ID?
- Is the text string constructed properly and in the "right" place? Most INITL type macros fail this test in one way or another.
- Where is the save area? At a guess, it is embedded in the macro expansion, which is sort of OK, but it is not a solution I have ever favored.
- Since the save area is embedded in the INITL macro expansion, the program is not reenterable and cannot be made reenterable.
- Is the new save area correctly and completely connected to the save area chain.
- What is the relationship of the base register to the start of the program. I personally prefer that they are equal so that the offset in the instruction matches the program offset, but given that the save area is part of the macro, you've given away a significant chunk of potential addressability, which I don't always like.
This issue about conventions is more complex than most beginners realize. When I started in the late 1960s, the usual convention for a reenterable program is the save area started addressability for the work area. The Language Environment DSA concept still follows this convention, and its entry and exit macros follow this convention. By the middle 1970s I realized this idea was not so good, and I no longer use it.
One dirty secret us Assembler programmers seldom think about is "standard" linkage is pretty poor.
000000 00000 001A3 1 GETPARM CSECT
R:C 00000 2 USING *,12
3 SAVE (14,12),,*
000000 47F0 F00C 0000C 5+ B 12(0,15)
000004 07 6+ DC AL1(7)
000005 C7C5E3D7C1D9D4 7+ DC CL7'GETPARM'
00000C 90EC D00C 0000C 8+ STM 14,12,12(13)
000010 18CF 9 LR 12,15
000012 41F0 C0E0 000E0 10 LA 15,SAVEAREA
000016 50F0 D008 00008 11 ST 15,8(,13)
00001A 50D0 F004 00004 12 ST 13,4(,15)
00001E 18DF 13 LR 13,15
Part of the problem is the instruction prefetching done by modern hardware. Hopefully it's smart enough to stop when it gets to the B instruction, but that just slows things down. In addition, since the B instruction uses a base register, it's hard for the hardware to know where to resume its instruction prefetch. Yes, you can persuade the SAVE macro to use a BRC 15,*+12 instruction in place of the B instruction, but few beginners (much less us old dinosaurs) know the method, which should make it easier for the hardware to know where to resume its instruction prefetch.
The STM instruction is quite fast, but it still saves too many registers. By using register 4 as the base register (registers 5 through 12 would not be used, so why save them? This varies by program, ...) we could improve this, and by improving this we also need to restore fewer registers, so that helps improve exiting from the program.