Oppolzer - Informatik / Blog

Am 20.01.2015 um 18:43 schrieb P.G.:
> On Tue, 20 Jan 2015 11:12:33 -0500, P.F. wrote:
>
>> Jumping in a little late here, but AMODE 64 for *code* is not
>> necessarily the need for most business purposes. AMODE 64 for *data* is
>> the need that I perceive as primary. I would be well satisfied if 64-bit
>> data storage could be used transparently even with code running only in
>> 31-bit storage.
>>
> Of course there are no separate AMODEs for code references and data references.
> But 31-bit addressing instructions might be used for code and 64 for data.
> Reminds me of the diverse memory models in historic Windows.
>
>> 3. ... direct I/O buffer addressing (unfortunately not usually
>> supported by existing HLL file semantics) ...
>>
> Pascal.  But not Borland's Pascal.  What ever happened to Pascal?

I have built an extended (2014) version of the (1982) McGill
University version of the 1979 Stanford Pascal compiler, which runs on
VM 370/R6 on Hercules. When I am retired (or when I have enough free
time), I will rework the code generation to build 31-bit machine code
(now it is all AMODE 24).

>> 4. As some others have also mentioned, interfacing with Java (or any
>> other JVM-based language) processes passing data from 64-bit storage for
>> HLL business processing will be a growing requirement
>>
>> .... The ability to use direct pointer arithmetic using HLL semantics
>> instead of needing to use integer redefinitions of pointers to perform
>> pointer arithmetic would be quite helpful in such data restructuring
>> projects.
>>
> This is intrinsic to C.
>
> Scientific Data Systems (later Xerox) hardware multiplied the index register
> content by the operand size when calculating effective addresses.  Not the
> best idea.  It's *so* FORTRAN!

In C, if you add one to a ptr, in fact the address points at the next
array element, that is, the number you add to the ptr is multipled by
the element size. Same goes for the difference of two pointers; you
get the numbers of elements between the pointers. That's because every
pointer is typed in C.

PL/1 today also allows simple pointer arithmetic, and even with a
C-like syntax (if you want):

DCL P PTR;

P = ADDR (X);
P += 5;

/* now P contains the ADDR of X plus 5 */

but unlike C, pointers in PL/1 have no type, so in this case, you get
simple address arithmetic.

Kind regards

Bernd


> -- G.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN
>