ruud.baltissen_at_abp.nl
Date: 2002-10-05 15:51:26
Hallo Ulrich,
> My suggestion would be to add a static variable space.
After reading your story I realised that what I'm building now does use
above feature. [1]
> While this makes the compiler more complex
Yes, indeed. That's why I have doubts if the compiler will run on memory-low
machines.
> I'm thinking of things like
I would be very happy if my compiler works at all for a beginning :)
Optimalisation of the compiler is the next step.
> The usual program layout is ....
That's what I have in mind as well. But...
> The stack is located in top memory
What is top memory: $9FFF or $CFFF for a C64? That's why I want to use
directives so the programmer can influence these pointers. But then I still
face a dilemma: using $9FFF I run the risc that the heap and stack can
collide. Using $BFFF probably means I'm wasting memory.
Then what about using the RAM under ROM? How do I tell my compiler to use
it? What about bankswitching? These are some of the questions I asked myself
and I realised that IMHO a static variable space is the best solution to
keep the code simple and still be able to use all these features.
> * Support for map and symbol files, so you can lookup the
> actual addresses of variables and procedures ....
Good idea, will keep that in mind.
> * Having a library that supports basic stuff would be
> useful. Something like screen I/O as in the TP CRT unit,
> file support and so on.
I think that is a must anyway simply because we are dealing with different
machines. Take outputting text to screen as example:
- I can write text directly to the video-RAM
- I can use the onboard routines like CHROUT
- I can use a user supplied routine
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| http://Ruud.C64.org
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.4.