John, I carefully considered the idea of using macro updates such as you described.
Making the basis changes necessary for baseless code generation is not cheap, but adding an additional level of complexity by requiring the invocation of an internal macro to evaluate literals, the addition of additional global symbols, and the requisite copying of data between the various local and global symbols seems to me to be cost-prohibitive. Adding a simple change to the High-Level Assembler is relatively inexpensive, and will significantly reduce the number of macro changes necessary to support baseless code generation. Let me take a minute to detail a potential implementation scheme. There may be some differences in any actual implementation, since I do not have access to the internals of the High-Level Assembler. When a literal is detected in a machine instruction a process is called to add the literal to a literal information table which will subsequently comprise a literal pool. Clearly, this is what the High-Level Assembler must be doing today. I think that it is self-evident that there must exist a flag byte (perhaps more than one) associated with the literal. Now, if the machine instruction uses relative addressing, then I propose to set a "relative alignment" bit in the flag byte for the literal, add 1 to the actual length, and then round down to an even value to get the required storage length, which will also be stored in the literal information table. Finally, when LTORG processing is initiated, either explicitly or implicitly, the literals will be generated on boundaries which are consistent with the referencing machine instructions. The use of existing macro facilities, such as you describe, is certainly possible. However, in this case I do not feel that it is the best solution. John P. Baker -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of john gilmore Sent: Sunday, August 22, 2010 11:14 AM To: [email protected] Subject: Re: LARL vs. literal alignment --snip-- In such an exercise the data type of the value of ¶meter can be determined, often now using BIFs like ISBIN, ISDEC, ISHEX, even ISSYM, or in extenso using one's own trivial service macros. It can then be altered by padding it, as others have suggested; or again an additional innocuous literal having a complementary length can be added to the literal pool following it. (I forbear to demonstrate how this can be done, but I suspect that here again I should perhaps "string things out for the delectation of . . . ".) Such schemes permit 'customers' to continue to use literals. They even permit marginal or dubious literals to be edited or repaired. They are workaday facilities for those of us who have elected to master the the facilities of the macro language and to use them effectively. This is as good a place as any to deal with Paul Gilmartin's (not, I hope, very serious) sally about such constructs as |paul DC 0CL4'Paul' In it neither the 0 repetition factor nor the explicit byte length 4 determines the alignment of paul. The data-type specifier, C here, does that. Moreover, in exactly the tenuous but not spurious sense in which 0 is a multiple of 16 it is also a multiple of 1, 2, 4, 8, and indeed any integer. Division by zero is in fact interdicted for just this reason. For the benefit of those who need such guidance I will in future mark any jocular technical suggestions I make here with the delimiters |<technical joke begins> | . . . |<technical joke ends> I promise to be parsimonious in my use of them. My contributions here are anyway not usually jocular. They are typically informed by the bleak perception that a significant fraction of the problems raised here are pseudo-problems, artefacts of radical if perhaps excusable ignorance. Let me very much more specific about this. The HLASM is imperfect. There are many ways in which it could be improved or extended. That said, it is also a powerful and expressive vehicle. Too many contributors here are too ready to impute their own inadequacies to it: Extend it please, in this or that ad hoc way, so that my problem of the moment will go away. They would usually do much better to explore how the facilities it already makes available can be used to address that problem. John Gilmore Ashland, MA 01721-1817 USA
