On 2015-08-20, at 05:39, Peter Relson wrote: > >> Does this mean that one can't create a data module to be loaded > above-the-bar? >> One must obtain STORAGE and copy into it? Can one IDENTIFY an address > above- >> the-bar? > > No to all three. > You can create a data module to be loaded above the bar. You can use LOAD > with ADDR64 to get the system to load into the area that you provide. > A disappointing restriction. I hope full Content Supervision support extends above the bar someday. (Is it constrained by existing Data Areas definitions?)
> Nobody would implement an option that was clearly supporting incorrect > information whose sole intent is to avoid some processing you don't think > you want. > Technically, one might argue that any AMODE value is "incorrect" for a pure data object. The programmer ought to be allowed to choose the most useful value. > Now if you had mentioned some new option asking for a non-AMODE-identified > return value that could be different. > Such an option might be useful if a given ENTRY point could be used alike for branch and non-branch operations > If you don't need bit 63 because you're not doing a BASSM then clear it > (whether because it's data or because you're doing a BASR or whatever). > And simply put: don't place AMODE 64 data that is to be externally located > on an odd address unless you know that it will be on an odd address (so > that the user would know to avoid clearing bit 63). > "know" requires the programmer to make undesired assumptions about the address of an object. How are bit 32 and bit 63 handled in 64-bit V-CONs? (Do 64-bit V-CONs exist?) -- gil
