<MrMobius>
neuro_sys, I think you'll find some of the "advantages" of forth are actually disadvantages that proponents are sometime overly optimistic about
<MrMobius>
like when Michael Scott says his biggest weakness is that he volunteers too much
<MrMobius>
so the big hype about bottom up design is not because someone compared that to top down design and decided it was better, it's because there's no way to go back and change a word once it's in the dictionary
<MrMobius>
so you're stuck with bottom up although some people try to pass it off as superior, which is not exactly honest
<MrMobius>
you'll find a lot of that in Starting Forth like when they discuss "information hiding"
<MrMobius>
that's an important topic but the term there is misused to try to hide that some things are tough to keep straight that arent tough in other languages
<veltas>
Forth words quickly become unreadable and unmaintainable, forcing you to write shorter and more factored words which turn out to be better code in some ways but you could still have done that in a 'cleaner' language
<veltas>
You can actually have your cake and eat it in other languages
<veltas>
I think Forth wouldn't be interesting if it was just a language, and not an environment, but yes the environment also has a lot of issues
<MrMobius>
so not saying you shouldnt use forth, just be aware that how it's presented can be very "optimisitic." when you see through that, you still may want to use the language
<veltas>
I like forth and yet I am surprised when problems turn out to be easier in forth, it's not often that happens
<veltas>
Writing forth feels like I am using the same parts of my brain that are active when I'm writing assembly *and* trying really hard to optimise everything like register usage
<veltas>
I have written a software 64-bit division routine in powerpc assembly and forth recently, and I found the powerpc easier
pareidolia has quit [Ping timeout: 260 seconds]
<neuro_sys>
I already figured that much quite soon, but I'm a hobbyist at heart, playing around with assembly and homebrew computing just a bit. So my expectations from Forth in practical terms is not that high (at least in my day to day work). Although this video was quite nice: https://www.youtube.com/watch?v=mvrE2ZGe-rs
<neuro_sys>
So I'd like to get to a level where I would solve some of my needs with Forth instead.
<neuro_sys>
I was thinking doing the next Advent of Code 2020 with Forth.
<veltas>
One thing I will claim about Forth is it will make you a better programmer, it made me understand problems I didn't even know I had and has helped me solve problems at work in a much more elegant way even though I mostly write C there.
<veltas>
I also want to do advent of code in forth, I never do them but forth will motivate me
<MrMobius>
veltas, ya assembly is sometimes preferrable I think. I feel like forth is a way to avoid thinking about registers if youre ok with the performance loss
<neuro_sys>
I wish to get a job where I can write C next year now that I made some money doing dirty job with dirty languages. :)
<veltas>
You stop thinking about registers and start thinking about a stack, I think neither is 'easy' and both require thought
<veltas>
Forth was invented back when it was actually a lot easier and cleaner than most assembly languages of the time, but these days a good macro assembler would be 'better' in some cases depending on what you're used to
<veltas>
8-bit assembly is harder than forth, you don't have multiply, only certain ops are 16-bit, register usage is full of caveats and restrictions, etc
<MrMobius>
some people say you can (re)write 10% in assembly and get a big boost in performance but still save a lot of time on the 90% written in froth
<veltas>
I think that's true anywhere, even in 8-bit or on modern microcontrollers
pareidolia has joined #forth
<veltas>
It's always worth writing a sensible reasonable solution and then optimising the 1-10% where performance matters in profiling
<veltas>
And any good forth will let you integrate machine code routines as well
* Zarutian_HTC
hasnt read the entire backlog
<Zarutian_HTC>
I think the performance loss of running Forth code versus register machine code is mostly the impedence missmatch berween dual stack machines and register machines
<Zarutian_HTC>
specially if you keep your stacks in work ram instead of their own ram devices. This is why I like fpga/clpd/asic implementations of dual stack machines: less same bus contentions
<MrMobius>
there's a lot actually that slows you down, especially if your forth is like most forths and doesnt optimize
<MrMobius>
but just having the bottleneck of a stack machine is a hige speed killer
<MrMobius>
if you could use PICK and insert stuff arbitrarily into the stack without a speed penalty, you could recover a lot of that but your code would look terrible
<Zarutian_HTC>
but yeah Forth is handy even on atmega328p for both the code density and ease of programming/parameterzation even in the field when you do not have the original software build environment
<MrMobius>
ya speed isnt everything
<neuro_sys>
I also read that register allocation is an NP problem, while using stack for program flow is not. I don't know the specifics though.
<neuro_sys>
s/is not/doesn't have such a problem/
<Zarutian_HTC>
one bottleneck speed killer for register machines is the register to alu to register muxing
<Zarutian_HTC>
note that I have not started talking about deeply pipelinef out-of-order execution
<Zarutian_HTC>
-lined*
<neuro_sys>
Is branch prediction still relevant in a stack machine?
<Zarutian_HTC>
think of why branch prediction is needed
<Zarutian_HTC>
branch prediction only makes sense in architectures with long execution pipelines
<neuro_sys>
Right, if all instructions took fixed or one clock cycle then there'd be no need for branch prediction.
<Zarutian_HTC>
and if there are instruction cache prefetchers tied in, the branch prediction is also needd
<MrMobius>
neuro_sys, I don't get your point. a lot of forths on a register machine will use two of the registers for the first two stack items and ignore the rest. im just saying putting those 8 or however many registers to use will be faster if the equivalent forth code has a stack depth more than 2
<Zarutian_HTC>
if you look at say the excamera J1 dual stack machine you can see that all the possible alu ops are performed every instruction but only some instructions select which result get pushed onto the datastack
<neuro_sys>
MrMobius: You're right, register allocation is not relevant when executing Forth code I guess.
<neuro_sys>
register allocation is not a problem, that is.
<Zarutian_HTC>
this means even though an alu op takes x amount of step cycles so long the cpu always takes the same amount of or more step cycles to fetch, decode and then execute/commits it doesnt matter
<Zarutian_HTC>
the analogy I like to use is a fast food place with fixed menu and no per item custimzation options
<Zarutian_HTC>
though in stack machines there is the data depency between values on stack
<Zarutian_HTC>
but because values in TOS and NOS are know at end of each instruction the alu can have at them before even the next instruction has entered its fetch phase
boru has quit [Read error: Connection reset by peer]
boru has joined #forth
<Zarutian_HTC>
not only alu but stuff like work ram and program memory read ports can be fed TOS into their address portion of the port
<Zarutian_HTC>
gives those memory devices enough time to get the value at that address to its data output pins for that port even before the cpu 'realizes' that it needs that value
boru has quit [Read error: Connection reset by peer]
boru has joined #forth
proteusguy has quit [Ping timeout: 265 seconds]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
dave0 has joined #forth
proteusguy has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
gravicappa has joined #forth
hosewiejacke has joined #forth
hosewiejacke2 has joined #forth
hosewiejacke2 has quit [Client Quit]
sts-q has quit [Ping timeout: 240 seconds]
hosewiejacke has quit [Ping timeout: 264 seconds]
sts-q has joined #forth
hosewiejacke has joined #forth
the_cuckoo has quit [Quit: WeeChat 1.9.1]
the_cuckoo has joined #forth
hosewiejacke has quit [Ping timeout: 246 seconds]
dave0 has quit [Quit: dave's not here]
hosewiejacke has joined #forth
gravicappa has quit [Ping timeout: 265 seconds]
lispmacs has quit [Remote host closed the connection]
xek_ has joined #forth
dave0 has joined #forth
_whitelogger has joined #forth
<veltas>
MrMobius: My 8-bit forth uses a totally memory stack and seems to have very good performance, compared to the built-in BASIC
gravicappa has joined #forth
dave0 has quit [Quit: dave's not here]
jimt[m] has quit [Quit: Bridge terminating on SIGTERM]
siraben has quit [Quit: Bridge terminating on SIGTERM]
siraben has joined #forth
jimt[m] has joined #forth
hosewiejacke has quit [Ping timeout: 240 seconds]
gravicappa has quit [Ping timeout: 264 seconds]
xek__ has joined #forth
xek_ has quit [Ping timeout: 260 seconds]
hosewiejacke has joined #forth
hosewiejacke has quit [Ping timeout: 272 seconds]
xek_ has joined #forth
xek__ has quit [Ping timeout: 265 seconds]
Gromboli has joined #forth
<MrMobius>
veltas, which architecture?
<MrMobius>
Im sure it's faster than BASIC but that's the lowest bar you could set
<MrMobius>
although maybe its a good size/speed trade off for what youre doing
<MrMobius>
forth is i mean
hosewiejacke has joined #forth
<cmtptr>
he's targetting a calculator iirc
hosewiejacke has quit [Remote host closed the connection]
hosewiejacke has joined #forth
gravicappa has joined #forth
Zarutian_HTC has joined #forth
hosewiejacke has quit [Ping timeout: 240 seconds]
hosewiejacke has joined #forth
hosewiejacke has quit [Ping timeout: 265 seconds]
tabemann has quit [Ping timeout: 240 seconds]
hosewiejacke has joined #forth
hosewiejacke has quit [Ping timeout: 260 seconds]
<veltas>
MrMobius: ZX Spectrum
<veltas>
The built-in BASIC is actually a very elegant application, although it's not very fast yes.
<veltas>
My Forth was a lot faster than I expected though, I was very happy with the result. I don't even have a very optised forth, it uses the classic threading
<veltas>
optimised*
<veltas>
Certain things needed optimising in assembly, where 90% of the work is done, but only in 10% of the code. That's why we can afford high-level niceties in 8-bit as well as anywhere
<veltas>
It's a good rule of thumb for performance and I didn't believe it would apply to 8-bit until I tried it years back with a C/assembly project that had really bad C output
<veltas>
On Z80 I think the C code you get from the available compilers is only slightly faster than a decent Forth, if at all
gravicappa has quit [Ping timeout: 240 seconds]
gravicappa has joined #forth
hosewiejacke has joined #forth
hosewiejacke has quit [Ping timeout: 246 seconds]
<FUZxxl>
veltas: yeah, Z80 is really hard to optimise for
<FUZxxl>
it's this sort of crazy accumulator architecture that has been extended in all places except where it would actually help (accumulator size)
<veltas>
I think that is the compromise of being mostly backwards compatible with 8080
<FUZxxl>
I guess so
<FUZxxl>
it's still quite amazing how it has 16 bit addition in basically all registers except the accumulator
<FUZxxl>
,
gravicappa has quit [Ping timeout: 240 seconds]
tabemann has joined #forth
<veltas>
HL is the 16-bit accumulator really
<veltas>
A is combined with the flags when you do 16-bit stuff, you can push AF to stack, it wouldn't be useful to try and do 16-bit arith with that because the flags would clobber the low byte
<veltas>
Of course there are other ways they could have used it, but I think Z80 is spoiled for registers really, especially compared to 6502
<neuro_sys>
The talk I posted above discusses the performance/hardware mapping aspects of Forth (or concatenative languages in general) in relation to what we briefly talked about here yesterday.
<neuro_sys>
In the second half of the video.
Gromboli_ has joined #forth
Gromboli_ has quit [Remote host closed the connection]