Source level compatiblity between P1 and P2?

David Betz

There has been lots of discussion of binary encoding optimizations in P2 that make it binary incompatible with P1 programs. What about source level compatability? What common source level practices used in P1 will not work anymore in P2? I guess one obvious one is that the NR and WR specifiers will no longer be supported. Are there other source level differences? I realize of course that there are many new instructions in P2 but right now I'm only asking about how much P1 PASM source code will have to be changed to assemble for P2. I'm also not worried about instructions that manage the hardware blocks like counters and video or even pins. In particular, I'm wondering about changes that might affect the code generation of PropGCC.

Bill Henning

Anything that uses:

- WAITVID
- Counters
- NR flag

- all the new P2 features (hub, clut pointers, indirection)

There is probably more I have not thought of.

won't be source code compatible.

Frankly, to make decent use of the new features, gcc will need a new back end code generator, assembler and new optimizer rules at a minimum - however that effort should result in smaller/faster code.

David Betz

Bill Henning wrote: »

Frankly, to make decent use of the new features, gcc will need a new back end code generator, assembler and new optimizer rules at a minimum - however that effort should result in smaller/faster code.

This is exactly what I'm worried about. If the compiler has to be ported again to P2 that opens up all kinds of questions including whether we should start with LLVM this time instead of GCC.

Bill Henning

Good point.

A "preliminary" port that minimizes the changes may make sense, and could be done fairly quickly by not trying to incorporate the new instructions etc, however for good performance, it may actually take less time and get better performance to start from scratch. (Sorry Ken)

Incorporating all the new features, and using a VLIW-approach, would result in much faster code.

p.s.

Starting with a preliminary port, and hoping to over time make small changes to "bring it up to snuff" is likely far more work and would cost a lot more than a clean sheet design specifically for the P2.

David Betz wrote: »

This is exactly what I'm worried about. If the compiler has to be ported again to P2 that opens up all kinds of questions including whether we should start with LLVM this time instead of GCC.

David Betz

Bill Henning wrote: »

Good point.

A "preliminary" port that minimizes the changes may make sense, and could be done fairly quickly by not trying to incorporate the new instructions etc, however for good performance, it may actually take less time and get better performance to start from scratch. (Sorry Ken)

Incorporating all the new features, and using a VLIW-approach, would result in much faster code.

p.s.

Starting with a preliminary port, and hoping to over time make small changes to "bring it up to snuff" is likely far more work and would cost a lot more than a clean sheet design specifically for the P2.

We already did the quick port and had it working until Chip changed all of the instruction encodings. That in itself wasn't really a problem since we could just have a different opcode table for P2. The real change was the elimination of the WR bit. I guess the PropGCC code generator makes use of that in cases where it wants to set the condition codes but not write any result. It is unknown at this point how much effort is involved with removing this feature but it will probably result in slightly slower generated code.

Bill Henning

Sorry David, I was not clear.

I meant a quick port to the new instruction encoding.

I liked the previous quick port, I did play with it a bit and it worked - you guys did a good job.

What I was referring to was making good uses of INDA/INDB, PTRA/PTRB, SPA/SPB with all the different addressing modes, the new math instructions, a float package based on them etc etc - the hub and clut addressing modes are a huge win for generated code (once implemented) as will the new instructions.

Regardless, the changes are well worth the re-work, as they greatly upgrade the P2 instruction set and opportunity for better code generation.

David Betz wrote: »

We already did the quick port and had it working until Chip changed all of the instruction encodings. That in itself wasn't really a problem since we could just have a different opcode table for P2. The real change was the elimination of the WR bit. I guess the PropGCC code generator makes use of that in cases where it wants to set the condition codes but not write any result. It is unknown at this point how much effort is involved with removing this feature but it will probably result in slightly slower generated code.

David Betz

Bill Henning wrote: »

Sorry David, I was not clear.

I meant a quick port to the new instruction encoding.

I liked the previous quick port, I did play with it a bit and it worked - you guys did a good job.

What I was referring to was making good uses of INDA/INDB, PTRA/PTRB, SPA/SPB with all the different addressing modes, the new math instructions, a float package based on them etc etc - the hub and clut addressing modes are a huge win for generated code (once implemented) as will the new instructions.

Regardless, the changes are well worth the re-work, as they greatly upgrade the P2 instruction set and opportunity for better code generation.

Certainly the new math instructions should be used. A few were in the original port to P2. I'm not sure how useful the hardware stack will be for C though since it is really too small for typical C programs. It could possibly be used in a P2 revision of COG native code generation (-mcog). Not sure if it would be useful for LMM or XMM though. The addressing modes can probably be used as you suggest, especially the hub ones.