[J-core] J-core address errors and other questions

[Rob Landley]

On 07/12/2016 07:48 AM, Robert Ou wrote:
> Hi,
> 
> I am interested in possibly using the J2 core for some of my projects.
> I am currently trying to see how difficult it would be to add a simple
> base and bounds MPU with a fixed number of regions.

We plan to implement an sh3-compatible MMU sometime next year, but all
the notes about that with any sort of detail are in Japan and Canada,
and I'm in Texas.

> However, it is not
> entirely clear to me how the exception logic in the core works and how
> I can correctly trigger a bus abort.

In general the nommu version runs correct code, but doesn't particularly
check for incorrect code. (Since the most common type of incorrect code
is an out of bounds memory access, there didn't seem much point.)

Lots of these checks need to be added for the j3 and j4 versions listed
on the roadmap, but our short-term focus (other than using this thing
for some commercial projects that involve actually making a batch of
test ASICs later this year) is getting J1 working, which is mostly
toolchain work.

Once we've scaled it down into arduino country, then we work on scaling
it up into mmu, FPU, multi-issue, eventually 64 bit territory.

(Oh, there's also a DSP design going on in parallel, which is equal
parts elegant and hideous and which I believe we plan to open source
once we get it working. But actually programming the sucker is... ask
jeff to walk you through the "fourier transform butterfly diagram"
sometime. That's eating a lot of development cycles too, but it's needed
for above commercial projects...)

What we REALLY need to do now that we're transitioning from "everything
is on fire" back to something like a normal schedule is get the
repository converted and up on github. I handed it over to Rich Felker a
month or two back, who so far hasn't managed to make any more progress
than I had, but he might just have been too busy with above deadline
fires. (Moral of the story: never use mercurial subrepos.)

> I am also trying to understand why the microcode operations for
> illegal instructions and interrupts are a) the way they are and b)
> quite different.

There are a lot of todo items. The first goal was to get it to run nommu
Linux with a known userspace, which means it shouldn't have illegal
instructions. Then we made it faster (implemented cache) and added SMP
support (which historical sh2 didn't have).

If you want to send us a patch, we'll happily merge it. (I want to make
one more pitch to Jeff to use 0bsd instead of 2bsd first, of course. :)

> From what I understand of the microcode, the handling
> of an illegal instruction is essentially:
> 1. Decrement PC by 2 or 0 so that it points at the next instruction
> (isn't decrementing by 0 pointless?)

It's a NOP. Sounds like it's making the decrement conditional?

> 2. Store SR at *(--R15)
> 3. Store PC at *(--R15)
> 4. Read from VBR+off
> 5. Do nothing (wait for reading to happen?)

Most likely. That's probably a Geoff question.

> 6. Update PC with value read
> 7. Make IF fetch from this new address
> 8. Poke instruction dispatch? (I don't quite know what this does as I
> don't have a complete picture of all the pipeline control signals yet)
> Meanwhile, the handling of an interrupt seems to be:
> 1. Decrement PC by 2 so that it points at the next instruction. Also
> acknowledge interrupt and remember the current interrupt level
> (where?)
> 2. Transfer R15 to TEMP0 (What does FC in the ALU X do? Why is the
> TEMP0 necessary? Why couldn't R15 be used directly? Why doesn't
> illegal instruction require TEMP0?)
> 3. Store SR at *(--TEMP0)
> 4. Store PC at *(--TEMP0)
> 5. Read from VBR+off
> 6. Decrement R15 by 4 and also change interrupt mask level. (Meanwhile
> waits for reading to happen?)
> 7. Update PC with value read
> 8. Decrements R15 by 4 again (couldn't step 6 just decrement by 8?),
> and also makes IF fetch from the new address.
> 9. Does nothing?? (Why doesn't it poke instruction dispatch like an
> illegal instruction?)
> Is this approximately correct? Could someone clarify the points I am
> unclear about?

Geoff or Jeff presumably could, or Niishi-san. Me alas, not so much.

> As an unrelated question, I would also like to know what happens when
> the CPU attempts an unaligned read/write or a jump to an unaligned
> address. From what I can see, the CPU just seems to assume that this
> doesn't happen and essentially would end up incorrectly rotating
> various bits around when an unaligned access is attempted. Is this
> accurate or did I miss a check for alignment somewhere?

Nope. If it's not needed to run the code we've fed to it, it probably
isn't doing it yet. But j3 or j4 should add that.

> Robert

Rob