2025-01-02 11:13:01 <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.
2025-01-02 11:13:30 <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
2025-01-02 11:14:13 <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
2025-01-02 11:14:32 <veltas      > But basically they were moved to totally different addresses, rather than being contiguous
2025-01-02 11:14:50 <veltas      > At least I think that's what was happening
2025-01-02 14:04:17 <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
2025-01-02 14:07:16 <crc         > it also won't be as efficient as a native system, (my forth runs on an emulated misc-style vm)
2025-01-02 14:49:02 <pgimeno     > does gforth support colonoscopy?
2025-01-02 14:50:44 <pgimeno     > ah found it, the see word
2025-01-02 14:53:13 <veltas      > :P
2025-01-02 14:53:17 <veltas      > Very good
2025-01-02 15:34:31 <Seabass_    > 2 questions
2025-01-02 15:34:41 <Seabass_    > 1. Has anyone here actually developed on a GreenArray chip?
2025-01-02 15:35:14 <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
2025-01-02 15:36:00 <veltas      > Do whatever makes more sense to you
2025-01-02 15:36:47 <veltas      > Bytecode is fine, neither way is 'optimal' anyway so I don't see the need to compromise on readability
2025-01-02 15:37:18 <veltas      > Bytecode also is closer to something cross-platform, if you ever wanted to pre-compile stuff etc
2025-01-02 16:01:36 <Seabass_    > Bytecode allows for nicer debug prints as well
2025-01-02 16:01:50 <Seabass_    > This is such an overly-complicated implementation XD
2025-01-02 16:03:10 <veltas      > There's a well-founded reason that I claim it's easier to write Forths in assembly than C :P
2025-01-02 16:03:25 <veltas      > It's mostly based on experiences people've had in here, including myself
2025-01-02 16:05:02 <GeDaMo      > I seem to remember problems with C's type system
2025-01-02 16:06:10 <veltas      > That's not even a problem I've encountered, but I don't doubt that's yet another issue with this
2025-01-02 16:20:40 <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
2025-01-02 16:41:13 <Seabass_    > zelgomer: do you have a link?
2025-01-02 16:42:41 <zelgomer    > no
2025-01-02 16:42:55 <zelgomer    > but i can describe it if you want
2025-01-02 16:49:02 <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)
2025-01-02 16:49:59 <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.
2025-01-02 16:51:08 <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; } }
2025-01-02 16:51:44 <zelgomer    > then the main loop ends up looking like   /* push the address of your entry point here */; while (1) { execute(); lit(); }
2025-01-02 16:53:07 <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 *);
2025-01-02 16:54:15 <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
2025-01-02 17:20:39 <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.
2025-01-02 17:21:04 <KipIngram   > Aside from that, at least using gcc and its extensions it was fairly straightforward to build a "real" Forth.
2025-01-02 17:21:34 <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.
2025-01-02 17:22:36 <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.
2025-01-02 17:25:08 <pgimeno     > uh, is there anyone here who's not writing a Forth interpreter or compiler?
2025-01-02 17:26:26 <zelgomer    > no, this is ##forth
2025-01-02 17:27:47 <pgimeno     > I thought it was for language users, not compiler writers 😂
2025-01-02 17:29:40 <zelgomer    > in the sphere of forth, those are the same thing
2025-01-02 17:29:53 <pgimeno     > haha, okah
2025-01-02 17:29:57 <pgimeno     > okay*
2025-01-02 17:30:25 <pgimeno     > I happen to be writing one myself, one exclusively for the JA, to solve the shortcomings in my previous one
2025-01-02 17:36:11 <zelgomer    > what is the JA?
2025-01-02 17:47:33 <crc         > zelgomer: likely the jupiter ace (pgimeno has done work w/that in the past, according to my logs)
2025-01-02 17:47:54 <pgimeno     > ah yes indeed, sorry
2025-01-02 17:56:24 <zelgomer    > oh yeah, sorry. i was following that adventure before the holidays, i just forgot
2025-01-02 17:57:32 <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)
2025-01-02 18:55:14 <Seabass_    > zelgomer: I haven’t even written any Forth code
2025-01-02 18:55:33 <Seabass_    > This interpreter is very over-engineered, I mostly picked Forth for its simple syntax
2025-01-02 18:55:55 <Seabass_    > My main goal is to just learn the basics so I can write a Scheme interpreter
2025-01-02 18:58:40 <Seabass_    > I do want to walk through Virgil’s Forth tutorials though
2025-01-02 19:01:21 <lilo_booter > i for one have been playing with developing stuff in gforth pgimeno - nothing useful though, just toy stuff for fun
2025-01-02 19:19:45 <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
2025-01-02 19:19:51 <zelgomer    > style but the vm is more abstract like your typical interpretated language
2025-01-02 19:22:36 <MrMobius    > Seabass_: if it's just a learning experience, Python really simplifies things
2025-01-02 19:32:36 <Seabass_    > Well, my goal is to learn C and also learn about writing interpreters
2025-01-02 19:32:52 <Seabass_    > I used Python to implement a limited subset of Scheme and Forth already
2025-01-02 19:34:01 <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?)
2025-01-02 19:34:14 <Seabass_    > Vs my implementation which has actual data structures passed around everywhere
2025-01-02 19:46:54 <skvery      > @pgimento  ...also look at Mecrisp.
2025-01-02 21:01:25 <clemens3    > is there any way to build gforth from source without having gforce?
2025-01-02 21:02:11 <clemens3    > tried to build 0.7.2 but it failed with engine/prim.i error message using a preforth script
2025-01-02 21:17:55 <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
2025-01-02 21:18:14 <thrig       > probably some bitrot for being too clever with the compiler
2025-01-02 21:26:12 <zelgomer    > Seabass_: @ and !
2025-01-02 22:19:13 <veltas      > clemens3: Try to build latest release of 0.7.3
2025-01-02 22:19:31 <veltas      > And then if you want later code, install 0.7.3 and build a snapshot
2025-01-02 22:23:43 <veltas      > KipIngram: When you implemented turning signals into exceptions, did you look into how this is done in C?
2025-01-02 22:24:22 <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
2025-01-02 22:27:36 <veltas      > But in my code I am more concerned with making stuff interoperable anyway
2025-01-02 22:28:25 <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
2025-01-02 22:28:45 <veltas      > So is equivalent to C++ throw
2025-01-02 22:32:44 <veltas      > At least re being able to call destructors etc, if I understand right
2025-01-02 23:21:46 <clemens3    > veltas: thanks, it worked! I thought 0.7.3 needs gforth for building, but it seems not. great!
2025-01-02 23:31:36 <veltas      > It's no problem, really, I am the gforth whisperer
2025-01-02 23:32:55 <clemens3    > heh, cool