2022-01-07 03:46:46 <veltas      > joe9: Running showstuff after it's compiled will do that
2022-01-07 03:47:37 <veltas      > Recommend reading Starting FORTH, it's a treat
2022-01-07 06:25:16 <joe9        > it is my go-to book these days. I must have forgotten about this. Let me look it up again.
2022-01-07 06:31:12 <veltas      > joe9: Actually, sorry I don't think those words are in starting forth
2022-01-07 06:31:15 <veltas      > What FORTH are you using?
2022-01-07 06:31:25 <joe9        > felixforth
2022-01-07 06:31:40 <joe9        > it is not popular
2022-01-07 06:31:48 <joe9        > it is small and still workable.
2022-01-07 06:31:52 <veltas      > Where are its docs?
2022-01-07 06:31:58 <veltas      > Are they online somewhere?
2022-01-07 06:32:35 <veltas      > "not popular" is not a problem for FORTH
2022-01-07 06:33:09 <joe9        > I doubt there are any. https://github.com/8l/ff
2022-01-07 06:44:56 <veltas      > The README contains all the non-standard words on felixforth, and the rest are ANS so download https://dl.forth.com:8443/downloads/SwiftForth-linux-macos-eval.tgz which contains "dpans.pdf" which is the ANS standard
2022-01-07 06:45:46 <veltas      > C" in felixforth is non-standard because it also stores it in the dictionary
2022-01-07 06:48:18 <dave0       > 
ACTION clicks

