On Sat, 17 Sept 2022 at 11:29, Ed Jaffe <[email protected]> wrote: [...]
> If I were to teach an HLASM course, I can envisage my very first > recommended program organization diagram showing both a code and a data > segment and never once suggesting at any time during the class that code > and data can be (or ever historically were) mixed. Example: > > | R12 -> .---------. R13 -> .---------. > | | | | | > | | Code | | Data | > | | Segment | | Segment | > | | | | | > | '---------' '---------' > What this doesn't, uh, address, is where constants live. Sure, there are a lot of modern Immediate instructions that make it easy to have small integers and maybe a few characters right in the instruction, but there are always going to be longer strings, arrays, and so on. These can't live in the data segment, because that's not going to be initialized by any Assembler/Binder magic such as happens in compilers. So either they end up in the code segment (right after preaching to the student about separation of code and data), or you need a third segment just for the constants. Well that's not necessarily a *bad* thing, but it complicates both the explanation and the bind time processing. To say nothing of potential performance issues on modern split-cache machines with data fetches from near where instructions are being fetched. Tony H.
