Eric Smith eric at
Mon Jun 11 23:19:31 PDT 2007

Juergen wrote:
> 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.

Best regards,

More information about the Altogether-devel mailing list