Vedran has quit [Quit: Ping timeout (120 seconds)]
Vedran has joined #forth
pbaille has joined #forth
pbaille has quit [Ping timeout: 252 seconds]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
actuallybatman has quit [Ping timeout: 252 seconds]
Keshl_ is now known as Keshl
<MrMobius>
dang, missed the 22V10 convo yesterday
<MrMobius>
im using a 16V8 for my current project which is the same just less pins
<MrMobius>
programming it with an ancient things called wincupl
<cmtptr>
no sorry it's over now, you can't talk about it anymore
<KipIngram>
:-)
<cmtptr>
what's the notation again? it's like NvM is N gates and M io ports or something?
<MrMobius>
hehe
<KipIngram>
i'm sure we oould talk some more.
<MrMobius>
22 pins with 10 input only i believe
<KipIngram>
I want to say, though, that I'm really struck by something. We all knew this - it was just a nice little showcase.
<KipIngram>
I'm working on BLOCK.
<cmtptr>
ah yeah that sounds right
<KipIngram>
I mentioned that yesterday I wrote the "fast path" for it, (BLOCK).
<KipIngram>
That's primitive and handles the case where the desired block is already resident.
<MrMobius>
I also thought about making a little CPU out of them but you would need a whole mess
<KipIngram>
So it's about 40 lines long all told.
<MrMobius>
of them
<KipIngram>
Then right below it I have 12 little tiny short Forth definitions, maybe 35-40 charcters long each, that does the WHOLE REST OF THE JOB.
<KipIngram>
Well, it doesn't do the syscalls, but it does all the organizing and getting ready, so that all that's left is a clean block-read and block-write.
<KipIngram>
And it looks like it's about 10% as big as all that assembly sitting there bove it.
<KipIngram>
Just so cool how "compressed" Forth can make our code.
<KipIngram>
MrMobius - I worked on that for a while, on paper.
<KipIngram>
A 22V10 Forth processor.
<KipIngram>
I got the equations all designed for 32 5-bit opcodes running a hardware stack.
<KipIngram>
And yes, you needed a mess of them.
<MrMobius>
do you remember about how many?
<KipIngram>
Yeah, it looked like six or seven dozen or something like that.
<MrMobius>
kind of a moot point these days since EEPROMs are dirt cheap
<MrMobius>
oh wow
<cmtptr>
lol
<KipIngram>
Well, it was "bit slice," so to speak.
<KipIngram>
You needed a bunch of each "design" to implement the word width.
<KipIngram>
I may have had two or three bits in each one - can't remember.
<KipIngram>
But I couldn't figure out how to make it work "going wide."
<KipIngram>
So I tried the other "orientation" and was able to find something that worked.
<KipIngram>
I bought the 22V10s, but never got it built.
<KipIngram>
They're in tubes in the garage now, over in a corner somewhere.
<KipIngram>
Story of my life - working out all the details on something but never building it.
<KipIngram>
I hope that changes when I retire.
<KipIngram>
The hardware stack was made that way too - each chip carried several levels of one data bit, and 16 of them sat side by side to make the word.
<KipIngram>
Fewer levels in the top elements per chip, because they had to be able to "do more" than the deep layers did.
<MrMobius>
holy moly
<MrMobius>
that is a crazy way to make that
<KipIngram>
I couldn't get the equations to fit any other way, is my recollection.
<MrMobius>
have you thought about using eeproms and ttl logic?
<KipIngram>
No, the 22V10 was about the most primitive level I ever got to.
<KipIngram>
But yeah, an EEPROM and a state machine - you could do it right up, couldn't you?
<KipIngram>
Another thing I once looked into, in the name of less logic, was a bit serial Forth machine.
<KipIngram>
Like when you did + you'd do it serially, one bit at a time, propagating the carry along with you.
<KipIngram>
So very slow, but very "narrow," so you could put a bunch of 'em in parallel.
<KipIngram>
I never got that very far along.
<KipIngram>
But you begin to realize that just handing the carry in an addition in a higher performance way is fairly expensive in terms of logic.
<KipIngram>
Add is eacy and cheap if you are willing to do it slow (ripple carry). But carry look-ahead gets to be a pretty big pile of logic for a wide word.
<KipIngram>
Software guys don't realize how much power they're playing with with that innocuous little +.
actuallybatman has joined #forth
<KipIngram>
The bit serial approach removed that hurdle completely, because you were going to do it slow ANYWAY.
actuallybatman has quit [Client Quit]
<KipIngram>
And you were getting a big payment for going slow - just one bit of ALU hardware.
actuallybatman has joined #forth
<KipIngram>
One bit of RAM, etc.
<KipIngram>
Anyway, other than the 22V10 effort, most of my tinkering with Forth processors has been FPGA-based; and I'd usually assume a device with 6-input LUTs (like the Spartan 6 line from Xilinx).
<KipIngram>
My big goal was always to have only one layer of LUTs between register outputs and register inputs, so I could get the highest possible clock speed.
<MrMobius>
im working on a 7400 design and using an 8 pin eeprom for the ALU
<KipIngram>
I think this kind of thing is a worthy way to spend some of one's time.
<KipIngram>
It's healthy for the soul. :-)
<MrMobius>
operands go in one bit at a time over spi. the chip goes up to 133mhz so the hope was to run it at least 8x faster than the rest of the system
<KipIngram>
Neat.
<MrMobius>
ya its a pretty fun hobby
<KipIngram>
Seriously, soul health aside, I think that kind of project does rally give you a good appreciation for the low-level nature of the stuff computers actually DO.
<KipIngram>
Understanding something like that just takes ALL of the "mystery" out of computers.
sts-q has quit [Ping timeout: 240 seconds]
<MrMobius>
on a certain level it does
<MrMobius>
i dont think i could build enough of those ttl computers though to understand the more sophisticated stuff :P
actuallybatman has quit [Ping timeout: 268 seconds]
<KipIngram>
Oh, sure - the DETAILS get very sophisticated, but yet it's still "just more of the same." People who know nothing about computers sometimes think they're "smart," but when you understand how they work you see how dumb they are.
sts-q has joined #forth
<KipIngram>
They can hardly do anything - they can just do it a whole slew of times faster than you can blink, and one can build a lot from that.
dave0 has joined #forth
dave0 has quit [Client Quit]
Zarutian_HTC has quit [Ping timeout: 265 seconds]
actuallybatman has joined #forth
actuallybatman has quit [Ping timeout: 268 seconds]
actuallybatman has joined #forth
proteus-guy has quit [Ping timeout: 240 seconds]
pbaille has joined #forth
pbaille has quit [Ping timeout: 252 seconds]
proteus-guy has joined #forth
gravicappa has joined #forth
proteus-guy has quit [Ping timeout: 268 seconds]
actuallybatman has quit [Ping timeout: 245 seconds]
actuallybatman has joined #forth
proteus-guy has joined #forth
actuallybatman has quit [Ping timeout: 252 seconds]
djinni has quit [Quit: Leaving]
djinni has joined #forth
pbaille has joined #forth
mtsd has joined #forth
Zarutian_HTC has joined #forth
xek has joined #forth
wineroots has quit [Remote host closed the connection]
mtsd has quit [Ping timeout: 240 seconds]
mtsd has joined #forth
f-a has joined #forth
Zarutian_HTC has quit [Ping timeout: 268 seconds]
tech_exorcist has joined #forth
f-a has quit [Read error: Connection reset by peer]
f-a has joined #forth
mark4 has quit [Remote host closed the connection]
mark4 has joined #forth
gravicappa has quit [Ping timeout: 240 seconds]
gravicappa has joined #forth
actuallybatman has joined #forth
Zarutian_HTC has joined #forth
f-a has quit [Read error: Connection reset by peer]
actuallybatman has quit [Ping timeout: 265 seconds]
Zarutian_HTC has quit [Ping timeout: 265 seconds]
f-a has joined #forth
f-a has quit [Read error: Connection reset by peer]
f-a has joined #forth
f-a has quit [Read error: Connection reset by peer]
f-a has joined #forth
proteus-guy has quit [Ping timeout: 240 seconds]
proteus-guy has joined #forth
mtsd has quit [Quit: Leaving]
pbaille_ has joined #forth
pbaille has quit [Ping timeout: 240 seconds]
pbaille_ has quit [Remote host closed the connection]
pbaille has joined #forth
pbaille_ has joined #forth
pbaille has quit [Ping timeout: 240 seconds]
pbaille_ has quit [Remote host closed the connection]
pbaille has joined #forth
pbaille has quit [Ping timeout: 252 seconds]
gravicappa has quit [Ping timeout: 240 seconds]
proteus-guy has quit [Ping timeout: 260 seconds]
proteus-guy has joined #forth
pbaille has joined #forth
pbaille has quit [Ping timeout: 260 seconds]
pbaille has joined #forth
f-a has quit [Read error: Connection reset by peer]
tech_exorcist has quit [Ping timeout: 268 seconds]
f-a has joined #forth
<cmtptr>
KipIngram, in your exit-based-programming forth, how do you like to handle errors? do you have a throw/catch, or do you return status codes, or what?
<cmtptr>
i tend to dislike throw/catch things, but handling return statuses in forth is tedious. i wonder if your conditional return paradigm makes it less tedious
<KipIngram>
Well, at the moment I haven't added any error handling beyond the usual errors that Forth checks for, and the normal Forth response is to print out some location information (block, line, col) and an error message and return to the interpreter.
<KipIngram>
That all works, and the system is restored to the state it had before the keyboard line that contained the error began interpreting.
<KipIngram>
If you mean how do I deal with user input errors in general in my applications, I really don't do much of that.
<KipIngram>
I have a sort of throw/catch mechanism that I added to this one I'm working on now.
<KipIngram>
But it's not necessarily for use only in case of error.
<KipIngram>
I used it when my FIND code found the desired word. There it is way down at the bottom of three nested searches, and it has your winning word.
<KipIngram>
I used the mechanism for it to "leap back up" to the top of the code stack in one shot.
<KipIngram>
So if you look at most of that code, it's only handling the case where the word isn't found. When I do find the word I hop over all of it.
<KipIngram>
I use this syntax:
<KipIngram>
In an outer word you use this construct: ... <| ... ... |> ;
<KipIngram>
Then many layers of software deep, you can put other copies of |>
<KipIngram>
if it hits one of them, it will continue to execute as if nothing has happened, but it's removed a bunch of stuff from the stacks, and the next ; will be equivalent to the ; after the first |}
<KipIngram>
I'm sorry. {| ... |}, not angle braces.
<KipIngram>
Both data and return stacks are resored to the upper state - the only thing you get from down below is the TOS item that's cached in a register.
<KipIngram>
So yuo can return one result.
<cmtptr>
so : baz ." baz1" |} ." baz2" ; : bar ." bar1" baz ." bar2" ; : foo ." foo1" {| bar |} ." foo2" ; prints "foo1 bar1 baz1 baz2"
<KipIngram>
That's my actual find, which is working and vetted.
<cmtptr>
go tit
<KipIngram>
I have a linked list of vocabularies - variable PATH gets me to it's start. Each of those list entries has a linked list of word names. And each word name is a string of characters. I thought it was a very compact bit of code for searching such an elaborate structure.
<KipIngram>
Down in line 11 is where you've found the right word. So the |} there, with the word pointer in the TOS register, uses |} to jump all the way back up to line 2.
<KipIngram>
If the word doesn't exist then you'll bubble your way back up as you hit the end of lists - you run out of stuff to search.
<KipIngram>
The { ... } without the | in the name are different - that's my stack frame mechanism.
<KipIngram>
Inside the { } I can use words s0 s1 s2 s3 s4 to access particular stack items.
<KipIngram>
The ones that were on top a {
<KipIngram>
at {
<cmtptr>
omg i like that
<KipIngram>
I LOVE that.
<cmtptr>
that's huge
<KipIngram>
That one thing has almost eliminated stack diddling from my code.
<cmtptr>
it's unbelievably simple locals
<KipIngram>
The } takes a parameter It restores the stack to the level it was at {, and then removes n more items, where n is the passed parameter.
<KipIngram>
Eliminates a lot of "cleanup" work in words.
<cmtptr>
yeah } is x86 leave
<KipIngram>
Feel free to plagiarize.
<cmtptr>
yeah this may have singlehandedly rekindled my interest in forth
<KipIngram>
Oh wow - well, I hope so. I honestly believe that these little htings have improved the system, and have improved my written code.
<KipIngram>
You should try out conditional returns too.
<cmtptr>
still on the fence about that. like i said earlier, i don't really like try/catch. maybe it's ptsd from tcl but i'm hesitant about callees that can influence state or control flow in the caller
<cmtptr>
i suppose in forth it's different because you view a collection of words as more tightly coupled than you generally do in other languages
f-a has left #forth [#forth]
<KipIngram>
I understand.
<KipIngram>
And that's exactly what those things do - it's their purpose.
<KipIngram>
In fact, when you call some of my words there's no guarantee you ever see control come back at all.
<KipIngram>
Some of my words will double return right back over you.
pbaille has quit [Ping timeout: 252 seconds]
<KipIngram>
It's almost like a conditional call (the single level returns, at least). Except you do pay the call/return price. But functionally it's exactly the same as a conditional call with the "logically reversed" condition.