> So in effect, we have two pointer sizes, 64 being the default, but
> we can also get a 32 bit pointer via the syntax above? Wow, I'm
> surprised that works.
Yup, been that way for many years.
> And the only time we'd be able to use larl is a dereference of a
> pointer declared with the syntax
On 07/08/2015 03:05 PM, DJ Delorie wrote:
In the TPF case, the software has to explicitly mark such pointers as
SImode (such things happen only when structures that contain addresses
can't change size, for backwards compatibility reasons[1]):
int * __attribute__((mode(SImode))) ptr;
ptr = &s
In the TPF case, the software has to explicitly mark such pointers as
SImode (such things happen only when structures that contain addresses
can't change size, for backwards compatibility reasons[1]):
int * __attribute__((mode(SImode))) ptr;
ptr = &some_var;
so I wouldn't consider this the "d
On 07/08/2015 02:33 PM, DJ Delorie wrote:
Is there any reason that LARL can't be used to load a 32-bit symbolic
value, in 64-bit mode? On TPF (64-bit) the app has the option of
being loaded in the first 4Gb so that all symbols are also valid
32-bit addresses, for backward compatibility. (and if
Is there any reason that LARL can't be used to load a 32-bit symbolic
value, in 64-bit mode? On TPF (64-bit) the app has the option of
being loaded in the first 4Gb so that all symbols are also valid
32-bit addresses, for backward compatibility. (and if not, the linker
would complain)
Index: s3
