[J-core] Jcore mailing list and tutrle board

[Rob Landley]

On 07/09/2017 12:23 PM, BGB wrote:
> On 7/9/2017 4:42 AM, Rob Landley wrote:
>> 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).
> 
> mine can work basically like this, but using 2 bits:

I'm tired of this. No, yours can't "work". Your chip _does_not_exist_.

1) What you have is yet another emulator. The j-core devs have "add
better j-core support to QEMU" on the todo list, because that's the
current best of breed, but even that hasn't been a propriority yet. QEMU
can run the j-core userspace code on an sh4 board emulation (modulo
cmpxchg), there's GHDL and NVC doing simulation from the VHDL, and an
FPGA implementing the hardware and running Linux, and the next priority
for us is doing an actual ASIC.

We're not looking at using mame/mess's superh emulation, or adapting
bochs or valgrind, or licensing evolution or omnimaga or gxemul or
renesas' emulator or... (emulating the sega saturn and dreamcast are not
a new idea) because those are all less interesting than QEMU. The _hard_
part of emulator design isn't the processor emulation anyway, it's the
rest of the board support. (Xen and kvm and virtualbox copied QEMU's I/O
devices, not dyngen or tcg.)

2) You haven't got a chip. You're not designing a chip. There is no FPGA
implementation of your design, no plan to ever make an ASIC out of it,
and my understanding is it's being designed by someone who doesn't have
any idea how to do those things, and isn't even currently learning how.
Thus the new instruction set designer doesn't know what does and doesn't
make an efficient hardware design (and what "simple" changes screw up
routing or contend for hardware resources or would require adding
pipeline stages... the sort of thing Jeff politely tried to bring up
last message and you ignored yet again).

3) Even if you did actually implement your brand new design, why would
that have anything to do with j-core? There are a dozen licensed ARM
variants out there, the Qualcomm Scorpion (in the Snapdragon SOC in
bunches of Android phones) isn't the same as the TI Omap or Davinci
stuff, which is not the same as Atmel's or Freescale's ARM designs.

If you came to the j-core list and asked us how to get a kernel running
on a Sega Saturn, we'd go "dunno" and point you at some Saturn guys. If
you wanted to revive some sh2 reference board from the late 90's and get
Linux running on it, we'd probably try to help for a bit (we know
several superh veterans in Japan) but after a while we'd declare it off
topic and ask you to find somewhere else to talk about it. We're happy
to be inclusive, but you haven't forked off of our code. You've sort of
thrown out what we did and started over, except you're not even doing
alternate hardware. There's no VHDL or verilog, there's just.... an
emulator for a chip that doesn't exist.

And you've been going on about it for a year, responding to all our
"we're thinking about doing this" with "but I did this!". No you didn't.
You don't have a chip. You're not making a chip. You don't know how to
make a chip. You don't know what's _involved_ in making a chip. You
don't know what constitutes a good chip vs a bad chip design decision.
And you're not here to learn, you're here to TELL us about what you
"did". You're telling our _hardware_guys_ about your _emulator_ and you
honestly don't understand why that's not helpful.

You have never once commented on our actual j-core VHDL code, or about
programming for our SOC, the state of kernel support or
gcc/binutils/llvm support or libc support for our stuff (vs historical
sh2). Your second ever post here was about your emulator and it's all
been output ever since. Your _third_ post started with a reply to "I
might suggest you try improving support for SH2 / J2 in Qemu rather than
writing your own emulator." and you basically said why you _weren't_
doing that.

You don't ask questions about "what would happen if X change was made",
or "why is this better than that". You make sweeping pronouncements
about entire new designs that have nothing to do with any hardware (old
or new). You are acting as an authority based on your ability to imagine
an instruction set variant nobody with any hardware experience has ever
even tried to implement, because you wrote a bytecode interpreter in
software. (I did that too back in college, and then the next year Sun
released Java and I went "oh" and proofread their API (which was missing
the "truncate" command, they added it in 1.2 because of my bug report).

Bytecode was a new idea back in the 1970's, now it's really old hat:

  https://en.wikipedia.org/wiki/Bytecode

We already have a 64 bit approach for j-core that our hardware guys
think is reasonable, but they haven't put in the work to prototype it
yet because we're up to our neck in DSP and GPS related deadlines for
people who want to give us money for the results (other hardware
entirely), plus we're trying to get turtle out the door and support it,
and when we cycle back around we have j1 and j3 waiting for us to finish
them. (Plus I need to completely update the website docs, clean up the
third vhdl tarball for release review, and I don't think our ethernet
driver ever went upstream into vanilla? And vanilla's serial emulation
is still enabling a UART buffer QEMU doesn't emulate and I need to get
those guys talking to each other...)

You're clearly very enthusiastic about your project. Why don't you start
a mailing list for your project, and post about it there? It's not on
topic here.

> mine was also about like x86-64.

> 1: in my tests,

> as noted before, in my design

me me me me me

https://www.youtube.com/watch?v=g0lbfEb8MMk#t=3

> will need to work on more on my compiler and similar before 64-bit

We're trying to add support to existing projects like gcc and llvm and
qemu and linux. You're trying to invent your own machine language with
your own compiler and your own emulator and your own operating system.
Could you find a place other than here to do it please?

> about the only things my design had borrowed

> most of the rest I left out, seeing little obvious use.

> the base design for my design

> I have mixed feelings about the mechanism

> I think the idea is that

> I previously considered a different strategy:

Rob