<veltas>
(just set iterator to limit, so the next LOOP/+LOOP falls through)
<crc>
joe9: still needs X11, which I don't have on my systems
<crc>
none of this matters though; I'm writing an editor for my own use, which will suffice and be written in Forth
* crc
intends to be done this by early summer
<veltas>
The nicest approach I can think of has a runtime cost and slight overhead for DO
<veltas>
i.e. add the leave address next to iterator/limit on return stack
<veltas>
Alternative is to have some kind of loop or leave stack, potentially link multiple LEAVE's through code to resolve at corresponding LOOP, which is all gross
<veltas>
fig-forth had the right idea with a LEAVE that requires a bit more care in use, but is infinitely simpler in implementation. That's the forth way really
<MrMobius>
the way I implemented it is a separate stack for structures at compile time. every LEAVE pushes it's address and type then LOOP pops repeatedly until it finds a an address of type DO. update all the addresses for the LEAVEs and error if another type like IF is found
<MrMobius>
doesnt seem to be a common way to do it though
<MrMobius>
I suppose you could have some valid reason to do DO FOO IF LOOP THEN BAR LOOP
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
f-a has quit [Ping timeout: 272 seconds]
f-a has joined #forth
dave0 has quit [Quit: dave's not here]
Zarutian_HTC1 has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
f-a has quit [Quit: leaving]
_whitelogger has joined #forth
Zarutian_HTC1 has quit [Ping timeout: 240 seconds]
Zarutian_HTC has joined #forth
gravicappa has joined #forth
jedb_ has joined #forth
sts-q has quit [Ping timeout: 260 seconds]
jedb__ has quit [Ping timeout: 264 seconds]
jedb__ has joined #forth
jedb_ has quit [Ping timeout: 256 seconds]
sts-q has joined #forth
dave0 has joined #forth
wineroots has quit [Remote host closed the connection]
_whitelogger has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
wineroots has joined #forth
<veltas>
MrMobius: There is a valid reason but there are workarounds (assuming middle LOOP was meant to be LEAVE)
<veltas>
Like just wrap end part in an IF..THEN, or use BEGIN..WHILE..REPEAT etc instead
<veltas>
Yeah a LEAVE stack is a way I considered, it would have to be pretty much what you said, I can't think of another way. I have opted for three items on the return stack because it seems like the simplest overall solution
<veltas>
ANd the overhead is minimal and doesn't affect the amortised loop overhead (apart from using 2 bytes more return stack, and 1 byte more with plain DO)
<nihilazo>
I am interested in fossil but idk really about how much I gain from moving to fossil, it just seems to be simpler than git while also integrating the stuff that is currently messy with git (like issues over multiple hosts, etc)
f-a has quit [Ping timeout: 265 seconds]
f-a has joined #forth
<veltas>
f-a: git or just .tar.gz snapshots
<veltas>
My VCS requirements are extremely basic personally, I use perforce and git at work and I prefer git there.
<veltas>
With 8KB RAM, and assumption that any game will have essentially all code in ROM, and no keyboard, it is not surprising to me nobody has made a full interpreter forth for gameboy
<veltas>
As far as I know anyway
<nihilazo>
yeah, a full interpreter doesn't make too much sense
<veltas>
But there's no reason you can't make one, I think it would be quite a cool thing on a real gameboy if you had a way of writing the ROM
<nihilazo>
a compiler is cool though
<nihilazo>
you could put writable memory inside a cartridge
<nihilazo>
that's what, eg. LSDJ does for song memory
<nihilazo>
(and some games for saves, but it was surprisingly a little rare)
<veltas>
Or you could just limit to the 8KB RAM, you could do a lot with that in a tokenised forth
<nihilazo>
LSDJ has the main program in ROM but also has storage in the cartridge the user can write and read from
<nihilazo>
so did pokemon games (although they used a battery-backed RAM which isn't a very robust solution)
<veltas>
That is definitely the way to go, some kind of nv storage
<f-a>
well you cannot use `create … does>`, which is a bit of a pity
<nihilazo>
and a forth interpreter is likely to be running from a flash cartridge
<nihilazo>
in which case you can use the insanely huge flash memories that those have lol
<veltas>
Yes
<nihilazo>
my EMS cartridge (which everybody agrees is pretty terrible, it's like the worst GB flashcard) has 32M storage
<nihilazo>
which is insane for the gameboy
<nihilazo>
some have even more, I think some of the bennvenn ones have multiple gb of storage
mjl has quit [Ping timeout: 272 seconds]
mjl has joined #forth
gravicappa has quit [Ping timeout: 256 seconds]
f-a_ has joined #forth
f-a has quit [Read error: Connection reset by peer]