[J-core] Jcore mailing list and tutrle board
rob at landley.net
Sun Jul 9 05:42:29 EDT 2017
On 07/07/2017 06:06 AM, D. Jeff Dionne wrote:
> Also keep in mind that as soon as you have 32 bit instruction words,
> your clean RISC (like) architecture starts to 'degrade' (maybe, my
> opinion ;). Much better to have a mode bit in the status register,
> for instance, and avoid variable length instructions... those can
> also double your external memory instruction bandwidth (which is
> important, see above).
For example, the j64 we roughed out still uses 16 bit instructions, it
just has an x86-64 style mode bit that interprets some of those
instructions differently, and has 64 bit registers (the top 32 bits of
which are masked out and not modified in 32 bit mode).
The different instructions are things like turning "load/store 16 bits
of memory" into "load/store 64 bits of memory" (meaning a 16 bit store
in 64 bit mode needs to become two 8 bit stores, but there are only so
many encodings so you gotta trade something off).
It is very much an x86-64 approach of mostly the same instructions in
the different modes (share as much circuitry as possible and make it all
_conceptually_ the same too), _NOT_ the Itanic approach of "let's glue a
couple of completely different processors together and have a toggle
indicating which one to use now".
The core of the x86-64 design team was the DEC Alpha design team. When
Compaq bought the corpse of DEC in 1996 they didn't do chip design so
didn't hire those guys, and AMD snapped them up and asked "if you were
going to do an x86 chip, what would it look like" and that was the
Athlon, then asked "if you were to expand it to 64 bits..." and they did
their first implementation (SledgeHammer) with just 10% more circuitry
than Athlon (part of which was adding 8 more general purpose registers,
but j-core already has plenty of those).
We used that as a frame of reference: those guys did their first 64 bit
implementation in about 10% more chip real estate on top of their
existing 32 bit design. It can be done, because it _has_ been done, so
that's the sort of thing we should be aiming for.
> - Radical ideas about register files are generally a no-no. SPARC
> tried register windows (fail) SH2A tried register page ideas (fail)...
And sh2a was not done by Hitachi. When Renesas spun off after Y2K it
inherited the superh intellectual property but the engineers who'd
created superh _before_ y2k all stayed at Hitachi. The sh2a, sh4a, and
sh5 designs came about years later, done by a completely different team.
So far j-core development has only tried for compatibility with the
More information about the J-core