[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] trunk-09082010 file structure / content

It's interesting how different views people can have :) I just remind
you 'fat binaries' wasn't exactly the idea I had in mind, this was
only mentioned as possibility (and even not by me). What I basically
wanted was to get rid of things like:

# ifdef M68060
                        r = 0x0000003cL;        /* 060 kernel */
# endif
# ifdef M68040
                        r = 0x00000028L;        /* 040 kernel */
# endif
# ifdef M68030
                        r = 0x0000001eL;        /* 030 kernel */
# endif

You see, it's not only awkward to see something like this but it's
also harder to read / maintain / change (imagine someone would like to
redefine meaning of these numbers -- he would need to compile four
kernels (000, 030, 040, 060) to see if he didn't break something).
There are also other places in code like this. My idea was to make one
kernel, where this stuff would be detected in runtime -- i.e. code
wouldn't be #ifdef M68030 but if( some_variable_possibly_cookiejar ==
CPU_030 ). It's more code than #ifdef approach? Naturally, yes. But
only by a few KBs at max!

So, except some corner cases (like 000 build where "everything" is
really disabled and saves considerably more memory than 030 vs 040 for
example) you would lose maybe 30 KB of RAM in exchange of one, unified
code base.

And please note, this doesn't stop Alan / you / whoever to make
060-specialized build! You just use make CC='gcc -m68060' and you are
done. Only "unoptimized" thing will be that few KBs for runtime
detection. Is it really that much? Do you really want optimized kernel
to the last bit of memory? If the answer is yes, then we must keep
current #ifdef approach.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org