[f-cpu] (!) a few noteworthy things

[Yann Guidon <whygee@f-cpu.org>]

hello,

- under popular demand (more than 500 hits on the french version),
i will do my best to make an english translation of the document
i recently presented, which describes some of the FC0 internals.

- the SIMD flag still creates problems.
Partial writes to a register are handled but bypass conditions are
a major headache, and this has a big impact on the "zero flags".
We should not forget the potential troubles that this choice
can make on future architectures. Here are the existing possibilities :
 a) specify that the high part is unchanged
   (only the low byte/word/dword/etc. is updated)
  --> this is the current approach.
 b) specify that the high part is cleared --> simpler solution
 c) specify that the high part is sign-extended
    (sign extension might create troubles like those of the
     current solution
 d) specify that the SIMD flag has no effect at all and the
   high part is updated with the rest of the word (just like a
   normal SIMD operation would do)
 e) specify that the flag return an "undefined/reserved" behaviour
   for the MSB (could be both dangerous and safe, it would force
   compilers to generate valid pointers all the time)

Also don't forget that usually, the MSB is not critical :
when you operate on bytes or short ints, all the operations
on that variable will have the corresponding/correct size flag
and the rest of the register won't matter ...

However it is important to consider the implication on the Xbar
and the decoding logic, when bypass is required. d) and e) simplify
the design because we don't have to choose subword results.

For example,
 * if the result of an operation is 0x0123456789ABCDEF
 * the operation had a byte as size
 * the previous value of the destination register was 0xFEDCBA9876543210

then on bypass the new value will be
 a) 0xFEDCBA98765432EF (there must be another MUX to select between the old
     and new value)
 b) 0x00000000000000EF
 c) 0xFFFFFFFFFFFFFFEF
 d) 0x0123456789ABCDEF
 e) 0x??????????????EF

personal notes :
 a) is possible but a bit complex.
 b) is simpler but still requires a mux (so a) would be the same)
 c) is a bit like b but the sign must be propagated :
     more complex because we must choose between at least
    3 sign bits (corresponding to a 8, 16 and 32-bit result)
 d) is plain simple and would be a choice except that it would confuse compilers
 e) is a "failsafe" solution that would allow the implementor to choose between
    a), b), c) and d) on a case-per case basis. This is some more pressure on the
    compiler but i guess it's still manageable.

As long as the debate is not closed, e) would be a safe bet before a) is completely
supported and implemented. However it would become a problem, for example when
the result is a byte and the next operations needs an int -> the unknown parts
should be explicitely extended...


- concerning the debate on the CAM of the LSU&Fetcher,
there might be a "middle way" and a firtst approach, consisting
of defining a primitive/generic CAM component, defined using
sequential or abstract constructs in VHDL. Then, specific
"architectures"/implementations could be created, which match
specific technologies (ASIC/FPGA). I hope that it can give
a "happy end" to this story.

Maybe when it's ready, someone could synthesise several versions,
and we'd choose the best architecture...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/