ruud.baltissen_at_abp.nl
Date: 2002-10-05 12:21:55
Hallo Ullrich and others,
Many thanks for your input.
>   * Just the first 8 chars of any identifier are recognized. 
> This one is easily fixed.
I made a global variable of the length that can be altered using a
directive. This can save memory when using this compiler on a small
computer.
>   * Both are using displays
This was one of the things I didn't understand. The moment an identifier is
declared, I give it a relative address. So the moment I need the data I only
have to perform a "LDA BaseAddres + RelAddress"
>   * Output generation in one pass .... leads to bad code.
That's why I generate ML-code, my assembler takes car of the needed passes.
>     or units.
Oops, forgot about this one myself as well :( Would have bumped in it soon
enough but stil ...
 
>   * The code output by the backend is strictly stack based. 
I noticed. I will use the original stack for real subroutines only for
starting. A dummy stack should take care of passing parameters etc. But I
also have the 65816 and 65GZ032 in mind which have a very big stack and
therefor don't need a dummy stack (I hope).
> ... even global variables are not really global, but
> part of a stack frame.
Because of the various 6502 machines that exist (even within C=), I intend
to make the compiler as flexible as possible. One way to do it is to use
directives telling the compiler where to put the code, global variables,
local variables (= dummy stack) and the heap.
The only problem I face is that I have two flexible parts, the dummy stack
and the heap, that I cannot mix in one or another way. The momentary idea is
that one grows up starting from the declared data and other grows down from
the top of free space.
> I would suggest to drop the existing pcode in favour of
> direct machine language output 
This means I need a mechanism that does several passes to optimize the code.
And my assembler has this mechanism. Producing ML-code also means that I
have a better way to compare the result against the original code for
optimizing the compiler. And again, ML-code can be hacked, binary code only
with a difficulties.
--
    ___
   / __|__
  / /  |_/     Groetjes, Ruud
  \ \__|_\
   \___|       http://Ruud.C64.org
 
       Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.4.