On 10/14/2010 06:27 PM, Uwe Hermann wrote:
On Thu, Oct 14, 2010 at 08:58:35AM -0700, Stefan Reinauer wrote:
On 14.10.2010, at 05:38, Joseph Smithjoe@settoplinux.org wrote:
Anyways why can't cpu specific features be implemented at the model level and not at the socket level???
Because SSE, SSE2 and MMX are not CPU specific features in this context. SSE and MMX determine how many registrers are available for romcc. It describes the lowest common denominator between all CPUs in a socket. If one model selects SSE and another one does not, it will still be enabled, thus breaking every other CPU you can put in that socket.
Yep.
Maybe we should drop those flags from Kconfig completely and just set the right ROMCCFLAGS in the socket's makefile to remove any confusion about the meaning of thos flags.
It's worth considering IMHO, yes. Or, actually, since sooner or later many chipsets will convert to TINYBOOTBLOCK and CAR (at least that's the plan I think), romcc will only ever be used for the bootblock, right?
And that's pretty tiny hopefully and should work just fine with 386 as romcc option? Do we actually really have any measurable advantages from using romcc options other than 386 in that case?
Same for RAM test -- it's not a memtest86 replacement, just a quick "Did I screw up RAM init" test, which doesn't get run very often after the RAM init code is finished / working. Does the RAM test speed really matter much here? Shall we just use 386 for ROMCC everywhere (and not use SSE2 for ramtest) and get rid of the MMX/SSE/SSE2 config options?
Good point Uwe, I like how you think :-)