From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-11-27 22:12:11
On Wed, Nov 27, 2002 at 01:34:18PM +0100, MagerValp wrote:
> 3) Extend the compiler with 24-bit pointers
>
> This would allow the coder to transparently use all of the
> available ram in the code, without having to worry about the
> underlying structure. There are two major problems though: it would
> take a massive amount of work to implement and debug, and for
> targets that can't access all available ram simultaneously the
> generated code will be far from optimal. You'll need to implement
> far pointers and function calls, with all of its probelms and
> overhead.
Support for banked RAM would in practice be nearly impossible, because that
would mean each and all memory access would have to go via a wrapper that sits
in non banked memory.
But adding a simple form of support for 65816 based systems would be rather
easy: Use a 64KB data space and pack the DATA, BSS and RODATA segments and the
parameter stack into this space. This would be supported directly by the 65816
architecture using the DBR register. Place the code into another 64K and
address it via the PBR. So you will get 128K total without any changes to
pointers. Function pointers are still 16 bit, but this is no problem, since
the code resides in one 64K block. Data pointers (including those to the
stack) are also 16 bit, because they would always address the data segment.
Casting a function pointer to a data pointer would no longer work, but such
casting is will cause undefined behaviour anyway.
All you need for a first test is:
1. A linker config, and
2. some startup code that loads the program parts into their locations and
then starts the program.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-11-27 22:12:31 CET