[J-core] Adding J1 to the roadmap.

D. Jeff Dionne Jeff at SE-Instruments.com
Wed May 18 08:07:28 EDT 2016

I don't see any reason to loose TRAP or CAS.L on small implementations, there is only a tiny piece of circuitry for CAS bus locking.  Both are implemented in 'microcode' using the normal pipeline.   In the case of FPGA RAM (ROM) microcode, nothing is gained by removing instructions that don't have any special pipeline hardware.

Which reminds me, we should try switching the decoder from random logic (ASIC style) to FPGA BRAM style and see what happens to the size again for the logic constrained platforms, unless Geoff already has done.

On the other hand, I think the selective stripping or stripping down of pipeline appendages... barrel shifter, MAC unit, etc is a useful exercise in making the implementation as clean as possible.  The compiler support could be tweaked, but some instructions removed might require support in libgcc.a


> On May 18, 2016, at 20:07, Christopher Friedt <chrisfriedt at gmail.com> wrote:
> I like this idea.
> I know on Cortex-M0, the software interrupt (svc / swi), was hosed , and I felt it was a bit of a mistake for Cortex-M0 to silently ignore. The only suggestion I have for J1 is to not make that same mistake.
> From musl gitweb it appears that "trapa #imm" is valid for SH*, so I assume that an analog to the above is not the case.
> Would we keep the atomic CAS.L? Atomic instructions are nice to have.. for a lot of reasons
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20160518/13ed67cf/attachment.html>

More information about the J-core mailing list