I can't imagine anything as complex as SKIP being used by any compiler for any high level language. Same goes for another 360 odd instructions in the P2 instruction set.
I guess the pain is that the assembler has to accommodate them all somehow.
I can't imagine anything as complex as SKIP being used by any compiler for any high level language. Same goes for another 360 odd instructions in the P2 instruction set.
I guess the pain is that the assembler has to accommodate them all somehow.
I'm not sure accommodating the zillions of instructions is all that hard. There are only a few instruction patterns.
I think it might be better for those who understand how to make the most out of the unique P2 abilities to do the C backend. Just a simple mapping from how the P1 compiler works is likely to not be acceptable.
However, a simple mapping from the P1 compiler to P2 may be a useful initial approach to PropGCC for the P2. We could even use an LMM kernel initially, and then change it to hubexec later on. This would be a way to quickly get PropGCC working on the P2. Most of the instructions used by PropGCC for the P1 have the same mnemonics in P2. So an initial version of the compile shouldn't need a lot of changes. It seems like most of the initial work will be on the assembler. This work can be minimized by supporting only the P1-like instructions.
I think it might be better for those who understand how to make the most out of the unique P2 abilities to do the C backend. Just a simple mapping from how the P1 compiler works is likely to not be acceptable.
However, a simple mapping from the P1 compiler to P2 may be a useful initial approach to PropGCC for the P2. We could even use an LMM kernel initial, and then change it to hubexec later on. This would be a way to quickly get PropGCC working on the P2. Most of the instructions used by PropGCC for the P1 have the same mnemonics in P2. So an initial version of the compile shouldn't need a lot of changes. It seems like most of the initial work will be on the assembler. This work can be minimized by supporting only the P1-like instructions.
Doing an "initial approach" that will quickly be replaced by something better has very little appeal to the one who puts a lot of effort into something with a very short lifespan. Anyway, I'll stop talking about this now. I did make a start at updating gas and will likely complete that. We might be able to tweak the old P2 LMM code generator to generate hub exec code. That would get C code running. Anyway, all of this code is in GitHub. Anyone can dive in and work on this stuff.
I looked that the assembly source code generated for the P1, and it seems like it would assemble on the P2 without too many changes. An LMM kernel could be written for the P2 that would contain the same labels used by the P1 LMM kernel. This would minimize the changes required. Hubexec could be accommodated by compiling in the COG mode. For the most part, the same code will run on the P2 from cog memory or from hub memory. The linker would just need to know how to handle the different memory spaces.
... There are also relative branches. I don't think P2-hot had those.
I figured the addition of HubExec was the reason why that changed occurred.
To be clear I'm not saying any of these changes (except maybe SKIP) are bad. They just change the assumptions on which the previous work was based.
True. I'm a fan of relative branching in general. I come from the Amiga world where that was the best way because there was only one virtual memory space for all processes/tasks.
I just hadn't noticed until recently that the Prop2 is now built around relative addressing (where there was only absolute addressing in Prop1) and I realised there must have been a reason why the transition had occurred. Hence it made sense to point fingers at HubExec, and you've all but confirmed it.
Comments
I guess the pain is that the assembler has to accommodate them all somehow.
I just hadn't noticed until recently that the Prop2 is now built around relative addressing (where there was only absolute addressing in Prop1) and I realised there must have been a reason why the transition had occurred. Hence it made sense to point fingers at HubExec, and you've all but confirmed it.