Re: [sdcc-devel] Having __far pointers that are wider than generic pointers?

[Philipp K. K. <pk...@sp...>]

The trade-offs however, are quite different for different architectures:

mcs51: There are many different intrinsic named address spaces in the
hardware. None of them is a good default generic space; we'd need at
least __code and one other space in a good generic space. At that point
we already need generic pointers wider than 16 bit, and generic pointer
reads need to go through a helper function. Having the generic space
just cover everything is then an obvious choice, since it gets benefits
at nearly no extra cost. And that generic pointer is then wide enough
for function pointers, too.

pdk: Fewer spaces, but again, we want at least __code and one other
space, and at that point we've already covered everything except for
__sfr. The hardware can't do pointers to __sfr anyway, so with a generic
space containing both __data and __code, we have a generic space
covering everything we can point to, and generic pointers are then also
wide enough for function pointers, too.

stm8: We have an efficient 16-bit addressing mode that convers nearly
everything (__sfr, code, data). For most devices this is totally
sufficient. So that is used in the medium model. Accessing data using an
8-bit pointer would be slightly more efficent, but only slightly, so
__near hasn't been implemented yet, and there wasn't much user demand so
far. The stm8 can also efficiently use a 24-bit address space for
functions. So to better support devices with more than 32 KB of flash,
we introduced the large memory model (the idea is to move the function
into the upper parts of the flash, while the lower 32 KB of flash can be
used for const data, and be accessed efficeintly with 16-bit pointers).
Data access for the upper parts of flash would be quite inefficient, so
__far also never got implemented. By keeping generic pointers at 16 bit,
but having function pointers at 24 bit, we get efficient code, and can
make good use of the available flash. Even if we implement __far one
day, I'd like to keep the generic pointers at 16 bits for the medium and
large memory models. We could later also introduce a huge memory model,
where __far becomes identical to the generic address space.

r2k, etc: We have an efficient 16-bit addressing mode. Data access
beyond that is substantially less efficient. Like for stm8, we an use
more memory efficiently for functions. So introducing a memory model
where function pointers are wider than object pointers, like for stm8,
makes sense (future medium memory model). But this time, there are
devices with much more memory (both RAM and flash) than the 16-bit
addresing mode can cover. So we also want to provide a way for the user
to access that, despite access being less efficient there. Introducing
__far pointers makes sense for that, but we would want to keep the
generic space efficient. So, this time, we'd get a __far that is not a
subset of the generic space. Again, could later also introduce a huge
memory model, where __far becomes identical to the generic address space.

Philipp