Access macros (was Re: Status)

Juergen Buchmueller pullmoll at
Tue Jun 12 11:35:49 PDT 2007

On Tue, 12 Jun 2007 10:43:57 -0700 (PDT)
"Eric Smith" <eric at> wrote:

> Aside from endianness, which has already been addressed, why do you
> think using macros is better?

Because "everyone" does. I've seen macros being used throughout many parts
of kernel code of various OSes (for example Linux and *BSDs), specificially
in the sections addressing SCSI oder IDE bus bit fields. I've seen then in
MAME, and I've been sticking to using them in all my code.

My idea is that the people who wrote this (kernel) code had their reasons to
use macros instead of C bit fields.

I believe the C bit fields were, despite their usefulness at the first
glance, avoided like hell in code that has to be portable across host CPUs,
because it has (or had) to be portable even across various compilers.

> The change I would be most inclined to make would be to change
> current_uinst from being a pointer to being the microinstrucion
> itself.

IMHO this is a "Good Idea(tm)" :-)
Accessing a simple global, and even accessing just some of its bits, is
definitely going to be faster than fetching a pointer, and only then
fetching some word at an fixed offset from this base.

> At this point I'm more concerned with correctness than minor
> optimizations, so your findings on the shifter, video, etc. are
> very much appreciated.

Well, my primary concern was, as I said, the readability of the source for
someone like me, who wants to verify the code with the documentation and
schematics. I doubt the code produced by the macros is expensive compared
to the C bit fields, plus you can easily define overlapping fields with
macros. To achieve that would be difficult with the C bit fields - sure, it
can be done using a union...

All this was, of course, just a suggestion, and not a request for a change!

Juergen (back to ksec and kwd :)

More information about the Altogether-devel mailing list