[J-core] Roadmap (was Re: j2 llvm repo?)

Rob Landley rob at landley.net
Wed Feb 8 16:06:49 EST 2017

On 02/08/2017 11:43 AM, BGB wrote:
> On 2/8/2017 3:20 AM, Rob Landley wrote:
>> We also don't want too many instruction set versions floating around out
>> there confusing the compiler people, if we can help it. We have
>> --with-cpu=j2 right now, we'd like to keep versions to a minimum. Should
>> the FPU have separate 32 bit and 64 bit modes: from a VHDL build
>> perspective and fitting into less FPGA space, sure why not? From a
>> toolchain/standardized instruction set perspective: ick, pick one. So
>> what configuration granularity level we implement beyond the first
>> release is a judgement call we haven't had to make yet. (There's been
>> talk of menuconfig in the VHDL build, which would itself be rather a lot
>> of work to implement...)
> I guess it could be possible to maybe add support for a subset of the
> FPU, and then use traps (and emulation) for the rest?

I don't see any benefit to a "partial" FPU, when both gcc and the kernel
have had entirely soft FPU implementations on multiple targets for
years. (If you want soft float, do soft float.)

There are a number of things that can be done to try to fit j3 into a
smaller FPGA, but multiple implementations split the testing over
different codepaths and in theory we'd be working towards a J3 ASIC in
which the LX9 vs LX25 boundary's arbitrary.

We should get turtle out, do a good implementation that fits 2-way SMP
in LX25, and then worry about trimming down the UP version to fit in
Numato after we have it working. As soon as we have engineering cycles
to devote to this, which isn't this week.


More information about the J-core mailing list