11:13:01
##forth
<veltas>
I had an interesting (at least to me) issue with my assembly .so Forth, you have to mark all 'global data' as being such, and say how large each object is.
11:13:30
##forth
<veltas>
I had assumed it would all be kept together, and so had essentially fth_sp_max and fth_sp0 defined at start and end of stack region
11:14:13
##forth
<veltas>
But fth_sp0 only said it was small (size of the padding/canary) so it was placed in a very different address to fth_sp_max which I think got its own page or something
11:14:32
##forth
<veltas>
But basically they were moved to totally different addresses, rather than being contiguous
11:14:50
##forth
<veltas>
At least I think that's what was happening
14:04:17
##forth
<crc>
xentrac: my system won't be submilliwatt; the Teensy 4.1 draws about 100mA at its default clock speed, not including display or other i/o devices
14:07:16
##forth
<crc>
it also won't be as efficient as a native system, (my forth runs on an emulated misc-style vm)
14:49:02
##forth
<pgimeno>
does gforth support colonoscopy?
14:50:44
##forth
<pgimeno>
ah found it, the see word
14:53:13
##forth
<veltas>
:P
14:53:17
##forth
<veltas>
Very good
15:34:31
##forth
<Seabass_>
2 questions
15:34:41
##forth
<Seabass_>
1. Has anyone here actually developed on a GreenArray chip?
15:35:14
##forth
<Seabass_>
2. Does it make sense to switch to storing actual bytecode in my VM instead of function ptrs? Storing function pointers seems a little convoluted and not readable
15:36:00
##forth
<veltas>
Do whatever makes more sense to you
15:36:47
##forth
<veltas>
Bytecode is fine, neither way is 'optimal' anyway so I don't see the need to compromise on readability
15:37:18
##forth
<veltas>
Bytecode also is closer to something cross-platform, if you ever wanted to pre-compile stuff etc
16:01:36
##forth
<Seabass_>
Bytecode allows for nicer debug prints as well
16:01:50
##forth
<Seabass_>
This is such an overly-complicated implementation XD
16:03:10
##forth
<veltas>
There's a well-founded reason that I claim it's easier to write Forths in assembly than C :P
16:03:25
##forth
<veltas>
It's mostly based on experiences people've had in here, including myself
16:05:02
##forth
<GeDaMo>
I seem to remember problems with C's type system
16:06:10
##forth
<veltas>
That's not even a problem I've encountered, but I don't doubt that's yet another issue with this
16:20:40
##forth
<zelgomer>
it's easier to write a native forth in asm than in c, but if you're happy with a vm layer, i've settled on what i think is a pretty nice, very simple model
16:41:13
##forth
<Seabass_>
zelgomer: do you have a link?
16:42:41
##forth
<zelgomer>
no
16:42:55
##forth
<zelgomer>
but i can describe it if you want
16:49:02
##forth
<zelgomer>
i create a virtual memory address space for the forth vm. a block is an array of 256 32-byte words (uint_least32_t), and these are allocated on demand when they're accessed, and they're tracked in a 16-bucket hash table where the hash function is something that looks kind of like fnv-1a but modified to hash by nibble (since the end result needs to be modulo 16)
16:49:59
##forth
<zelgomer>
execution of the vm is simple: code words are tokenized below some address. so if you have 23 code words, then addresses 0-23 are interpreted as code words. execution of any other value is understood to be an implicit nest.
16:51:08
##forth
<zelgomer>
so my execute code is something like: { uint_least32_t xt = pop(&sp); if (xt < ncodewords) { codewords[n](); } else { *push(&rp) = pc; pc = xt; } }
16:51:44
##forth
<zelgomer>
then the main loop ends up looking like /* push the address of your entry point here */; while (1) { execute(); lit(); }
16:53:07
##forth
<zelgomer>
and finally, the parameter stack and return stack are just linked lists that allocate nodes on demand. the api looks like uint_least32_t pop(struct stack *); uint_least32_t *push(struct stack *);
16:54:15
##forth
<zelgomer>
i should point out i haven't profiled any of this. performance is not the focus here, the idea in my case is just to have an extremely simple and portable vm that can be used to bootstrap compilers, which then produce native binaries
17:20:39
##forth
<KipIngram>
I felt like the main thing that lowered my opinion of my C Forth "as a Forth" was the fact that I wasn't keeping key variables in registers.
17:21:04
##forth
<KipIngram>
Aside from that, at least using gcc and its extensions it was fairly straightforward to build a "real" Forth.
17:21:34
##forth
<KipIngram>
My primmitives were snips of C, but I could have replaced them with code inside the image I built the system in if I'd wanted to.
17:22:36
##forth
<KipIngram>
And I suppose if I'd done that I could have used machine code that DID use the registers in an intelligent way - once this whole mess was running, it never left the system except when it needed OS support.
17:25:08
##forth
<pgimeno>
uh, is there anyone here who's not writing a Forth interpreter or compiler?
17:26:26
##forth
<zelgomer>
no, this is ##forth
17:27:47
##forth
<pgimeno>
I thought it was for language users , not compiler writers 😂
17:29:40
##forth
<zelgomer>
in the sphere of forth, those are the same thing
17:29:53
##forth
<pgimeno>
haha, okah
17:29:57
##forth
<pgimeno>
okay*
17:30:25
##forth
<pgimeno>
I happen to be writing one myself, one exclusively for the JA, to solve the shortcomings in my previous one
17:36:11
##forth
<zelgomer>
what is the JA?
17:47:33
##forth
<crc>
zelgomer: likely the jupiter ace (pgimeno has done work w/that in the past, according to my logs)
17:47:54
##forth
<pgimeno>
ah yes indeed, sorry
17:56:24
##forth
<zelgomer>
oh yeah, sorry. i was following that adventure before the holidays, i just forgot
17:57:32
##forth
<pgimeno>
the previous one is compiler-only and has no interpreting capabilities, so no [] LITERAL which sucks (I could have used it in the program I was writing)
18:55:14
##forth
<Seabass_>
zelgomer: I haven’t even written any Forth code
18:55:33
##forth
<Seabass_>
This interpreter is very over-engineered, I mostly picked Forth for its simple syntax
18:55:55
##forth
<Seabass_>
My main goal is to just learn the basics so I can write a Scheme interpreter
18:58:40
##forth
<Seabass_>
I do want to walk through Virgil’s Forth tutorials though
19:01:21
##forth
<lilo_booter>
i for one have been playing with developing stuff in gforth pgimeno - nothing useful though, just toy stuff for fun
19:19:45
##forth
<zelgomer>
Seabass_: you might be interested to take a look at joy or factor. when it comes to forth, as in classic or traditional forth, part of the challenge is that there is largely an expectation to manipulate raw memory directly. this isn't strictly a requirement of the idea of forth as a language, but most of the core vocabulary is designed around it. languages like joy and factor take the concatenative rpn
19:19:51
##forth
<zelgomer>
style but the vm is more abstract like your typical interpretated language
19:22:36
##forth
<MrMobius>
Seabass_: if it's just a learning experience, Python really simplifies things
19:32:36
##forth
<Seabass_>
Well, my goal is to learn C and also learn about writing interpreters
19:32:52
##forth
<Seabass_>
I used Python to implement a limited subset of Scheme and Forth already
19:34:01
##forth
<Seabass_>
zelgomer: i kinda figured that was the case, since all the examples I have seen that are simple implement all the stack operations with the memory access primtives (@ and * I believe?)
19:34:14
##forth
<Seabass_>
Vs my implementation which has actual data structures passed around everywhere
19:46:54
##forth
<skvery>
@pgimento ...also look at Mecrisp.
21:01:25
##forth
<clemens3>
is there any way to build gforth from source without having gforce?
21:02:11
##forth
<clemens3>
tried to build 0.7.2 but it failed with engine/prim.i error message using a preforth script
21:17:55
##forth
<thrig>
maybe use a head branch? gforth 0.7.3 ran into "compiler runs forever" or "compiler fails" last I tried it on a modern system
21:18:14
##forth
<thrig>
probably some bitrot for being too clever with the compiler
21:26:12
##forth
<zelgomer>
Seabass_: @ and !
22:19:13
##forth
<veltas>
clemens3: Try to build latest release of 0.7.3
22:19:31
##forth
<veltas>
And then if you want later code, install 0.7.3 and build a snapshot
22:23:43
##forth
<veltas>
KipIngram: When you implemented turning signals into exceptions, did you look into how this is done in C?
22:24:22
##forth
<veltas>
I've seen stuff stated that you can longjmp (or maybe siglongjmp?) from a signal back to code, I think this would suffice, but obviously that's using C library so no good if you don't want to link the C library
22:27:36
##forth
<veltas>
But in my code I am more concerned with making stuff interoperable anyway
22:28:25
##forth
<veltas>
I found out that the longjmp mechanism in one of the 64-bit x86 ABI's actually hooks into the generic exception handling mechanism
22:28:45
##forth
<veltas>
So is equivalent to C++ throw
22:32:44
##forth
<veltas>
At least re being able to call destructors etc, if I understand right
23:21:46
##forth
<clemens3>
veltas: thanks, it worked! I thought 0.7.3 needs gforth for building, but it seems not. great!
23:31:36
##forth
<veltas>
It's no problem, really, I am the gforth whisperer
23:32:55
##forth
<clemens3>
heh, cool