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.  > 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.