[J-core] Linux on J1?

[Rob Landley]

On 08/02/2016 01:06 PM, Rich Felker wrote:
> On Mon, Aug 01, 2016 at 03:51:19PM -0500, Rob Landley wrote:
>> What would it take to build a J1 processor running Linux?
>>
>> What I mean by that is, presumably starting with:
>>
>>   http://lists.j-core.org/pipermail/j-core/2016-June/000204.html
>>
>> 1) Take the stripped down "should fit in ice-40 if the toolchain works"
>> config and build it for spartan 6 with the existing xilinx toolchain.
>>
>> 2) Add the DRAM controller back.
>>
>> 3) Audit the instruction set and decide what we want to keep/drop. Do we
>> want a microcoded multiplier, or have libgcc.a do it? We talked about
>> this a few times:
>>
>>   http://lists.j-core.org/pipermail/j-core/2016-May/000166.html
>>   http://lists.j-core.org/pipermail/j-core/2016-May/000169.html
>>   http://lists.j-core.org/pipermail/j-core/2016-July/000252.html
> 
> There would be at least a moderate software support burden for trying
> to make Linux & userspace run on something that's not SH-2 ISA
> compatible. Both GCC's FDPIC support and the kernel presuppose at
> least SH-2.

Then when stripping down the ISA we should take that sort of thing into
account.

One of the questions is how much J1 should take into account the
historical original SuperH instruction set (which sh2 was the sequel
to), and how much it should be based just on a cost/benefit analysis of
"chip real estate vs performance" (impact of doing without optional
things like the multiplier and barrel shifter).

I lean pretty strongly towards the second, but you have a point that
there's at least some legacy software support for the first...

> Since the kernel doesn't need FDPIC, one could audit it
> for SH-2 assumptions and remove them, then add traps to emulate full
> missing instructions for userspace in software; of course that would
> be painfully slow.

There's not that much assembly in the kernel. Most of the mandatory
stuff seemed to be startup code and locking, the rest there was C
fallback code for. (You'd know more than me, of course.)

As long as gcc has a good code generation strategy, we should be good? I
remember looking at this with jeff and one of the hardwired bit shift
versions was never used because gcc had an alternative instruction that
did the same thing. (Instead of <<1 it added it to itself?)

Designing j1 based on what a modern compiler needs to generate code
seems an obvious choice, and running Linux on it gives us a lot more
code to run through such an analysis. But possibly this analysis should
wait until basic superh support goes into llvm? (Dunno.)

> If we wanted GCC to support an ISA-subset J1
> directly, either FDPIC support should be added to the existing SH-1
> target (not too difficult but upstream would end up with extra mess to
> maintain) or J1 could be added as a new ISA level (complexity burden).

Presumably we'd want a "gcc -mj1" target, but we'd want that even if we
weren't thinking about trying to run Linux on it.

> If microcoding is practical, I think that makes a lot more sense. It
> should both perform better and avoid big software dependencies.
> 
>> 4) Tweak gcc/binutils to add a target to produce the right instructions.
>>
>> 5) Tweak the kernel assembly.
>>
>> 6) Boot Linux on a Numato board with J1.
>>
>> Now here's the really funky question: If we just use prefetch instead of
>> icache/dcache, could we SMP J1 on Numato? (And/or fit in one instance of
>> the DSP?)
> 
> Disabling dcache is a huge hit to performance.

I also forgot that CMPXCHG and our memory barrier stuff is currently
implemented as cache tricks. Right now we CAN'T do SMP without the cache.

> It might be more
> practical to do a shared-dcache implementation for SMP, where both
> cores are accessing the same cache (even if subject to stalls when
> both access it at the same time) that would allow all the snooping
> logic (and half of the cache memory size) to be omitted.

I'm not sure what actually saves resources in the FPGA, the SRAM banks
are there either way. (Wiring them up takes the kind of cells we tend to
run out of...)

> Rich

Rob