Am Samstag, den 03.10.2009, 20:03 +0200 schrieb Peter Stuge:
Because you either introduce a dependency on ROMCC or you need additional assembler code.
I love Patrick's idea about generating macros from cmos.layout. With that, the additional assembler code would amount to maybe 15 instructions. Far from painful to me.
The thing is, there's code that isn't that pretty in assembly. K8 HT init comes to mind (necessary for rom mapping), so there is a use case for romcc in that model anyway.
But that isn't all that bad in my opinion: 1. we had much more trouble with gcc than with romcc.. If anything, gcc has to go ;-) 2. We're talking about a tiny piece of code here. The smaller, the better, so that even good, slow, unscalable romcc won't be too much of a burden. 3. We'll be using romcc for various projects anyway (eg. serialICE) - it's far from that, so we can use it where appropriate.
We have issues with romcc currently because we use it on a large set of files from many separate parts of the tree (the various bridges etc), and suffer from its constraints.
What I don't know is, do we require any chipset setup to _reach_ CMOS? Accessing it will be trivial, no matter if assembly or romcc.
Patrick