WickedShell has quit [Remote host closed the connection]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
mbomba has quit [Quit: WeeChat 2.9]
Gromboli has quit [Read error: Connection reset by peer]
gravicappa has joined #forth
mbomba has joined #forth
sts-q has quit [Ping timeout: 240 seconds]
sts-q has joined #forth
Rakko has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
jsoft has quit [Ping timeout: 256 seconds]
Zarutian_HTC has quit [Remote host closed the connection]
Rakko has quit [Quit: Leaving]
cantstanya has quit [Remote host closed the connection]
jsoft has joined #forth
cantstanya has joined #forth
larsb has joined #forth
<larsb>
Toy Forth question.
<larsb>
I have this CPU which has no indirect jumps.
<larsb>
This makes it awkwar to write a direct or indirect threaded Forth.
<larsb>
It also has no access to the contents of the built in hardware return stack.
<larsb>
How would you suggest to implement Forth on this machine?
mbomba has quit [Quit: WeeChat 2.9]
<inode>
larsb: which cpu?
<DKordic>
From the information you provided the hardware simply can not be _interactive_. That obviously does not mean that some forth dialect can not be ""cross-compiled"".
mtsd has joined #forth
<larsb>
inode: It's Marvin Minsky's TT2500, a Logo computer from the MIT AI lab.
imode has quit [Quit: WeeChat 2.9]
<larsb>
DKordic: One option would be to define a Forth VM and have the native code interpret that.
<larsb>
But I'm considering subroutine threading. There would be no >R R> accessing the real return stack. For a toy Forth that might be ok.
<veltas>
Is this an enterprise Forth?
<veltas>
Toy languages are the best anyway
<veltas>
Yeah I agree with implement some kind of VM
<veltas>
If you can edit machine's text live then that's a possibility as well, but I assume that's impossible?
<larsb>
Nothing enterprise about it. Just a hobby thig.
<larsb>
veltas, not it's possible. The code space is in a separate 16x4K memory, but it's run time writable.
<larsb>
So indirect jumps *could* be implemented by writing a runtime generated instruction to, say, location 0 and jump there.
<larsb>
But this sounds like a loss for a NEXT primitive.
dave0 has quit [Read error: Connection reset by peer]
dave0 has joined #forth
imode has quit [Ping timeout: 256 seconds]
mtsd has quit [Ping timeout: 240 seconds]
<inode>
larsb: do you have any documentation about that cpu? i saw your post on comp.lang.logo about it being a custom TTL design (sounds interesting) and the only hints about its instruction set i've found are in your MinskyForth/assembler.lisp file
<larsb>
The problem with this computer is that everything is on MIT backup tapes, and files can't be released without a lengthy process.
<larsb>
I have written a simulator which is online in my GitHub simh fork.
<larsb>
Presumably someone could clean-room document the hardware from that.
<larsb>
Side note: people still read comp.lang.logo? I thought it was dead.
<larsb>
This should give an idea what the hardware looks like: