proteus-guy has quit [Remote host closed the connection]
proteus-guy has joined #forth
nitrix has quit [Quit: Genius is one percent inspiration and ninety-nine percent perspiration]
nitrix has joined #forth
f-a has joined #forth
f-a has quit [Read error: Connection reset by peer]
f-a has joined #forth
Gromboli has quit [Ping timeout: 260 seconds]
f-a has quit [Ping timeout: 260 seconds]
Zarutian_HTC has quit [Ping timeout: 240 seconds]
f-a has joined #forth
pbaille has quit [Quit: Leaving...]
dave0 has quit [Quit: dave's not here]
tech_exorcist has joined #forth
Gromboli has joined #forth
siraben has quit [Ping timeout: 245 seconds]
guan has quit [Ping timeout: 250 seconds]
guan has joined #forth
siraben has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
joe9 has quit [Ping timeout: 265 seconds]
mark4_ has joined #forth
joe9 has joined #forth
mark4 has quit [Ping timeout: 240 seconds]
sts-q has quit [Ping timeout: 240 seconds]
APic has quit [Ping timeout: 240 seconds]
mark4_ has quit [Ping timeout: 240 seconds]
sts-q has joined #forth
mark4_ has joined #forth
gravicappa has quit [Ping timeout: 240 seconds]
Zarutian_HTC has joined #forth
gravicappa has joined #forth
gravicappa has quit [Ping timeout: 240 seconds]
gravicappa has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
APic has joined #forth
mark4_ is now known as mark4
Zarutian_HTC has joined #forth
f-a has quit [Ping timeout: 268 seconds]
f-a has joined #forth
<KipIngram>
Ok, question for you all. I'm setting up my block/buffer system so that I use a hash to narrow down the list of buffers a block is able to reside in to two, then I can quickly check those two to see if one of them is the one I want. The question regards the case where both of the candidate buffers are occupied, but not by the block that I want. So I'm going to have to replace one of them.
<KipIngram>
I'm implementing a simple least-recently used system for that - I'll always replace the block that has sat there untouched for the longest time.
<KipIngram>
Here's the question: if the least recently used block has been written to, so I'd have to write it before replacing it, but the more recently used block has not been written (so I could just replace it), which do I do? Should dirty/clean override least recently used?
<KipIngram>
I lean toward yes, but I don't have a crystal clear argument as to why.
<KipIngram>
I have a nasty feeling that the answer to this question depends on the nature of my current traffic - i.e., it's application dependent.
gravicappa has quit [Ping timeout: 252 seconds]
<lispmacs>
hi, I am working through Moving Forth. I was just wondering if anybody had a particular preference for ICT, vs DCT and SCT? I found ICT as a model kind of appealing, though I can see some performance disadvantages
<KipIngram>
I have a strong preference for IDT. I think there are certain things (one is CREATE / DOES> ) that implement more cleanly in IDT.
<Zarutian_HTC>
lispmacs: depends on the $NEXT assembler macro
<KipIngram>
I'm sorry - ITC.
f-a has quit [Ping timeout: 240 seconds]
<KipIngram>
I will say right out, though, that many many people like STC.
<KipIngram>
I think it's just almost automatic to regard it as higher performance, but that really depends on the details of the architecture.
<KipIngram>
I think people think "Oh, the hardware supports STC, so surely it's best."
<KipIngram>
And I think they're likely right in many/most cases.
<KipIngram>
Just not in every single one.
<Zarutian_HTC>
I like STC on dual stack machines but DCT or ITC otherwise
<remexre>
I mostly do DTC, since imo it's nice that colon words are just a special case of code words
<KipIngram>
ITC is what I've become most thoroughly familiar with over the years, so my opinion should be considered somewhat biased.
f-a has joined #forth
<remexre>
though yeah, I have worried about the branch predictor penalty vs STC
<Zarutian_HTC>
the subroutine call opcode often takes up one byte and the absolute address two, so you get lot of three byte instructions
<remexre>
heh, I live on aarch64, they're all 4-byte :)
<KipIngram>
remexre: That's an interesting point - I think I see what you mean.
<Zarutian_HTC>
on avr and others I prefer DTC
<KipIngram>
dave0's "NEXT == ret" approach has really impressed me - that's just slick as heck in my opinion.
<Zarutian_HTC>
KipIngram: re block: it also depends on how 'expensive' it is to write a block out
<KipIngram>
True.
<KipIngram>
I'm also thinking of including cuckoo hash at this level and dodging the whole question.
<KipIngram>
I.e., there would then be more than two buffers a block could live in.
<KipIngram>
There would be four - two from each hash method.
<KipIngram>
That mitigates the thrashing prospects quite a bit.
<KipIngram>
Best case access time wouldn't be impacted at all, but average access time would be lengthened.
<KipIngram>
I suspect writes to disk would be considerably less frequent in that scheme, which is probably enough to make it a win right there.
<KipIngram>
More work, though.
<Zarutian_HTC>
I do not recall where I read it, might been in Forth Dimensions, that one guy used tape as block storage.
<KipIngram>
I think with cuckoo, though, I would have fewer buffers.
<KipIngram>
Like instead of 256, it would be 240.
<KipIngram>
You'd need to eliminate the "diagonal" of the grid, so that no block got the same buffer # from both hashes.
<Zarutian_HTC>
but he had a modified casette 'drive' which could play the casette backwards
<KipIngram>
My very first Forth sort of did that - it had a 32 kB randisk and I loaded it from and to cassette.
<lispmacs>
I was wondering - author hinted that there were some advanced things that you could do with ITC since everything is an address - but he didn't go into details. I would imagine maybe writing a decompiler might be simpler...? or maybe it would be easier to modify/move-around code...?
<KipIngram>
That's not quite the same thing, though.
<KipIngram>
There the tape was just for offline storage.
<KipIngram>
Well, as I said, I've always found CREATE/DOES> easier and less klunky in ITC.
<KipIngram>
I think ITC is just the "closest to the origins" of Forth.
<KipIngram>
It really just stands to reason that an additional level of indirection would provide opportunities one could exploit, but I can't give you a full list right now.
<Zarutian_HTC>
and it had two sets of heads
<KipIngram>
Oh, INTERESTING.
<KipIngram>
If you ever run across that again point me at it.
<KipIngram>
I may look for that later, just for shoots and grins.
<KipIngram>
I like "clever."
<Zarutian_HTC>
re ITC: I am still somewhat facinated by opemfirmware fcode bytecode idea
<KipIngram>
I also find bytecode an interesting idea.
<KipIngram>
I don't think I'm interested in a pure bytecode system, but I keep wondering if it could be "integrated" into an ITC system in some useful way.
<Zarutian_HTC>
the idea was that pci devices had fcode drivers in accessible rom
<KipIngram>
lispmacs: My ITC system has a second pointer right there by the CFA pointer that points to the "parameter field" of each word.
<Zarutian_HTC>
no need to hunt down the driver from a disk or install it
<KipIngram>
So, definition points to called CFAs, the PFAs are right by the CFAs, the CFA points to code and the PFA points to the new definition.
<KipIngram>
And that structure makes me able to "revector" any word I want.
<KipIngram>
I can just change a words PFA pointer to point to a new definition, and that redefines EVERY INSTANCE of that word, everywhere. Even in already compiled definitions.
<KipIngram>
In fully traditional Forth systems you have to jump an extra hoop to get that revectoring capability, so you usually only do it with a subset of your words.
<KipIngram>
Of course, that's yet another level of indirection I have to thread through.
<KipIngram>
Every little bit costs.
<KipIngram>
The system still feels plenty snappy to me, though.
<KipIngram>
In a traditional ITC system the called definition list is right there immediately following the CFA, instead of there being another pointer involved.
<lispmacs>
i feel like from my perspective I wouldn't mind giving up some cycles to make a system more elegant and more hackable, though that might be a hard sell to others
<Zarutian_HTC>
re the tape drive: because each block on tape had lengthOfBlock, blockNr, blockData, lengthOfBlock it could seek backwards for the latest version of the block desired
<KipIngram>
So the only way you could redefine a word and affect prior usages would be to overwrite the definition with the new one.
<KipIngram>
And it might not fit.
<lispmacs>
KipIngram: that sounds appealing to me
<KipIngram>
It's very clean.
<lispmacs>
your approach, I mean
<KipIngram>
Well, if you're into elegance as you said, then you're somewhat like me.
<KipIngram>
So you might like the same sorts of things.
<KipIngram>
I'll show you what my next looks like.
<KipIngram>
next_c: geti rrW, rrIP ; Fetch next icell
<KipIngram>
radd rrW, rrHB ; Offset -> address
<KipIngram>
inci rrIP ; Bump instruction pointer
<KipIngram>
geti rrTMP, rrW ; Fetch CFA offset
<KipIngram>
radd rrTMP, rrBB ; Offset -> address
<KipIngram>
rjmp rrTMP ; Go there
<KipIngram>
Those are mostly macro names, but the comments tell you what's going on.
<KipIngram>
I have #defines to give Forth VM style register names.
<KipIngram>
My system is MacOS, which required those funky additions of rrBB and rrHB - you wouldn't need those steps in a Linux system.
<KipIngram>
You'd work with literal addresses, whereas everything stored in my system is offets. I have to add the base address of a region to each one to get the address.
<KipIngram>
So try to ignore that part.
<Zarutian_HTC>
tape drive: there was another guy that used a diffrent casette recorder and player that took these endless loop one way tapes
<KipIngram>
I think the same scheme in a Linux imp would just be missing both of the Offset --> address lines.
<lispmacs>
KipIngram: aside from those offset-related instructions, it looks pretty simple
<KipIngram>
:-) That's pretty fascinating. Seems like someone tries more or less everything eventually.
<Zarutian_HTC>
in that setup each block had servral locations evenly spaced around the tape
<KipIngram>
Yes. Compared to traditional FIG next it just has that one extra indirection.
<KipIngram>
Oh, but you don't see that here.
<KipIngram>
That extra level of indirection would be in the "docol" routine.
<KipIngram>
Sorry - so this is a completely traditional NEXT except for the Offset --> address lines.
<KipIngram>
And Apple force that on me.
<Zarutian_HTC>
so, each block had a version counter field in it
<KipIngram>
Yeah, I'm not fully grokking how these versions come into play yet.
<lispmacs>
Is there any trouble with "inlining" in a ITC system?
<KipIngram>
I used to wonder if you could do something like that endless one way tape with fiber optics.
<KipIngram>
Just have a repeater, that receives what comes out of the fiber and continually shoves it back in.
<KipIngram>
And however long the fiber was, if you wait a little while any piece of content will come by.
<KipIngram>
Just intercept what you need, replace what you want to replace.
<KipIngram>
I don't really see any immediate reason why that wouldn't work.
<Zarutian_HTC>
the tape the guy used was an hour long one but he could play it back at 4x speed
<KipIngram>
A km of fiber would spin every 3 us or so.
<Zarutian_HTC>
in extended memory he had a list of block nrs and their version
<KipIngram>
And say you worked with 5ns windows - that would store about 600 bits. So not much, I guess. That's probably the problem with it.
<Zarutian_HTC>
it meant that at power up he had to play the whole tape through for the system to discover which version nr was highest per block
<KipIngram>
Yeah.
<Zarutian_HTC>
but it meant that older versions of a block could be overwritten
<KipIngram>
Ah, I start to see now.
<Zarutian_HTC>
often with a diffrent block alltogether
<KipIngram>
That seems to bear some similarity to NAND flash strategies in data storage.
<KipIngram>
The write process there is sort of a continuous big loop through the physical storage. Over and over.
<KipIngram>
And you update logical to physical mapping however you need to as you go.
<Zarutian_HTC>
the neat thing regarding this recorder player was the read head was in front of the ereaser and write head
<KipIngram>
Because it was running backward?
<Zarutian_HTC>
nope this is the continous loop one
<Zarutian_HTC>
the guy figgured that he could record while playing back
<Zarutian_HTC>
so he built an decoder and encoder in hardware which meant that the stuff on tape was always being refreshed
<KipIngram>
Sure - why not?
<KipIngram>
I mean, two different spots on the tape - may as well do two different things. :-)
dave0 has joined #forth
<dave0>
maw
<KipIngram>
hey dave0
<KipIngram>
You missed it - I was plugging your
<KipIngram>
Forth earlier
<dave0>
hey KipIngram
<dave0>
oh cool!
<dave0>
thanks guy :-)
<Zarutian_HTC>
KipIngram: so he experimented with overwriting obsoleted block versions with the block buffer that was least recently used
<KipIngram>
Ok.
<Zarutian_HTC>
worked suprisingly well
<KipIngram>
I think if I rig up this cuckoo-hash equipped block buffer system, then essentially I won't have to write any blocks out until the buffers get around 95% full.
<KipIngram>
Which really means that most of the time I'll probably write stuff out when I quit.
f-a has left #forth [#forth]
<KipIngram>
With how large memories are on computers I can easily have more buffers than I'd ever really use.
<Zarutian_HTC>
what I do not get was why there were diy papertape readers but no punches
<KipIngram>
Hmmm. Was there just no good cheap way to implement the punches?
<KipIngram>
I could easily imagine reading a paper tape on the fly as it's moving, but how would you punch it while it was in motion?
<KipIngram>
Just really really QUICKLY?
<KipIngram>
Before it had time to move any significant amount?
<KipIngram>
Maybe you could punch with a wheel.
<KipIngram>
As the wheel rotated (rolled along the paper) the punch heads would come down in well-contained spots.
<KipIngram>
If you could control a whole bunch of punch heads around the periphery of the wheel, maybe that could work.
<KipIngram>
That would be a lot of punches, though.
<KipIngram>
I'm having trouble thinking of anything other than advance/punch, advance/punch... that would be easy to home brew.
<KipIngram>
Ah man - got to caught up in this and missed a 4pm time for a phone call.
<KipIngram>
I've joined now, though.
<KipIngram>
It's too entertaining around here, man.
<KipIngram>
So, if I add this cuckoo hash stuff I'm still going to structure things the same at the top-most level: