On 07/16/03 Dan Sugalski wrote: > >> pit/pratfalls. At one point, Tupshin suggested emulating a 'more > >> traditional stack-oriented processor' and I don't think he was > >> joking... > >> > >Indeed, I wasn't, but I wish somebody would at least have the > >decency to tell me how insane this is. ;-) > > Oh, sorry. > > You're insane. :) > > Traditional processors aren't stack-oriented, not even ones that are > more register-starved than the x86 family. (I'm thinking of the 6502 > with it's 1.75 registers here)
The wording "stack-oriented processor" is a little misleading, since it usually means the processor has a stack-oriented instruction set, instead of a register one. The original context, instead, implies it refers to GCC's assumptions about the existence of the runtime stack (as the contiguous area of memory where call frames are stored). There is already a (limited) gcc backend that targets the CLR that sets up an area of memory for that use, but, as you can guess, it's not vey nice. > The base architecture's fixed, and I'm not inclined to change it at > this point. GCC could handle it if someone wanted to work it out--it > can already deal with multiple register classes, since most machines > these days have at least two (general purpose and float) and the ones > with vector processors arguably have three types. It'd probably have > to do less work for parrot than for other systems, as we have more > registers, and register starvation's one of the more annoying things > a compiler has to deal with. I think a gcc port would require parrot to provide at least a stack memory area and a register (sp) that points to it. There may be other issues with the parrot instruction set, but since you have already hundreds (or thousands?) of opcodes, I guess it wouldn't be an issue to add a few more if needed:-) lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
