Mats Erik Andersson wrote:
I did try to introduce other reductions further into the code base, but I was not successful in getting compilable code until I removed the assignment
device = ctrl->channel0[0];in favour of explicit calculations in this very file i440bx/debug.c.
Instead of the present patch, I also tried some variations in using a macro to perform the replacement of the original variable 'device' (meant to improve readablility), but some of those caused romcc to get stuck in a seemingly infinite loop, so there is something wrong with the parsing performed by romcc.
There are a couple of debug defines you can activate in romcc. But keep in mind that romcc indeed takes forever because it can not spill registers to any memory. I've seen romcc run 10 or more minutes before it failed/succeeded compilation.
Now, I would like to know, if the kind of code that the present patch introduces is at all acceptable by the project. In particular, it is that repeated 'ctrl->channel0[i]' that comes to my mind.
There's nothing principally wrong with it, but I suggest that for a chipset as simple as the 440BX, you drop the ctrl structure completely. The original author tried to mimic a scenario that is required on the AMD K8 where you have several memory controllers and the SPD roms are not assigned to fixed addresses. Instead of getting the actual values via indirections and arrays, just assume they're at 0xa0 + 2 * i and you'll be fine.
Also, did you evaluate the possibility of using cache as ram on the system? That would get rid of the register pressure completely because you can use the processor cache as your stack.