So as noted earlier, my son needed a project to occupy him, so he's learning a bit of vi, git, & gcc by doing some of the easier parts of cc0 -> REG_CC conversions.
I selected the v8 port as the first target based on the (flawed) assumption that it would be the easiest. It turns out a fair amount has changed since I did the original v8 port many years ago. Regardless, it's done with a bit more head banging than expected. Just a few notes for anyone who cares about this port. Testing: I haven't upstreamed all the bits I used for testing. In the simulator/binutils/newlib I've given the simulator an extra megabyte of memory. The inconsistencies caused by collisions in the various segments are painful to deal with. However, I have not upstreamed that change -- various comments lead me to believe the current memory map may be derived from real hardware. I haven't upstreamed a tweak in sim_fpu_neg where I think we're mis-handling negation of NaNs. I believe we're supposed to return a NaN with the sign flipped. But right now it just returns the original NaN. There's a couple places in the simulator that are not 64 bit clean, in particular handling of multiply and divide insns. These are v850 specific issues and I'll likely upstream these fixes. I suspect there's other 64 bit issues it the code. I'm not going to do a full audit of the v850 simulator. I'm pretty sure the v850 simulator mis-handles the "bins" instruction. But it's also the case that I don't have any documentation on that insn, so there may be some kind of restrictions that I'm not aware of. For testing purposes I disabled use of "bins". But I'm not upstreaming that hack. I believe I've found a bug in the FNMAS handling in tree-ssa-mathopts.c. I still need to go through the relevant parts of the IEEE standard to be sure. In the mean time I've got a little hack that guards the suspicious transformation on HONOR_SIGNED_ZEROs. [Whoops, sent the 01-03 messages, but not the cover... ] In the testsuite, there are many tests which simply use too much memory, even with the extra megabyte added. I'm currently guarding those with a hack. I'll probably upstream some kind of tweak here. I'm pretty sure newlib's sprintf is not compliant enough to pass builtin-sprintf.c's test. So that's guarded as well. Similarly there's a guard for trapv tests which want to use fork and one or two other oddballs. So, with those caveats, the tests look really good now. Essentially the only differences between the trunk and a converted port are the additional tests that we get a dumpfile from the compare-elim pass. Code quality: >From a code generation standpoint the trunk and the converted port are essentially the same when comparing libgcc and newlib. I've seen the converted port miss a couple compare eliminations due to the CFG shape changing after compare-elim. But there's other cases where we're doing a slightly better job at compare elimination -- in the end it's a wash. Style: The v8 does not have the ability to add two registers without changing the condition codes. So we don't expose the condition codes until after reload, except as clobbers. For insns where the condition codes are set in a useful manner we have define_insn_and_split patterns to handle the pre-reload and post-reload case (with and without clobbers respectively) as well as patterns which set the condition codes. A few insns do potentially set the condition codes in a useful way, but I haven't bothered to describe the condition code handling as it's unlikely to be all that important relative to the bloat they'd introduce in v850.md (for example the divide instructions). Future work With cc0 eliminated on the v850 port, it can potentially convert to LRA. I've done light testing which looks promising, but haven't looked at it extensively. I'll probably do the conversion since it looks so easy. If someone had an interest, they probably could do things like exploit the C bit to improve 64bit arithmetic. We're probably not using the tst1 and similar instructions very aggressively either. I'm not planning to work on either of these issues. I don't expect I'll do much, if anything, else on the v8 port. My son is currently working on the mechanical changes to convert the h8 port away from cc0. Jeff
