eric at brouhaha.com
Mon Jun 11 23:19:31 PDT 2007
> I just subscribed this list, after I got
> Eric's preliminary source compiled and running on my machine. Wow!
Welcome! It is great to have another person contributing!
> I took me some time to write down my own Makefile, as I don't know
> anything about the development tool that uses SConscript files.
It's called SCons:
> I think it may be
> faster to access static arrays by an index (current_upc), rather than
> to dereference elements of a global, or passed into functions, pointer to
> a struct. I may be wrong here, though.
Possibly. The uinst_t struct is composed of bit fields that should all
wind up in a 32-bit word, so I'd expect the compiler to pass those around
as efficiently as a uint32_t. I haven't looked at the generated code.
> Also, the use of specific uint16_t for all the word sized variables and
> function arguments is certainly adequate documentation-wise, while it will
> cause the x86 to do many type cast conversions like "movzx" or "movsx",
> which are (or at least were) slower than plain 32bit transfers. The latter
> many times map to just register renames in the x86 core.
I'd rather replace it with uint_fast16_t, then. I think I'd be inclined
to do this:
typedef uint_fast16_t uword_t;
There are probably places in the code that will require explicit masking,
since the uint_fast16_t will most likely compile to 32-bit or 64-bit
> I think there's a bug in cpu.c line 654. I believe it should read:
> shifter_function = (ir >> 6) & 3;
> while you have "& 2" there.
Yes, looks like a bug, thanks.
I'll have to study your other changes in more detail.
More information about the Altogether-devel