After I got through laughing over a stack of 256 values, and 3840 registers (I know, ''something like...''), I wanted to recommend that you pick up the book, "Virtual Machine Design and Implementation in C/C++" by Bill Blunden.

Thanks for the laugh, and good luck with your project.

David

The 6502 only had a 256 byte stack. That is why there are almost no C compilers for 6502 machines.

As for 3000+ registers, well, that is creative licence :-)

quote:The 6502 only had a 256 byte stack. That is why there are almost no C compilers for 6502 machines.

It is my day for learning things. Why would only having a 256 byte stack allocated by hardware affect the ability to write a compiler for it? Couldn't the compiler writer ignore the hardware stack and implement their own stack in regular memory of whatever size they wanted, and work their program around this stack? I believe that is what MS, Borland, and other compiler writers do, but maybe I am wrong.

David

[edited by - david oneil on June 8, 2004 11:22:32 PM]

Virtually enough

quote:Original post by David ONeil

quote:The 6502 only had a 256 byte stack. That is why there are almost no C compilers for 6502 machines.

It is my day for learning things. Why would only having a 256 byte stack allocated by hardware affect the ability to write a compiler for it?
[edited by - david oneil on June 8, 2004 11:22:32 PM]

Hmm, it''s been ages since I programmed a 6502, it did not have segment registers like a 8086 so I think you could not allocate your own stack segment. I think the stack was something like the above author has, it was a fixed block of memory.

Languages like C and Pascal require a stack for function calls and recursion. 256 bytes is very limiting, even on a very limited machine. You could write a compiler for them but, they were so slow and small, nobody really programmed them in anything but assembler language anyways.

MS, Borland, etc use the stack that the processor thinks of as a stack. Though you could get around it, it would be extra effort, a waste of a register, and ignoring any optimization Intel put into their chips for dealing with the stack. It would likely screw up prefetch and branch prediction

To "create your own stack" rather than using what the CPU thinks of as a stack would mean never using call, and ret, but manually emulating the behaviour, saving the current address, changing the stack pointer, jumping to a new location, changing the stack pointer back, reading the location, and jumping to it. Push and Pop would become complex, large macros.

On the 6502, yes there was a 256 byte stack, at $0100-$01FF. There was also only 3 8-bit registers. Creating your own stack isn''t feasible in that situation, and a 256 byte stack severely limits recursion, and local variable storage.

call, ret, push, pop (and other cpus sets of similar opcodes...jsr, rts, pha, pla, bsr, bcc, etc) all use an implied stack. With the x86 this is at SS:SP. With 680x0 it''s A7. You just need an SP (stack pointer) register which is a pointer to memory like any other addressing register, which is the implied memory used by stack based instructions.

Modern processors don''t have a specific memory area for stack. One of the registers is considered the stack pointer, and it''s just a pointer to somewhere in RAM. This lets you have any stack size you''d like, and since it''s location isn''t fixed, allows multithreading easily. With a fixed memory location stack you''d need to copy stacks around on every context switch, which isn''t a good idea. Just save the current registers somewhere, and load in the other threads registers, and voila, you''ve switched context.