kerravon86@yahoo.com.au [hercules-os380]
2018-06-02 13:55:02 UTC
I am trying to figure out how malloc() should
work. I thought it might be better to abstract
the problem by pretending that fopen() was
an OS function which returns a file pointer.
So if we are on a 256-bit computer running
a 128-bit program, fopen() and malloc()
need to return addresses in 128-bit space.
But then I was thinking we should decouple
data pointers and code pointers. If we have
a 128-bit load module that is loaded into
128-bit space, so all references to either
code or data within the load module will
be 128-bit pointers, then it is theoretically
possible that the assembler program has
been written with knowledge that the
operating system always returns data that
is in 64-bit space. In addition, it may have
knowledge that the stack is always in
32-bit space.
So data pointers can theoretically be split
into 3 categories that have different bit
sizes. But C only provides a single data
pointer.
Because some data is in the load module
itself, I think there should be a rule that
data pointers will always be equal to or
greater size than code pointers.
If this reasoning is sound, then there still
needs to be a way of the operating system
to know what the data pointer size is of
the load module. We could have a 128-bit
load module loaded into 128-bit space,
but it is using 256-bit data pointers. This
would allow the module to access more
data.
I am inclined to say that we should just
have a rule that if you want to access
256-bit data, you should create a
256-bit module instead of trying to run
with separate code pointer size and
data pointer size. However, bringing back
to what we actually have in MVS, we
basically have 32-bit load modules
(must be loaded into 32-bit space) that
are able to run as AM64 and able to
manipulate 64-bit data.
I am unsure how malloc() should be
implemented. Is it right for GETMAIN
to provide appropriate flags, or is it
something that the OS should be
figuring out itself, perhaps by virtue of
where the load module is loaded?
BFN. Paul.
work. I thought it might be better to abstract
the problem by pretending that fopen() was
an OS function which returns a file pointer.
So if we are on a 256-bit computer running
a 128-bit program, fopen() and malloc()
need to return addresses in 128-bit space.
But then I was thinking we should decouple
data pointers and code pointers. If we have
a 128-bit load module that is loaded into
128-bit space, so all references to either
code or data within the load module will
be 128-bit pointers, then it is theoretically
possible that the assembler program has
been written with knowledge that the
operating system always returns data that
is in 64-bit space. In addition, it may have
knowledge that the stack is always in
32-bit space.
So data pointers can theoretically be split
into 3 categories that have different bit
sizes. But C only provides a single data
pointer.
Because some data is in the load module
itself, I think there should be a rule that
data pointers will always be equal to or
greater size than code pointers.
If this reasoning is sound, then there still
needs to be a way of the operating system
to know what the data pointer size is of
the load module. We could have a 128-bit
load module loaded into 128-bit space,
but it is using 256-bit data pointers. This
would allow the module to access more
data.
I am inclined to say that we should just
have a rule that if you want to access
256-bit data, you should create a
256-bit module instead of trying to run
with separate code pointer size and
data pointer size. However, bringing back
to what we actually have in MVS, we
basically have 32-bit load modules
(must be loaded into 32-bit space) that
are able to run as AM64 and able to
manipulate 64-bit data.
I am unsure how malloc() should be
implemented. Is it right for GETMAIN
to provide appropriate flags, or is it
something that the OS should be
figuring out itself, perhaps by virtue of
where the load module is loaded?
BFN. Paul.