<neuro_sys>
Canon Cat looks like a whole Emacs machine written in Forth
<veltas>
Very nice
<veltas>
I am working on a C Forth, I will make the code public soon when it's a bit more developed
<veltas>
I liked the idea of pForth but I think it's too basic, so I'm working on a fully fleshed out C Forth
<neuro_sys>
Nice. Hopefully at some point I'll start implementing my own Forth too.
<neuro_sys>
I've yet to check pForth.
<neuro_sys>
One of the main "selling point"s for me about Forth was that many people roll their own implementations.
<neuro_sys>
It seems like in gforth, using marker and dynamic linking with c libraries don't mix well, or I'm doing something wrong.
<neuro_sys>
After I load my code, and then use marker to reset the dictionary, and then reload my code, I get a "Invalid memory access" at libcc.fs:908:35: 0 $7F7BC8140520 lib-sym
<neuro_sys>
Maybe gforth links it once, but after a marker reset, it doesn't load it a second time, and crashes.
<veltas>
Maybe it just doesn't handle it correctly
<veltas>
I know the gforth devs don't really think that highly of memory management using the dictionary, you'll get better support from them with ALLOCATE etc
<veltas>
Which is a bit sad
tech_exorcist has joined #forth
dave0 has quit [Quit: dave's not here]
<neuro_sys>
Hmm was it okay to use return stack inside a begin-while-repeat loop?
<neuro_sys>
The standard says it's a separate control flow stack.
cmtptr has quit [Ping timeout: 260 seconds]
cmtptr has joined #forth
f-a has joined #forth
<veltas>
neuro_sys: The control flow stack exists at compile time, begin-while-repeat don't touch return stack
<veltas>
The control flow stack basically gets the address of the BEGIN, and then when you do UNTIL it pops that off to calculate the branch offset, similar logic for REPEAT
<veltas>
On a lot of forths the "control flow stack" is actually just the data stack
proteusguy has joined #forth
<neuro_sys>
I see
pareidolia has joined #forth
<siraben>
neuro_sys: whoa do you have a link to that mandelbrot program
<neuro_sys>
This video makes some comparisons to lambda calculus and concatenative languages. It's pretty cool talk BTW.
<nihilazo>
I'll have a look
<veltas>
nihilazo: No, Forth is like Lisp. And Lisp is barely like a functional programming language, if it was invented today it wouldn't be considered functional.
<nihilazo>
oh ok
<nihilazo>
idk how forth is exactly like lisp other than both having metaprogramming stuff
<nihilazo>
which is nothing to do with functional programming as an idea at all really
<nihilazo>
I'll watch that talk tho
<veltas>
It's like Lisp in the respect that it can have a very small implementation, you can do metaprogramming
<veltas>
The parsing is very simple
<veltas>
There are lots of similarities
<mark4>
veltas, java falls into that category too
<veltas>
Which category?
<veltas>
I don't think any of what I just said applies to Java
<mark4>
small implementation (can be embedded) and can be extended if thats what you mean by metaprogramming
<neuro_sys>
The first half an hour of the video is a survey of different computational models, but at around 30 minute mark it goes into Forth (and generally stack based concatenative languages) and show how you can see and use it in functional paradigm.
<veltas>
mark4: The property it's least similar on is having a simple parser, Java's parsing is a C-style language's parsing, which is not as simple as Lisp or Forth.
<remexre>
also common lisp's parsing isn't actually simple...
<veltas>
I mean original lisp
<mark4>
agreed
f-a has quit [Quit: leaving]
<veltas>
Forth's parsing isn't simple either in some senses, there is a bit of nuance to what I mean
<veltas>
And I have not attempted to be more specific because really I find language comparisons very unproductive, I'm just trying to give some help to why it is people say Forth is similar to 'functional' languages
<veltas>
I think another reason might be that when I learned Forth, it was as novel to me as when I first programmed in Haskell (my first proper functional language), and made my head hurt just as much
<neuro_sys>
Programming language fights are the worst head aches.
f-a has joined #forth
<veltas>
Comparing programming languages is also meant to be constructive sometimes, I just find it doesn't work that well when you try and reduce it to paradigms
<veltas>
I find what I learn from different programming languages and styles can end up helping me anywhere, never where I expect
<neuro_sys>
I like to enjoy them with no expectation, but I'm sure it helps me in my work life too.
<neuro_sys>
They're pretty much like natural languages too, they are equivalent in the sense that you can form a logical proposition in any of them, but everyone's got their favorite, and one or two that they use daily.
<neuro_sys>
Lately I'm enjoying Forth a lot, some of my friends think I'm now a bit crazy since I share and talk about it regularly.
<neuro_sys>
Now I'm wondering, are there Forths that output machine code after compilation, and stripping any compilation features? Like with zero over head on runtime.
<veltas>
Yes, I think some embedded forths do this (symbol info is kept locally, the embedded device just gets pure threaded code)
<veltas>
You can also keep symbols and the dictionary separate, and have a separate space for interactive feature words, and then you can just cut off those features and symbols in your output image
<veltas>
And SwiftForth for example one of the licences allows you to use their code in your program, but you may not expose the compiler or interpreter to the user
<neuro_sys>
I see, that's cool. I compared my mandelbrot with the equivalent written in C using <complex.h>, and C one obviously was way faster.
f-a has left #forth [#forth]
<neuro_sys>
I kind of would like to compare it to some Forth that outputs optimized code. At some point I also would like to go into writing a Forth too, at which point I'd like to focus on performance.
<veltas>
The fastest would be to vectorise the work (or do it on GPUs), C is probably easier to do that with too
<neuro_sys>
Yes, but to be fair, I'm more interested in sequential performance.
<veltas>
I wonder why
<neuro_sys>
Not that I care it actually renders fast (in that case I'd write it in C and not Forth).
<veltas>
If I care about performance I care about getting the CPU to do it as fast as it can, and then I'm writing it either in C with intrinsics or some kind of vector extension, or for a GPU in a specialised compute shader language
<neuro_sys>
Well, as I'm only interested in the performance comparison with C, and not that the program runs the fastest possible way.
<veltas>
And you can technically write the 'fast' part in C or assembly, and link it to forth
<veltas>
So then I would say you can get 99% of the performance by writing mostly forth (or any language really)
<veltas>
I think that's an important consideration when people decide a language based on performance requirements, provided you can link C code that doesn't matter as much as people think it does
<veltas>
And the people who claim they care about raw performance don't tend to optimise their C code that much anyway
<veltas>
Just interesting
<neuro_sys>
True. I made a confusing remark. I'm not interested in writing performant code. I'm interested how a Forth can compare to a C compiler in terms of performance (without vectorization or inline assmebly tricks).
<veltas>
Yeah it's a valid question
<veltas>
I think desktop Forth performance is somewhat limited by interest, and also the enthusiasm for optimising Forth, and maybe lack of funding
<veltas>
i.e. I think if the right people cared enough then Forth could be comparable with stuff like LuaJIT, node, JVM in terms of performance
<veltas>
> Lately I'm enjoying Forth a lot, some of my friends think I'm now a bit crazy since I share and talk about it regularly
<veltas>
Forth is the ultimate "I'm not crazy, you are" language :P
<veltas>
Or "I'm not crazy, everyone else is crazy"
<remexre>
the thing I always hit with writing a perf-oriented forth compiler on paper was, choosing the registers->stack mapping
<remexre>
either I have to do an uncomfy amount of inlining, or there's significant overhead going from code for which the stack exists and code where it doesn't
<mark4>
does json allow for templates the way php does?
<remexre>
not knowing PHP, almost definitely not
<mark4>
let me give you an example that im working on which is basiclaly just SHORT HAND for the structures im going to be parsing,
<mark4>
anywhere within the main json blob that you see |attribs| you would mentally replace that structure with the json structure at the bottom of the file
<mark4>
it would be nice if json parsers allwed you to create macros like that
<remexre>
I'd recommend using yaml or dhall or something as an authoring format, and converting it to JSON
<remexre>
yaml has pointers that'd let you do this
<mark4>
no. json is ubiquitous and very simple :)
<remexre>
yaml->json and dhall->json are lossless conversions
<mark4>
im writing my own parser lol i can implement this :)
<remexre>
like that's not json at that point :P
<mark4>
i know :)
<mark4>
its jsonish
<mark4>
hmmi could implement json loops! }:)
<mark4>
omg please dont give anyone that idea :/
sts-q has quit [Remote host closed the connection]
<remexre>
>_>
<KipIngram>
Well, I've added something to my system that's rather radical and will raise eyebrows. I can motivate it by the dictionary search for a word. In that search, there is a linked list of vocabularies. Each one of those has a linked list of words. And each one of those has a string of characters that have to be checked. So it's a three-deep search. First imagine searching for a string that's not there.
<KipIngram>
You're guaranteed to get a false result, after searching the entire structure.
<KipIngram>
If that is your coding goal, it's fairly simple and clean. So imagine you've coded that.
<KipIngram>
Now consider having the search succeed. Here you are, way down at the bottom of that three-deep process, and now you're faced with modifying the code above you to propagate your successful result back to the top.
<KipIngram>
That complicates the code CONSIDERABLY.
<KipIngram>
So I have extended my stack frame system with what I call a "super frame." Basically it gives me the ability to have my successful search result on top of the stack, and I can leap all the way back up to the top, just bypassing that whole process of unwinding.
<KipIngram>
The super frame restores both return and data stacks to their state when the frame is opened, except the TOS value cached in a register is maintained. That's how the result get back up to the top.
gravicappa has quit [Ping timeout: 240 seconds]
<KipIngram>
Unlike the standard stack frame the process can't be nested. The required return stack value is cached in an otherwise unused register.
<KipIngram>
But it's such a radical idea I really can't imagine needing to nest it.
<KipIngram>
It would be possible to add a third stack to the system and use that to nest it, but I'm assuming I'll nenver do that.
<remexre>
this sounds like how I implemented exceptions a while back
<KipIngram>
I imagine there are structured programming fanatics that would just lose their minds over something like this.
<KipIngram>
Yes, it actually is similar to the error handling, except with a controllable return point.
<remexre>
iirc I solved nesting by having the "set up handler" code push the old handler to the return stack
<KipIngram>
Well, that's what the standard stack frame does.
<KipIngram>
Saves the frame point to the return stack, and then sets it equal to the current stack pointer.
<KipIngram>
It just gives a way to access stack elements relative to a fixed point.
<KipIngram>
I could do the same thing using the stack pointer, but I'd have to keep up with everything moving around as the stack changed.
<KipIngram>
When I close a standard frame, I put the frame pointer back into the stack pointer, so it avoids the need to clean junk off of the data stack.
<KipIngram>
Provides a clean return state for that.
<remexre>
hm, okay; my system at the time didn't do anything like that :P
<KipIngram>
Well, it's kind of unorthodox.
<KipIngram>
But it is helpful. Makes it so in this nested search I just need to get the loop termination item on the top of the stack so I can test it, and then the framing stuff hanndles cleanup for me.
<KipIngram>
In the standard frame the TOS is recovered from the initial state as well. I need to ponder that and see if it's what I want.
<KipIngram>
In that case I'm not really trying to pass information back up.
<KipIngram>
I had the standard frame stuff in my last one, so I know I like it. This super frame thing I really haven't gotten much experience with yet - time will tell if it was a good idea or not.
spoofer has quit [Quit: leaving]
spoofer has joined #forth
<KipIngram>
It really seems to be extremely helpful in this dictionary search case, though I haven't actually put that code in and made it work yet. It's still on the drawing board.
<KipIngram>
But the entire process of dictionary search, in the case of multiple vocabularies in the search order, is a pretty sophisticated process.
<KipIngram>
I could go back to my old one and see how much code I write last time - I can't believe it will be as terse as this candidate code, which is just 12 short lines.
<KipIngram>
Essentially implementing FIND.
<veltas>
remexre: Probably if you want to write a performance oriented forth compiler you should do a lot of research on stack-based JITs
<veltas>
KipIngram that error handling thing is just exceptions, you've come up with exceptions by another name
<veltas>
And possibly very slightly different semantics
<remexre>
veltas: I'm "not unfamiliar with" c2 (the JVM JIT), but it knows statically how call's affect the stack
<remexre>
which one wouldn't for a typical forth
<remexre>
calls*
<veltas>
Incorrect
<remexre>
which part?
<veltas>
If you write an optimising compiler you will need to do data flow analysis, many forth words can be statically analysed to know the number in/out
<remexre>
right, I'm saying once you have to call out to something that you can't statically analyze, e.g. a deferred word, you're paying a really bad penalty that I couldn't find a way around
<veltas>
And also you could handle different stack results based on different input too
<veltas>
You can statically analyse a deferred word just-in-time
<veltas>
There are some situations where you don't have the same info, yes, although you could have an option to provide that info for performance
<veltas>
Many problems to solve, new ground to tread, I think it's as interesting and worth a pursuit as anything in Forth.
<veltas>
Not something I'll go into myself likely, I'll respect anyone who does though
<veltas>
I think I prefer simpler Forths though, lower bar for understanding, so highly optimised Forths I'm not too keen on. I'd rather optimise critical parts in assembly than maintain an optimising compiler
<remexre>
yeah, that's where I'm at at this point
<remexre>
although I do want to maintain an optimizing compiler, just the optimizations I'm doing are way before it gets anywhere close to being as low-level as Forth :)
<KipIngram>
veltas: Yes, I accept that description. It is an exception handler, and in the case of the dictionanry search the exception is "success."
<veltas>
KipIngram: Another thing people do is a far exit by dropping from the return stack
<KipIngram>
The normal exception system always dumps me back in through WARM/QUIT, whereas this one lets me specify a location. If it was possible to nest these things I could just use the mechanism for normal errors. But that would require me adding a third stack, to save these exception roots on, and I don't know if I want to do that.
<veltas>
Obviously that is less maintainable and more error prone for any amount of sophistication in your code
<KipIngram>
Yes - this does that, basically, except it just has a return stack pointer value that it "drops back" to, without actually picking its way down.
<KipIngram>
It's a "rapid implementation" of an arbitrary number of "r> drop" pairs.
<veltas>
What does it do to data stack?
<KipIngram>
Except it also restores the data stack.
<KipIngram>
{| saves the data stack pointer on the return stack; |} pulls it back.
<KipIngram>
The TOS entry that's cached in a register isn't restored, though.
<veltas>
Problematic
<KipIngram>
{ ... } restores the TOS, but {| ... |} doesn't that's your way of returning a value from below.
<veltas>
TOS should be an invisible optimisation
<veltas>
Fair enough
<KipIngram>
In this case there's a 0 |} just before the end of FIND. That 0 is your fail result. If the |} down below is executed, it's done with the success pointer in TOS, and that gets retained.
<KipIngram>
This really doesn't let me do the usual thing of having FIND return two values on success and one on fail.
<KipIngram>
I just get one result either way.
<KipIngram>
But I have a lot of words that do conditional tests without consuming the value, so I'm in good shape.
<KipIngram>
I have a common mechanism of sticking a . at the beginning of a word, and that causes one extra value to be retained.
<KipIngram>
So = consumes the top two items, but .= consumes only the top one. And so on.
<KipIngram>
So I can do .0= after FIND to branch to success/failure cases.
<KipIngram>
I have a .0=; conditional return, for example.
<veltas>
In my Z80 forth FIND (actually, a generalised version of FIND) is written in assembly
<KipIngram>
I've done that in the past.
<veltas>
Because it significantly improved performance at the interpreter
<KipIngram>
More recently though it's written in Forth.
<KipIngram>
Yes, I can definitely see that.
<veltas>
A 3.5MHz 8-bit processor benefits there
<KipIngram>
:-)
<KipIngram>
Yes, it would, wouldn't it?
<KipIngram>
I haven't imposed such a system on myself yet.
<veltas>
If it's not 'slow' I would write it in Forth generally, even TYPE was implemented in Forth on there
<KipIngram>
But my general idea is that this will be the OS of any gadgets I build during retirement.
<KipIngram>
So who knows what that will be.
<veltas>
Nice
<veltas>
I like stuff like that, very personal technical projects
<veltas>
Can get some good gems in there
<KipIngram>
Oh me too.
<KipIngram>
This seems a good way to "prepare" for it, while I still have work responsibilities.
<veltas>
How close to retirement are you?
<KipIngram>
Get this all working, get it so it will self and cross compile, and so on.
<KipIngram>
I'm 58.
<KipIngram>
So somewhere within 10 years, I assume.
<veltas>
So you're going to join the rest of us in the retirement age of 90 as the countries we live in go bankrupt :P
<KipIngram>
What I hope to do is have a good profiling system associated with this.
<KipIngram>
So I'd profile FIND, and find out exactly where the time is really being spent, and assembly optimize just those points.
<KipIngram>
You'd get most of the benefit just by optimizing the comparison scan for each name, I imagine.
<veltas>
Yeah probably, I had the same logic, but it was easy enough to just write the whole thing in asm at the time
<KipIngram>
That would whack away four or five of the 12 lines I've got now that I think implement this.
<KipIngram>
Sure. And then you're sure. :=)
<KipIngram>
I am kind of interested, though, in minimizing the amount of porting work associated with this system.
<KipIngram>
Well, not really "minimizing it." Reducing it as much as possible consistent with "close to optimum" performance.
<KipIngram>
I've got a layer in there that I refer to as "virtual instructions."
<KipIngram>
They're assembly macros.
<KipIngram>
And primitives are implemented using those.
<KipIngram>
So in theory I'd only need to port those macros, and the rest would be portable.
<KipIngram>
I figure I'll wind up with a few dozen of them.
<KipIngram>
Whereas if I wanted to absolutely minimize I could probably get it down to one dozen, or even less, but then I'd have some tacky performing primitives.
<KipIngram>
I'm trying to set it up so that I can get optimum primitive code for both x86 and ARM architectures.
<veltas>
I think the fig forth approach was good enough, just write colon definitions for large parts and write basic words in assembly
<veltas>
"basic" I mean simple, not BASIC
<KipIngram>
One of the things I did in the name of porting was put the terminal into raw mode, and implement all of the line editing in Forth. I really want to just need to replace KEY and EMIT and have that be it.
<KipIngram>
Plus I just don't like the standard way a cooked terminal does things.
<KipIngram>
For one thing it makes CREATE/DOES> a lot easier to implement.
<veltas>
Hmm not sure
<KipIngram>
It just feels the most like original Forth to me.
<veltas>
Yes, and it's true to say
<KipIngram>
I learned all that really well before I ever even considered other alternatives, so they always seem a bit alien to me.
<veltas>
However it improves CODE definitions a lot to use direct threading, and has not a huge overhead on others
<KipIngram>
Yes, direct threading offers some definite pros.
<veltas>
TOS optimisation I like because it improves a lot of code and has really no impact on other code words
<KipIngram>
Yes, I think it's clear that caching TOS is an advantage.
<veltas>
It's hard to find a situation where it's negative
<KipIngram>
Caching more can have a much smaller advantage, but only if you have a really smart compiler.
<veltas>
It's a little harder to wrap your head around TOS when writing assembly though
<KipIngram>
The GForth guys have dug into that pretty deeply.
<KipIngram>
And you have to decide where the stack pointer is going to point.
<KipIngram>
Does it point to where TOS would be? Or to 2OS?
<KipIngram>
In this system I'm writing now it points to the 2OS location.
<KipIngram>
So TOS reall belongs at [SP-CELL].
<veltas>
Point to fake TOS might make sense if you want to easily spill cached stack when calling
<KipIngram>
You could do it either way, of course.
<KipIngram>
I've never done one that works the other way, so I'm less familiar there.
<KipIngram>
But as far as the benefits of caching, you can't deny the advantage on @, which just becomes TOS = [TOS]; NEXT.
<KipIngram>
Or +1: INC TOS; NEXT
<KipIngram>
Sorry; 1+.
<KipIngram>
Because that's such an advantageous structure for performance, I have other words for the first few powers of two. I have 1+, 2+, 4+, and 8+, which come in really really handy when processing linked lists.
<KipIngram>
And the corresponding decrements.
<veltas>
They are handy
<KipIngram>
Those are used extensively throughout FIND, leaving me better off than I would be vs. an assembly version.
jedb has joined #forth
MrMobius has quit [Read error: Connection reset by peer]
MrMobius has joined #forth
X-Scale` has joined #forth
dys has quit [Ping timeout: 265 seconds]
tech_exorcist has quit [Ping timeout: 265 seconds]
shmorgle has quit [Ping timeout: 240 seconds]
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
tech_exorcist has joined #forth
<KipIngram>
veltas: Starting in the last version I had a collection of conditional double returns (like 0=;; instead of 0=; ) and also a word n; that returned an arbitrary number of levels up - I only used that in one spot in the system, though.
<KipIngram>
I imagine that spot will get done with {| ... |} this time instead.
<KipIngram>
Counting up the number to use for n was dangerously "manual."
<KipIngram>
My |} word does NOT change the IP. So you roll on to the end of the word where |} is used. But when you hit ; it has the effect of the ; up in the word {| was executed in.
<KipIngram>
I wouldn't know what IP value I'd need at the time {| is executed - it's out there somewhere down the stream.
<KipIngram>
So when I finally make the topmost "search" call, after doing {|, the code after that word and up to the ; only executes in the failure case. In the success case I execute the code after |} down below, up to ;.
<KipIngram>
What that really means to me is that there won't be any code to speak of between |} and ;.
<KipIngram>
Up at the top you'd put the failure result on the stack if necessary, and down below you put the success result on the stack.
<KipIngram>
If the stack is already in those states, then ; will come right after |}
<veltas>
Yes I too have pondered how to make the exception syntax nicer
<veltas>
I don't like ANS exceptions
tech_exorcist has quit [Quit: tech_exorcist]
<KipIngram>
Well, feel free to pilfer any of these thoughts if you decide you like them.
<KipIngram>
Actually, maybe there nothing stopping me from saving the old value of that new register on the return stack. Then I could nest this. Why not?
shmorgle has joined #forth
<veltas>
For one thing I think any control feature should inline actions, not use xt's