Re: Different sized data and code pointers
Julian Brown wrote: FWIW, a port I did used indirection for all function pointers, albeit for a different reason, and I can report that it seems to work OK in practice with a little linker magic. It wasn't really production-quality code though, I admit. Perhaps the indirection table can safely hold only those functions whose address is taken? (Or maybe that was assumed anyway?) A previous version of our back end did indeed use the indirection (data) method, and IIRC only stored pointers for address taken functions. However, we really don't have enough data space for that sort of thing. Especially since all the developers are used to using a compiler which does this `properly'. Another possibilty that we've discussed is putting an indirection for function pointers at <64k in code space (ie, a load and a branch for each function). However, either way requires us to modify all the obscure function pointer code in our firmware (eg, functions that get loaded from flash memory to ram before they're run) and we've got a hack that *nearly* works[1]. It worries me that doing anything other than leaving it alone it likely to introduce more bugs than it fixes. In fact I've now patched up the slight breakage we were seeing in the hack, so it's even more tempting to just leave it alone again. Ned. [1] Ok, here's the hack. Get a bucket, you might be sick. The header in the machine description has something like: extern tree type, decl; #define Pmode xap_pmode(type,decl) #define POINTER_SIZE xap_pointer_size(type,decl) Those functions check to see if they're looking at the global type and decl (which are defined to NULL in the C file), or if there's some other type or decl in scope where the macro's used. If one of them is in scope, and it's a function pointer type, then they return HImode or 32 otherwise they return QImode or 16 (yes, QImode - our platform has 16 bit bytes). It's possibly the worst hack I've ever had the misfortune to come across. I can't imagine how anyone ever thought it was a good idea. The worst thing of all it that it actually works quite well and since people are already using it, I'm not going to be allowed to get rid of it until I come up with something that works equally well :( ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. **
Re: Different sized data and code pointers
On 2005-03-02, Thomas Gill <[EMAIL PROTECTED]> wrote: > Paul Schlie wrote: > >> With the arguable exception of function pointers (which need not be literal >> address) all pointers are presumed to point to data, not code; therefore >> may be simplest to define pointers as being 16-bits, and call functions >> indirectly through a lookup table constructed at link time from program >> memory, assuming it's readable via some mechanism; as the call penalty >> incurred would likely be insignificant relative to the potential complexity >> of attempting to support 24-bit code pointers in the rare circumstances >> they're typically used, on an otherwise native 16-bit machine. > > Thanks for the response. > > Suppose we don't have enough space to burn on a layer of indirection for > every function pointer. Do I take it that there's really not a clean way > to make GCC treat function pointers as 24 bit while still treating data > pointers as 16 bits? FWIW, a port I did used indirection for all function pointers, albeit for a different reason, and I can report that it seems to work OK in practice with a little linker magic. It wasn't really production-quality code though, I admit. Perhaps the indirection table can safely hold only those functions whose address is taken? (Or maybe that was assumed anyway?) Julian -- Julian Brown CodeSourcery, LLC
Re: Different sized data and code pointers
Paul Schlie wrote: If the program's address space pointer is more accurately implemented as a 16-bit pointer combined with an 8-bit segment address; wonder if it may be worth your while to take a look at how the old segmented x86 GCC targets treat segmented addresses? >>> >>> Thomas Gill wrote: >>> Hmmm.. it's possible. Where can I find that? >> >> the target ports are in gcc/config/... > > Sure, I mean which target should I be looking at? Was thinking x386, but it seems to use the same scheme for data or program addresses; candidly, I believe building a jump table for function-pointer calls just like interrupt vectors may be your best bet; as it will only add a few cycles per call through a data pointer, and may even be eliminated if the code never calls a function pointer (which most code never does).
Re: Different sized data and code pointers
Paul Schlie wrote: the target ports are in gcc/config/... Sure, I mean which target should I be looking at? Ned. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. **
Re: Different sized data and code pointers
Paul Schlie wrote: With the arguable exception of function pointers (which need not be literal address) all pointers are presumed to point to data, not code; therefore may be simplest to define pointers as being 16-bits, and call functions indirectly through a lookup table constructed at link time from program memory, assuming it's readable via some mechanism; as the call penalty incurred would likely be insignificant relative to the potential complexity of attempting to support 24-bit code pointers in the rare circumstances they're typically used, on an otherwise native 16-bit machine. Thanks for the response. Suppose we don't have enough space to burn on a layer of indirection for every function pointer. Do I take it that there's really not a clean way to make GCC treat function pointers as 24 bit while still treating data pointers as 16 bits? Thanks, Ned. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. **
Re: Different sized data and code pointers
> Thomas Gill wrote: > I'm working on a GCC backend for a small embedded processor. We've got a > Harvard architecture with 16 bit data addresses and 24 bit code > addresses. How well does GCC support having different sized pointers for > this sort of thing? The macros POINTER_SIZE and Pmode seem to suggest that > there's one pointer size for everything. > > The backend that I've inherited gets most of the way with some really > horrible hacks, but it would be nice if those hacks weren't necessary. In > any case, the hacks don't cope with casting function pointers to integers. With the arguable exception of function pointers (which need not be literal address) all pointers are presumed to point to data, not code; therefore may be simplest to define pointers as being 16-bits, and call functions indirectly through a lookup table constructed at link time from program memory, assuming it's readable via some mechanism; as the call penalty incurred would likely be insignificant relative to the potential complexity of attempting to support 24-bit code pointers in the rare circumstances they're typically used, on an otherwise native 16-bit machine. (and just as a heads up, there seems to be no exiting mechanism to enable the convenient access of static constant data stored in an orthogonal address space relative to read-write data memory; although suspect one could implement a scheme in which every address is discriminated at run-time based on some address range split, but likely not worth the run-time overhead to do so, but should work if desperate to conserve ram)
Re: Different sized data and code pointers
Thomas Gill wrote: Hi all. I'm working on a GCC backend for a small embedded processor. We've got a Harvard architecture with 16 bit data addresses and 24 bit code addresses. How well does GCC support having different sized pointers for this sort of thing? The macros POINTER_SIZE and Pmode seem to suggest that there's one pointer size for everything. The backend that I've inherited gets most of the way with some really horrible hacks, but it would be nice if those hacks weren't necessary. In any case, the hacks don't cope with casting function pointers to integers. I too would be interested in different size pointer support as this may be needed to further improve the AVR port (add new bigger devices). Eric
