J1VM

Moderator: timpart

J1VM

Postby timpart » Fri Feb 15, 2013 8:40 am

I took a quick look at the design document http://excamera.com/files/j1.pdf

Here are some notes that might help Forth novices figure out what is going on.

There is a data stack and a return stack. These are both push down stacks, and words operate on the top most entries

Word definitions start with : wordname and end with ;
The ; indicates the word returns to its caller at that point and ends the definition. The word EXIT has the same return to caller function and would be compiled into the definition by ; The J1 machine code often allows the EXIT to be merged into the preceding instruction.

Here are some explanations of the Forth words mentioned in TABLE III
The stack before and after is shown by -- separating the two. The text on the right of each half is the top of the stack. There may be other more deeply nested values on the stack but they are unaffected by the word.

So + (plus) is shown as n1 n2 -- n3

DUP "dupe" duplicates the top entry of the stack pushing a copy of the top entry onto the stack
n1 -- n1 n1

OVER makes a copy of the secondmost entry f the stack pushing it onto the stack
n1 n2 -- n1 n2 n1

INVERT bitwise inversion of the top of stack
n1 -- n2

+ "plus" add together the top two entries of the stack and put the result there
n1 n2 -- n3

SWAP exchange the top two entries of the stack
n1 n2 -- n2 n1

NIP remove the secondmost entry from the stack
n1 n2 -- n2

DROP discard the top of stack
n1 --

; (well actually EXIT) Pull the top entry off the return stack and resume execution at that location
R: n1 --

>R "to R" take the top entry off the data stack and push it onto the return stack. Rather specialist this one.
n1 -- R:vv -- n1

R> "R from" take the top entry off the return stack and push it onto the data stack. If you use >R must do R> before doing an EXIT or you'll have a crash most likely.
R: n1 -- -- n1

R@ "r fetch" make a copy of the top of the return stack and put it on the data stack
R: n1 -- n1 -- n1

@ "fetch" the top of the data has a memory address. Fetch a word of data and replace top of stack with it
a1 -- n1

! "store" the top of the data stack has a value and a memory address. Store the value there
n1 a1 --

OK onto J1 itself
T seems to be a register holding the top of the stack (a common optimisation). I don't think it changes as the stack does but might be wrong
N seems to be whatever the rest of the data stack has at the top at the moment. Changes as data stack depth changes
R seems to be whatever the top of the Return stack has at that moment. Changes as return stack depth changes

Conditional jumps use zero for FALSE any other value is TRUE. The formal value for TRUE is all bits set and is returned by words like <

So it is a matter of writing an emulator for it.

Hope this helps
Tim
timpart
 
Posts: 302
Joined: Mon Dec 17, 2012 3:25 am
Location: UK

Re: J1VM

Postby timpart » Thu Feb 21, 2013 2:19 pm

The J1's ALU instruction has a host of bits and adjustment values. However the order in which they are executed is important or the results will be strange.

I've looked through the examples given and believe the order should be

1) Set T prime to the ALU operation (one of sixteen possibilities - see Table II). In parallel Move N to address held in T if N -> [T] bit is set
2) Adjust the data stack pointer by the signed amount given
3) Move T -> N if that bit is set. In parallel more R to program counter if R -> PC bit is set
4) Adjust the return stack pointer by the signed amount given.
5) Move T to R if that bit is set
6) Move T prime to T

While reading Table III I noticed that there are a couple of typos. Neither r> nor r@ should be doing T -> R. This is confirmed by a more detailed version of implementing Forth words elsewhere on the site.

Tim
timpart
 
Posts: 302
Joined: Mon Dec 17, 2012 3:25 am
Location: UK

Re: J1VM

Postby eleitl » Tue Jun 03, 2014 10:43 am

Do you think the Zynq 7020 is big enough to implement J1, and keep eLink/HDMI?
eleitl
 
Posts: 25
Joined: Mon Dec 17, 2012 3:22 am

Re: J1VM

Postby timpart » Thu Jun 05, 2014 12:11 pm

eleitl wrote:Do you think the Zynq 7020 is big enough to implement J1, and keep eLink/HDMI?

I know very little about FPGAs. The page for J1 says it fits easily in a small Xilinx FPGA but doesn't say which model. The requirements look modest, so I'd be hopeful it would fit, but the only way to find out is to give it a go. Not sure whether the 16K of RAM can use the FPGA internal RAM or that is tied up with something else. The only other potential snag I can think of is the clock speed, if the design won't run with the speed used currently.

Tim
timpart
 
Posts: 302
Joined: Mon Dec 17, 2012 3:25 am
Location: UK

Re: J1VM

Postby 9600 » Thu Jun 05, 2014 1:04 pm

timpart wrote:The only other potential snag I can think of is the clock speed, if the design won't run with the speed used currently.


I imagine it would be trivial to implement a clock divider (for those who do know how to program FPGAs).

Cheers,

Andrew
Andrew Back (a.k.a. 9600 / carrierdetect)
User avatar
9600
 
Posts: 997
Joined: Mon Dec 17, 2012 3:25 am

Re: J1VM

Postby svartalf » Tue Jun 10, 2014 7:26 pm

eleitl wrote:Do you think the Zynq 7020 is big enough to implement J1, and keep eLink/HDMI?


Heh... The J1 will fit into a Spartan3 FPGA. The 7020'll allow it and quite a bit more. Hell, a ZPU should fit nicely in there as well. It's similar in nature to a J1, 32-bits, and has a GCC toolchain for it if you don't want to implement a Forth for it.
svartalf
 
Posts: 50
Joined: Thu Oct 03, 2013 4:06 pm

Re: J1VM

Postby svartalf » Tue Jun 10, 2014 7:28 pm

timpart wrote:
eleitl wrote:Do you think the Zynq 7020 is big enough to implement J1, and keep eLink/HDMI?

I know very little about FPGAs. The page for J1 says it fits easily in a small Xilinx FPGA but doesn't say which model. The requirements look modest, so I'd be hopeful it would fit, but the only way to find out is to give it a go. Not sure whether the 16K of RAM can use the FPGA internal RAM or that is tied up with something else. The only other potential snag I can think of is the clock speed, if the design won't run with the speed used currently.

Tim


It fits (originally) into a Spartan3 and is used as part of a game/graphics coproc for the Arduino, called the GameDuino. It should comfortably fit several times over in more advanced/capable FPGAs like the 7020- and it's supposed to be able to use BRAM for memory.
svartalf
 
Posts: 50
Joined: Thu Oct 03, 2013 4:06 pm

Re: J1VM

Postby timpart » Fri Jun 13, 2014 6:12 am

svartalf wrote:It fits (originally) into a Spartan3 and is used as part of a game/graphics coproc for the Arduino, called the GameDuino. It should comfortably fit several times over in more advanced/capable FPGAs like the 7020- and it's supposed to be able to use BRAM for memory.

That sounds promising. I wonder how easy it would be to create more than one instance? One aspect of running Forth in software on the Epiphany is that you have 16 cores to run on at the same time vs one FPGA. If the FPGA could run more than one J1 that would be interesting.

RAM might be the biggest constraint, so would be useful to share the address space, at least enough so that the unchanging word definitions' code is mapped into every processor.

Tim
timpart
 
Posts: 302
Joined: Mon Dec 17, 2012 3:25 am
Location: UK


Return to Forth

Who is online

Users browsing this forum: No registered users and 0 guests