<veltas>
I was reading a style guide, and one of the instructions was to not abbreviate any words, and I think they gave "cos" as an example and said to use "cosine"
<veltas>
If it's good enough for Euler it's good enough for your programs!
<mark4>
heh
<mark4>
i whole heartedly DISAGREE and agrree at the same time
<mark4>
however, using complete sentences for function/variable names is pure, unadulterated idiocty
<veltas>
It's interesting but I have no idea how useful or real it is
<veltas>
Who wrote this?
<veltas>
No copyright or author
<lispmacs[work]>
is there a `pick' implementation in forth somewhere handy that I could copy and paste?
<KipIngram>
: pick 3 << sp@ + @ ;
<KipIngram>
or something like that.
<KipIngram>
Depends on exactly how your sp@ works, which direction your stasck goes, etc.
<KipIngram>
And 3 << is for 64-bit cells.
<KipIngram>
You might need a 1+ or 1- in there to get exactly what you want, just before the 3 <<.
<veltas>
Or do you want an implementation in standard forth?
<KipIngram>
:-)
<lispmacs[work]>
whatever is easiest. FlashForth doesn't have pick but it would be handy right now
<veltas>
Easiest/fastest is KipIngram's suggestion
<KipIngram>
I don't have pick in mine, but I have something else that gives me access to the deep stack.
<veltas>
Standard forth is hard and slow
<KipIngram>
It DOES come in handy now and then.
<veltas>
That's basically what PICK does
f-a has left #forth [#forth]
<lispmacs[work]>
cell . 2 ok
<KipIngram>
lispmacs[work]: Hard-core Forthwrights will tell you that if you need pick you're doing something wrong. I see where they're coming from, but I think it's true only a large fraction of the time, with some exceptions.
<KipIngram>
Oh, then 1 <<
<KipIngram>
Or 2* if you have it.
<lispmacs[work]>
KipIngram: I imagine there wright, but I didn't want to rewrite the other 8 lines of code I already wrote for a different forth
<KipIngram>
I think they're "mostly right." But sometimes you just have a set of values that you need all of. I find that to be the case in QUERY/EXPECT, especially after I add command line history. You've got six or seven things you need to juggle.
<veltas>
I don't consider myself "hard-core", and I think "PICK" is legit, use it all you want.
<veltas>
If it makes your code shorter then do it
<KipIngram>
I created a "stack frame" system, that lets me access deep stack with words that always point to the same place (rather than move around as the stack pointer changes).
<lispmacs[work]>
FlashForth does not have a <<
<KipIngram>
Maybe with a different name? lshift or something?
<lispmacs[work]>
but does have a 2*
<KipIngram>
Ok - well, that's the best one for you anyway. Shortest.
<lispmacs[work]>
there is an lshift
<KipIngram>
Ok. << and >> are just my names for the shift operations.
* KipIngram
likes symbols.
<lispmacs[work]>
: pick 2* sp@ + @ ; appears to be working
<KipIngram>
Most implementations see to have their data stacks grow downward.
<KipIngram>
I guess because that's how most microprocessor stacks work.
<KipIngram>
I go down with data and up with return, toward each other.
<veltas>
It works better that way generally, it means that sp[0] is the current item, sp[1] is next, etc
<KipIngram>
I fill that range at initialization with 0xA7; that way I can inspect the range later to see how far my stacks have grown.
<veltas>
It's my reason to not change the direction
<KipIngram>
veltas: makes sense.
<KipIngram>
I never really thought about it - I just did what I Found already out there. :-)
<KipIngram>
But it does make accessing the stack like an array more intuitive.
<veltas>
I am one of those people that likes to understand *why* and not just *how*
<KipIngram>
:-) Me too, usually. Just didn't find this one that interesting at the time. But I totally agree.
<veltas>
"more intuitive" and more performant probably, on older architectures
<KipIngram>
You do better work that way.
<veltas>
I think it's a legitimate approach
<KipIngram>
It is.
<KipIngram>
It's one of the reasons I don't exactly care for the very strong "library based" approach of typical programming. Stiching together work others did that you don't really understand - that just can't lead to a "best" solution.
<KipIngram>
It's one of the things that draws me to Forth in the first place - that I can *totally* understand the whole thing.
<KipIngram>
I'm the same way with my hardware. I learned to do FPGA design back when the only approach was to draw a schematic, with gates and registers and so on.
<KipIngram>
I don't care for the modern "behavioral" Verilog approach that trusts a synthesizer to create the logic for you.
<KipIngram>
Even when I use Verilog, I still use it "structurally" and call out the circuit item by item.
<KipIngram>
I prefer schematics, though - just the shape of the circuit on the page conveys meaning.
<KipIngram>
You can see things like reconvergent fanout and so on.
gravicappa has quit [Ping timeout: 252 seconds]
<xybre>
Lack of proper library support means it's annoying to iterate on my own ideas and reuse my own projects without just copying and pasting, so while ecosystems like Node are full of oneliner libraries, I feel like a good balance can be struck.
Zarutian_HTC1 has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
<xybre>
I just looked at Dawn, it sure looks like my forth-like VM blacklight, semantically.
<xybre>
The creation of inline stacks is pretty fun
<xybre>
I'm not 100% sure how Dawn does it, I haven't looked at the source yet, but in blacklight there's a few different ways of doing "inline stacks".
Lord_Nightmare has joined #forth
<xybre>
Firstly, you can switch to a fresh stack at any time using $new and then kill that stack and return to the previous one with $drop.
<KipIngram>
Oh man. Forth, Haskell, C, and Rust.
<KipIngram>
Ok, that's kind of interesting.
<KipIngram>
Is the old one completely unavailable while you've got the new one?
<KipIngram>
I'm trying to see why that's better than just growing the one stack taller.
<kiedtl>
That wasn't my impression
<xybre>
It's decoupled from any idea of a function, and you can still reference the previous stack to store your results, or even get a reference to the "metastack" directly that contains all the others
<kiedtl>
that the old stack is unabailable
<kiedtl>
what xybre
<kiedtl>
said
<KipIngram>
Ok.
<KipIngram>
So that means your instructions have to have a stack specifier in them.
<KipIngram>
Sort of like register specifiers in normal CPU instructions.
<KipIngram>
You lose implicit addressing.
<xybre>
Hmm. Kinda. There's an implicit "current" stack that all operations focus on. Then there's a small collection of additional bytecodes which refer to the previous or meta stacks.
<KipIngram>
This is ever so slightly like what my stack frames do. I don't crate a new stack, but I can access items in the old stack in a uniform way, and you can get back to it cleanly at the end.
<KipIngram>
And store results in it.
<xybre>
Yeah it's a lot like a stack frame, but there's no function call necessary and instructions continue being read from the same input stream. A tactic I use is like drop into a new stack, do a bunch of stuff and push the result to the previous stack, then drop. So there's only one "deallocation" and less stack shuffling.
<kiedtl>
Note, this is more of a general-purpose concatenative language, not an actual FORTH implemented in assembly for low-level stuff.
<KipIngram>
I just load a register with the stack pointner value when I open the frame, and then I can access relative to that register. And when I close the frame it whacks the stack back to that point, and also n items further, with n passed to the close frame word.
<xybre>
kiedtl: Yeah and same for blacklight. I can't speak to the design of Dawn.
<KipIngram>
Yes, that makes sense.
<kiedtl>
:120
<kiedtl>
oops
<KipIngram>
It's kind of handy to not have to worry about a completely correct cleanup.
<xybre>
I've fantasized about implementing a subset of blacklight in an FPGA. But it is significantly more complex than a real Forth.
<KipIngram>
And as you pointed out, it's more efficient than a bunch of drops.
<KipIngram>
I have a second set of words that do a frame on both stacks. That lets me return all the way through a deep set of calls to a point higher up.
<xybre>
Yeah it's both cleaner for a memory management and a coding perspective. I think it can be implemented closer to the metal whle still having that high level safety by using stack guards and checks, which would only be needed on operations which drop values anyway.
<KipIngram>
That one is {| ... |}, and there can be other |} instances down in the code in between.
<xybre>
Oh that's cool, like a stack break to label (or goto)
<KipIngram>
It returns the data stack to its original state, except for TOS.
<xybre>
Yeah that's cool, I dig it
<KipIngram>
TOS is the way I pass a result back up. Since it's cached in a register anyway, it was clean to implement that.
<xybre>
Yeah I got it, that's clever
<KipIngram>
I use that in FIND. I'm way down at the bottom of a bunch of nested loops, searching through a list of vocabularies and each those a list of words and each of those a list of characters.
<KipIngram>
Then suddenly I find a match. So I just |} all the way back out.
<xybre>
When I was implementing an array type I was trying to reuse some code and realized I could drop into a new stack and return it casted to the array type. This meant there was no custom syntax inside. So ( 1 2 3 ) give an array of 3 elements like you'd expect, but ( 1 2 3 add ) returns an array of 2 elements of 1 and 5. I dunno why but I love it.
<KipIngram>
Not only does it improve performance (a little), but it simplifies the codeing of those loops, because they don't have to be able to carry a successful result all the way back up through themselves.
<KipIngram>
xybre: That's very cool seeming.
<xybre>
That's a cool stackified long return with |}. I don't quite know what to call it, but I totally see the use case.
<xybre>
Another neat thing, not really stack-related, is that blacklight is a VM that can disassemble it's own bytecode back into mnemonic symbols, modify them and reassemble them back into bytecodes.
<xybre>
I think I only got that working a month or so ago. Felt great. I should still do more testing.
Zarutian_HTC1 is now known as Zarutian_HTC
<KipIngram>
I don't know what to call it either, really. I guessit's a little like setjmp / longjmp in C, but I'm not really sure.
<xybre>
Yeah it sounds like it. What is your project that implements it?
<KipIngram>
It's just the Forth I'm currently working on, in assembly with nasm.
<KipIngram>
I haven't put it up anywhere yet.
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
WQX has joined #forth
<WQX>
hello i'm new in forth, could someone tell me how do i declare an matrix of floating points using gforth?
<KipIngram>
Forth is a typeless language. It deals with integers, which can be either values or addresses, and has some support for shorter word lengths. You can allocate RAM for a matrix with the word ALLOT. To treat it as a matrix, you have to do all of your own addressing calculations and so on. Forth has no native "subscripting" capability.
<KipIngram>
There is usually a consant called CELL that is an integer specifying bytes per cell, so you can multiply by that in calculating the right address of an entry.
<KipIngram>
You decide whether to store by rows or columns, and pretty much everything else.
<KipIngram>
So to declare an NxM floating point matrix, let's say you're using 64-bit floats (8 bytes), you'd do
<KipIngram>
CREATE ARRY_NAME N M * 8 * ALLOT
<KipIngram>
Then when you execute ARRAY_NAME you get the base address of the array on the stack. You'd then calculate the offset to the i, j -th entry and add to that.
<KipIngram>
Then you have a memory address you can store to or fetch from.
<KipIngram>
In other words, all the stuff the compiler usually does for you.
<KipIngram>
You can write words to "sugar coat" those calculations in some sort of syntax if you like.
<KipIngram>
Forth even gives you a more sophisticated capability where you could arrange to be able to say
<KipIngram>
i j ARRAY_NAME
<KipIngram>
and wind up with the address of that cell on the stack. That uses a facility called CREATE / DOES>, and it's something of an advanced topic that I won't try to describe here.
<KipIngram>
But if you look that up (CREATE / DOES>) you can learn how it works - that's just one example of what you cna do with it.
<WQX>
KipIngram: thank you very much, i will study a little more about the function (CREATE / DOES>)