Re: Language/Compiler for 8/16 bit processor?

davidm@questor.rational.com (David Moore) writes:


>mago@legba.sunmexico.Sun.COM (Gerardo Horvilleur) writes:
>>Where can I find information on languages designed for simple 8 bits
>>processors?


>bazyar@netcom.com (Jawaid Bazyar) writes:
>> Most 8-bit high-level languages opted for a P-Code approach.




>This is, I think, true of the 6502. However, on the Z80 chips, Turbo
>Pascal, BDS C (I believe the initials were), Pascal MT+ and my Modula-2
>compiler generated machine code. These were all commercially available
>compilers.


There was a Pascal compiler for the BBC micro that produced 6502 native
code. The compiler was written in BBC BASIC (a structured BASIC containing
an embedded assembler). It didn't handle all of Pascal, but you could
still write useful programs with it.


>The Z80 had two "pointer" registers (IX and IY) which made the compiler
>writer's life a lot easier. It also had some 16 bit arithmetic operations.
>Just as importantly, there were register move instructions. The 6800, and
>I think also the 6502, required you to store values in memory and reload
>them to move them between registers.


This is only partly true. You could move values from A to X or Y and vice
versa (using TAX, TYA etc.) and from eiter X or Y (I don't recall) to and
from the status register. You couldn't move from X to Y or vice versa.


The main difficulty with using the 6502 as a target language for a
Pascal-like language was addressing. The indexed addressing mode was the
"wrong way around", in the sense that you added a 16 bit constant to an 8
bit variable. For stack-relative addressing it was more useful to add an 8
bit constant to a 16 bit variable as on the Z80. The best you could do on
the 6502 was to use zero-page indexed addressing, where you could add a 16
bit variable (in zero page) and an 8 bit variable (in Y), but that
required an "extra" instruction to load a constant offset into Y before
doing this. The lack of a 16-bit add also made array indexing a bit of a
pain for arrays larger than 256 bytes. Of course, all these problems were
solvable using sequences of instructions, but the resulting code would be
to large to use on the quite small machines normally using 6502s.


Torben Mogensen (torbenm@diku.dk)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.