2022-01-07 06:48:57 <veltas      > The SwiftForth evaluation download contains ANS standard and some other good PDFs
2022-01-07 06:51:23 <veltas      > So the docs for that FORTH look pretty good to me, and the whole source is available and readable
2022-01-07 06:54:08 <joe9        > this is a good article: https://www.phaedsys.com/library/blog/data/Forth_versus_C%20Howerd_Oakford%20%20v3.pdf
2022-01-07 06:56:53 <veltas      > Would take it with a pinch of salt, sounds a bit ideological
2022-01-07 06:57:24 <veltas      > I wouldn't claim you can write FORTH faster than C in general, I certainly don't
2022-01-07 06:57:37 <veltas      > I happen to enjoy it more, some applications are probably faster in FORTH, but certainly not in general
2022-01-07 06:57:58 <veltas      > Interested to know what others think
2022-01-07 06:59:28 <veltas      > This thing about writing a "new language" for every problem is something I don't do, and don't really think you need to do either. It's the sort of platitude you hear from most people who learn a language with emphasis on powerful macro/interpreter features
2022-01-07 07:00:18 <veltas      > You'll hear the exact same argument from some lisp proponents, and yet almost no lisp code is written like that
2022-01-07 07:29:40 <veltas      > Chuck makes a sort of similar argument in POL but it's not quite the same as the work he was doing was more primitive, FORTH as we know it today has many more basic blocks you'd need for all sorts of programs
2022-01-07 07:34:45 <crc         > after spending a couple of decades writing forth, there have only been a couple of times when I actually extended forth to a 'new language' when working with it.
2022-01-07 07:44:38 <joe9        > are there any metrics between subroutine threaded forth vs token threaded forth?
2022-01-07 07:45:13 <joe9        > s/token/direct/
2022-01-07 07:45:32 <joe9        > http://www.complang.tuwien.ac.at/forth/threading/
2022-01-07 09:05:48 <veltas      > I think at that link it says subroutine threading is slower without optimising, but it's the base for optimising
2022-01-07 09:06:07 <veltas      > I have no idea but IMO subroutine is also harder so not worth doing unless you want to optimise as well
2022-01-07 09:06:11 <veltas      > for speed
2022-01-07 09:06:44 <veltas      > If trying to be as performant as possible is not the goal then do something else, but none of the classic models make sense in 64-bit
2022-01-07 09:06:52 <veltas      > You probably want some kind of VM now
2022-01-07 09:07:17 <veltas      > bytecode
2022-01-07 09:07:58 <veltas      > The old-school "array of xt's" is fat and penalised for bad locality
2022-01-07 09:08:42 <veltas      > tokenised forths are probably not making enough intelligent use of the space, some kind of opcode system is probably what you want if not subroutine threaded
2022-01-07 09:10:04 <veltas      > tokenised forth is probably the simplest compromise, or using an array of 32-bit relative offsets to xt's
2022-01-07 09:10:28 <Zarutian_HTC> veltas: would a vm that uses cell wide virtual instructons like the canonical dual stack machine from Koopmans book qualify?
2022-01-07 09:10:59 <veltas      > That's the sort of thing I mean by VM or bytecode yeah
2022-01-07 09:11:09 <veltas      > And/or whatever it is that retro does
2022-01-07 09:12:13 <Zarutian_HTC> easy to implement as megamorphic switch inside an endless loop
2022-01-07 09:14:31 <Zarutian_HTC> (the default case is a CALL to that forth address, while the other cases implement the primitives)
2022-01-07 09:15:10 <veltas      > In my mind, we are so used to JIT at this point that anything less than subroutine threading with a sprinkle of optimisation on x86-64 would be underwhelming
2022-01-07 09:15:25 <crc         > retro runs on a bytecoded stack based vm, but is subroutine threaded
2022-01-07 09:18:03 <veltas      > You probably have more opportunity for elegance on a VM
2022-01-07 09:19:09 <Zarutian_HTC> what I long for is cheap, opensource bitstream, partially reconfigurable fpgas/cplds
2022-01-07 09:19:52 <veltas      > Yeah a FORTH machine FPGA sounds neat to me too
2022-01-07 09:21:21 <Zarutian_HTC> the trend in fpgas these years have been more and more 'hard ip cores and blocks' which is not I want
2022-01-07 09:21:44 <boru        > I've been trying to convince a certain someone on this net to do that, based on another project they've been working on.
2022-01-07 09:21:59 <boru        > Open FPGA fabric, that is.
2022-01-07 09:22:42 <Zarutian_HTC> more usually 'dead' silicon, higher denisity, harder to manifacture, all results in expensive parts
2022-01-07 09:23:29 <boru        > Pointy haired managers' desire for faster iteration has driven the demand for IP cores, imo.
2022-01-07 09:23:38 <boru        > Everything must be agile!
2022-01-07 09:24:26 <Zarutian_HTC> do not mind if those 'ip cores' were just soft
2022-01-07 09:25:36 <Zarutian_HTC> I am basically looking for 7400s series equiv in manifacturing and specification for fpgas
2022-01-07 09:27:35 <Zarutian_HTC> boru: iirc, fpga fabric as simplest are LUTs and bus routers, no?
2022-01-07 09:29:44 <boru        > Amongst other LEs and stuff, sure.
2022-01-07 09:30:29 <boru        > They did some work reversing some bitstreams which resulted in: https://github.com/azonenberg/openfpga
2022-01-07 09:31:23 <Zarutian_HTC> the cell technique in https://www.digikey.com/en/products/detail/atmel/AT6002-4QI/12107934 inspired me to start specifing an LUT block (for a lack of better term) that is inspired by cellular automata with von neuman neighbour rules
2022-01-07 09:32:18 <Zarutian_HTC> boru: do the Symbiflow folka know of this?
2022-01-07 09:32:45 <boru        > Unknown to me. There are a bunch of similar projects around, but they all seem to be in silos.
2022-01-07 09:33:05 <boru        > Symbiflow seems pretty awful to me. Great idea, but poor execution.
2022-01-07 09:33:18 <boru        > When hardware people write software: the project.
2022-01-07 09:34:09 <Zarutian_HTC> basically 16x16 grid of LUTs, each with North, East, West, South inputs and seprate outputs in these directions
2022-01-07 09:34:19 <boru        > I'm mostly a softie these days. I only tangentially touch FPGAs at work these days, and I don't have time for my own projects much.
2022-01-07 09:34:28 <boru        > Yeah, I get what you're saying.
2022-01-07 09:35:13 <Zarutian_HTC> only, there are no state flip flops per LUT
2022-01-07 09:36:05 <Zarutian_HTC> completely async
2022-01-07 09:37:15 <boru        > Classic async designs never really made it outside academic, alas.
2022-01-07 09:37:25 <boru        > Very interesting, though.
2022-01-07 09:38:43 <Zarutian_HTC> the idea is that you basically have to treat the LUT blocks like you just had a bunch of combinational boolean logic gates
2022-01-07 09:38:48 <veltas      > I find anything that never makes it outside of academia quite smelly
2022-01-07 09:38:59 <boru        > Heh
2022-01-07 09:39:15 <veltas      > "interesting but nobody uses it" is definitely an alarm bell
2022-01-07 09:39:24 <boru        > Well, AMULET3 was pretty cool.
2022-01-07 09:40:03 <boru        > As are stack computers and transputers.
2022-01-07 09:40:35 <boru        > Things which aren't useful or turned out to be bad ideas can be the source of better ideas later.
2022-01-07 09:40:49 <Zarutian_HTC> veltas: depends, often manifacturability, hard to develop process, etc have more say than if an technique is interesting or not
2022-01-07 09:40:51 <boru        > Or ignore them, and repeat the same mistakes later.
2022-01-07 09:41:14 <veltas      > Yeah I shouldn't generalise
2022-01-07 09:41:46 <veltas      > I wouldn't be here if I thought FORTH was totally useless, and it's one of those things that's "interesting buy nobody uses" to some extent
2022-01-07 09:41:53 <veltas      > but* nobody
2022-01-07 09:42:08 <Zarutian_HTC> then network effects and market dominance can entranche decissions that made sense then but dont today
2022-01-07 09:42:22 <boru        > Wasn't there a user on sillynode who did precisely that? Used to show up and moan about how useless Forth was constantly.
2022-01-07 09:43:04 <veltas      > Me probably lol, no I don't actually remember
2022-01-07 09:43:08 <Zarutian_HTC> dunno, got an Openfirmware based machine booting thanks to forth
2022-01-07 09:43:37 <boru        > It wasn't you, no.
2022-01-07 09:43:56 <boru        > The BSD bootloader is also a forth.
2022-01-07 09:44:04 <veltas      > Was
2022-01-07 09:44:05 <Zarutian_HTC> and I have come across it as an inbuilt debugger in an soecialist equipment
2022-01-07 09:44:19 <boru        > I don't think it's been replaced in all of them yet.
2022-01-07 09:44:24 <Zarutian_HTC> specialist*
2022-01-07 09:44:29 <veltas      > Zarutian_HTC: USSR? lol
2022-01-07 09:44:34 <veltas      > soecialist equipment
2022-01-07 09:45:08 <boru        > I think it was a typo. The joke might not translate.
2022-01-07 09:45:28 <Zarutian_HTC> fat fingering on an virtual keyboard on smartphone, hence the _HTC suffix on my nick
2022-01-07 09:45:42 <boru        > Nonetheless, it is whiskey o'clock. I have pressing matters to attend to.
2022-01-07 09:45:52 <Zarutian_HTC> "Go FORTH, comrad!"
2022-01-07 09:46:11 <veltas      > I know there was a soviet FORTH-like language
2022-01-07 09:46:18 <veltas      > reverse polish
2022-01-07 09:47:47 <Zarutian_HTC> so Forth is not as useless as many think
2022-01-07 09:56:05 <MrMobius    > hopefully im not the one you were thinking of who criticizes now and again. when people say unoptimized forth is 10x faster than optimized C i feel the need to speak up. unfortunately it can come off as anti-forth rather than pro-forth + pro-facts
2022-01-07 09:57:43 <boru        > No, it wasn't you, either.
2022-01-07 09:58:11 <boru        > And I'd say that's a sensible time to speak up.
2022-01-07 10:00:16 <veltas      > Every regular in here is pro-facts and realistic about FORTH IMO
2022-01-07 10:00:59 <veltas      > Maybe sometimes I could be accused of being a little too positive about FORTH's performance, don't worry though we can put it to the test when my FORTH's done and optimising
2022-01-07 10:02:38 <boru        > I didn't intend for what I said to cause widespread self reflection. I don't precisely remember the user in question's nick, but they're not here at the moment, it seems.
2022-01-07 10:07:18 <MrMobius    > np :)
2022-01-07 10:09:00 <veltas      > boru: I was just kidding anyway
2022-01-07 10:10:41 <joe9        > from my playing around, I feel that unoptimized forth is around 3 times slower than C. This seems to be around the same as python or any other interpreter, I guess.
2022-01-07 10:12:17 <veltas      > Python is much slower than that
2022-01-07 10:12:23 <veltas      > It really depends on the FORTH, and the machine
2022-01-07 10:12:51 <MrMobius    > ya the number a lot of people throw around is 50x slower for python vs C generally speaking
2022-01-07 10:13:09 <veltas      > I would say on the order of 10-100 times slower
2022-01-07 10:13:54 <MrMobius    > a subroutined (ie fastest for that architecture) forth for 65C02 I measured was 10-20x slower than hand written assembly. might be worse case though since extra penalty for running 16 bit forth on 8 bit arch
2022-01-07 10:14:46 <veltas      > That's about what you want, BASIC tends to be like 1000 times slower, not even an exagerration
2022-01-07 10:15:00 <veltas      > 10 times is quite a nice tradeoff in comparison
2022-01-07 10:15:22 <veltas      > Depends on the BASIC/FORTH but yeah
2022-01-07 10:16:10 <MrMobius    > on 6502 they claimed forth was 3x faster than BASIC though that would have been a direct or indirect threaded forth since the subroutine one i tried is modern
2022-01-07 10:16:58 <veltas      > I am skeptical about how much faster sub threading is on 8-bit
2022-01-07 10:17:03 <MrMobius    > apples to apples is hard to do since internally the BASIC is using a type of threading. a subroutine threaded BASIC could be written for 6502 for example
2022-01-07 10:17:19 <veltas      > Really depends on the BASIC
2022-01-07 10:17:45 <veltas      > ZX Spectrum BASIC is really really slow at some things, so I would have believed a tokenised forth was faster
2022-01-07 10:18:01 <MrMobius    > why is that? working with 16 bit pointers is especially slow on an 8 bit arch unless you have some hardware support
2022-01-07 10:18:07 <veltas      > And I can back it up with facts since I have a tokenised or non-tokenised (build option) forth for the spectrum that is much faster
2022-01-07 10:18:35 <veltas      > Made me smile seeing how much faster it was than BASIC, FORTH is a good model
2022-01-07 10:19:31 <veltas      > 16-bit pointers are not that much slower as long as you have carry (and Z80 has actual instructions for 16-bit addition etc anyway)
2022-01-07 10:20:10 <MrMobius    > ya hard to make a one to one comparison. a lot of those BASICs use floating point. comparing an integer BASIC to forth would be more meaningful
2022-01-07 10:20:26 <veltas      > Spectrum BASIC uses a mix of integer/floating
2022-01-07 10:20:41 <veltas      > If it's an integer it uses integer ops, if it's fractional it uses routines for floating point
2022-01-07 10:20:54 <MrMobius    > thats neat
2022-01-07 10:21:50 <veltas      > I'm not talking about floating arith, just the integer stuff, control flow etc
2022-01-07 10:22:00 <veltas      > I never did floating point on my forth so I can't compare lol
2022-01-07 10:22:22 <veltas      > But the spectrum floating point stack is pretty much a forth float stack so maybe I'd just use that
2022-01-07 10:23:01 <veltas      > The floating point performance for the Spectrum ROM is not atrocious, I'm sure it can be faster but not sure I could make it faster
2022-01-07 10:24:37 <veltas      > I've never written floating point implementation in software and I'm not going to start now, fixed point is just fine for 8-bit
2022-01-07 10:24:54 <veltas      > 32-bit fixed point calculations on that machine "ought to be enough for anyone"
2022-01-07 10:30:25 <MrMobius    > as fas as subroutine threading goes, you can just count the cycles - 6+6 for a JSR/RTS pair and INC/BCC/INC/BCC/JMP = 5+2+5+2+5 on modern 65C02 and 9 extra cycles on old 6502
2022-01-07 10:30:56 <MrMobius    > so 12 for subroutine threaded vs 19 or 28 for direct threaded
2022-01-07 10:31:31 <MrMobius    > and re floating point, it depends on what you want to do :)
2022-01-07 10:31:42 <veltas      > Also you get another register to use with sub threading
2022-01-07 10:31:54 <veltas      > But use more memory (on 8-bit, usually)
2022-01-07 10:32:17 <MrMobius    > assuming you have a 16 bit register to old the thread pointer :P
2022-01-07 10:32:46 <MrMobius    > im interested in calculators so i made my own decimal floats for my 6502 forth
2022-01-07 10:33:07 <veltas      > Also it's not a simple calculation because the real question is what percentage of time do you spend NEXT'ing, if it's like 50% of the time then your speed difference impact is halved
2022-01-07 10:33:11 <veltas      > But often it's even less
2022-01-07 10:33:33 <veltas      > The proof's in the pudding
2022-01-07 10:34:16 <MrMobius    > that is true though the original question was whether subroutine threading is faster on 8 bit. it clearly is at least for 6502. its a different matter whether the difference is meaningful
2022-01-07 10:34:56 <veltas      > Not in my opinion because the subject of performance is so skewed towards whether it's a meaningful speedup
2022-01-07 10:35:49 <joe9        > MrMobius, that seems about what I would expect. That subroutine threading is faster than direct threading.
2022-01-07 10:36:08 <veltas      > For 8-bit... on modern CPUs it's more complicated
2022-01-07 10:36:09 <joe9        > It was surprising to see the results where stc was 2 times slower than direct threading
2022-01-07 10:36:14 <MrMobius    > those are actually separated things. if you define performance or speed by the number of cycles it takes, there is no room for opinion. it's just an objective measure of cycles taken
2022-01-07 10:36:50 <veltas      > semantics
2022-01-07 10:37:40 <MrMobius    > you can define performance in a different way which is fine but if youre defining it by cycles then there is no room for disagreement. it's just the number of cycles
2022-01-07 10:38:02 <veltas      > Okay but what is the program we're measuring?
2022-01-07 10:38:12 <veltas      > You can't measure cycles without a program to run
2022-01-07 10:38:29 <MrMobius    > all programs. if everything else is the same except NEXT then it's the same calculation for all programs
2022-01-07 10:38:46 <MrMobius    > ie how many cycles does NEXT take
2022-01-07 10:39:04 <veltas      > Okay but be careful to not exagerrate the importance of NEXT, becaues if NEXT is twice as fast, that doesn't mean the FORTH will be twice as fast
2022-01-07 10:39:07 <veltas      > That is the point I am making
2022-01-07 10:39:35 <veltas      > I know you understand this, but just trying to make it clear for posterity
2022-01-07 10:39:58 <MrMobius    > thats a good point but its not relevant to this (i dont mean this in a mean way). thats why i said the original question was if stc is faster. that is an entirely separate concern although its important
2022-01-07 10:40:55 <MrMobius    > right
2022-01-07 10:41:27 <veltas      > In my opinion it's so important and is a fundamentally motivating question that there's something wrong with having the academic conversation about NEXT speed without also adding the disclaimer "this could mean a lot or very little depending on the program, and other things"
2022-01-07 10:42:04 <joe9        > i guess that can be said about most performance figures..
2022-01-07 10:46:50 <MrMobius    > meh i think it's that's person's fault if they jump to that conclusion without anyone saying that
2022-01-07 10:48:21 <veltas      > I'm not trying to prescribe blame, just trying to work with the fleshy creatures I communicate with. Personally I have noticed the fleshy creatures are inherently bad at interpreting simple data and easily mislead by facts presented the right way
2022-01-07 10:50:50 <f-a         > good ol’ fleshy folks
2022-01-07 10:52:04 <MrMobius    > ya its a practical question
2022-01-07 10:53:23 <veltas      > It's a bit like saying "linked list dictionaries are slower than hashed dictionaries". It's true under every meaningful metric. It's also not a valuable fact to most FORTH implementors
2022-01-07 10:54:07 <veltas      > Well not quite the same but just babbling on now
2022-01-07 13:21:38 <lagash      > Hello everyone! I haven't really touched FORTH for some years, but recently I've decided to dabble a bit more in it.
2022-01-07 13:22:10 <lagash      > Could someone critique this small sample of code I just wrote? https://dpaste.com/BQUJVKHRR
2022-01-07 13:26:34 <joe9        > add more comments?
2022-01-07 13:27:05 <lagash      > Like a link to a WikiPedia article..?
2022-01-07 13:28:46 <joe9        > I am not an expert. What differentiates good forth programs vs bad forth programs is the use of stack operators. Good programs use the thesaurus and the program seems to flow with the words. With bad forth programs, all I see is stack manipulation operators.
2022-01-07 13:28:56 <joe9        > this is my opinion.
2022-01-07 13:29:24 <joe9        > have you read thinking forth?
2022-01-07 13:30:26 <lagash      > I might've, years ago.. I know I read Starting FORTH..
2022-01-07 13:31:00 <lagash      > I'm aware of that, however, the algorithm itself is about as straightforward as my code.
2022-01-07 13:53:40 <veltas      > lagash: Hey that's some good syntax highlighting for FORTH there
2022-01-07 13:53:44 <veltas      > Will have to use that site
2022-01-07 13:54:24 <veltas      > That looks appropriate to me, it's true the calculation is a bit inherently complicated
2022-01-07 13:56:21 <veltas      > lagash: `dup 31 / swap 31 mod` is `31 /mod swap`
2022-01-07 14:03:29 <lagash      > veltas: nice! I wasn't exactly thinking of code golfing but this is pretty small :)
2022-01-07 14:04:05 <veltas      > Well in FORTH I sort of inherently try to code golf, especially if it's just a complicated calculation anyway
2022-01-07 14:06:17 <lagash      > I mean I'm sure some other stack-based language like GolfScript would make it really tiny but still..
2022-01-07 14:25:51 <veltas      > I'm not trying to make it as small as possible in any language, I'm just trying to factor it in FORTH
2022-01-07 14:26:08 <veltas      > lagash: This is what I got trying it https://dpaste.com/B42QKN8LB
2022-01-07 14:26:37 <veltas      > So that is how I document a 'big calculation'
2022-01-07 14:28:08 <joe9        > veltas, I like your formulaic commenting style. cool.
2022-01-07 14:28:10 <veltas      > /mod was just for your info because I assumed you didn't know about it from the way your word turned out
2022-01-07 14:28:44 <veltas      > joe9: Yeah usually I don't put formulae in like that, but in this calculation I think it's useful
2022-01-07 22:36:39 <Zarutian_HTC> https://github.com/Bushmills/Bashforth/