2024-10-13 00:48:26 xentrac: How would you imagine that C would be compiled on a system you're bringing up? 2024-10-13 00:48:59 Forth supplies everything needed for all that, and does so in a package that you can very reasonably write yourself. 2024-10-13 00:49:46 And if you really go whole hog and do it Chuck's way, you can bring the whole thing up starting with just a monitor that lets you poke bytes into RAM. 2024-10-13 00:51:04 Again, I like C - I really do. I just believe that for the sort of task I'm most interersted in, Forth can't be beaten. 2024-10-13 00:51:13 It's kind of "what Forth si for." 2024-10-13 00:51:17 is 2024-10-13 01:18:35 forth is self hosting in a very small amount of code 2024-10-13 01:28:03 KipIngram: sure, if you're the one writing the toolchain for the vendor for a new microcontroller, or if you don't want to use the vendor's toolchain, Forth is a pretty good tool 2024-10-13 01:29:09 generally though when people want to bring up C on a new system they start by cross-compiling it from a system that already supports C 2024-10-13 01:32:19 not always, of course. The original C compiler, Jeremiah Orians's M2-Planet, and BDS C are three of the many C compilers that have been written in assembly 2024-10-13 01:33:32 amby> forth is self hosting in a very small amount of code 2024-10-13 01:34:21 is it? can you please explain it to me? because i've been trying to figure this out for an embarassing length of time. 2024-10-13 01:34:35 maybe i'm just stupid but i just don't get it 2024-10-13 01:35:28 zelgomer: it's a very tricky small amount of code 2024-10-13 01:35:32 i'm starting to think the people who say this are just repeating what they've heard and have never actually written a self hosting, cross compiling forth 2024-10-13 01:35:34 but sure, F83 is self-hosting for example 2024-10-13 01:35:41 I've never *written* one 2024-10-13 01:36:12 and i've never seen anyone capable of explaining it 2024-10-13 01:36:24 F83 is about 1200 lines of code 2024-10-13 01:36:40 C. H. Ting did write a book purporting to explain it 2024-10-13 01:37:22 wait no 2024-10-13 01:37:42 write a forth in asm 2024-10-13 01:37:46 write an assembler in forth 2024-10-13 01:37:52 2400 2024-10-13 01:37:53 rewrite the same forth for the forth assembler 2024-10-13 01:38:21 F83 isn't written entirely in assembly, though; most of it is written in Forth 2024-10-13 01:38:35 that's the main thing 2024-10-13 01:40:25 I generated four Unix-style line-based files (cpu8086.fs kernel86.fs meta86.fs utility.fs) with http://canonical.org/~kragen/sw/dev3/blk2unix.py 2024-10-13 01:40:44 running cat *.fs | sed 's/\\.*//' | sort -u | wc says 2053 16031 125010 2024-10-13 01:40:51 so I guess about 2100 lines of code 2024-10-13 01:41:15 amby: how do you do that without tripping all over your own words? once i define : for the target, then you can't call : for the host anymore. so tben you play games with vocabularies and the context stack, but it's a damn mess. so then you try to make words aware, so if you execute : at compile time it does one thing but when you compile : it compiles something different, and you find this is full of 2024-10-13 01:41:21 tricky gotchas and corner cases 2024-10-13 01:41:55 my avr assembler does a horrendous hack with the dictionary 2024-10-13 01:42:11 zelgomer: yes, you play games with vocabularies and the context stack. Ting's book does spend some time explaining this, as do the F83 shadow screens 2024-10-13 01:42:16 where { and } swap out and in a section of the dictionary respectively 2024-10-13 01:42:49 so after loading asm.f, : creates a function that generates an avr call instruction 2024-10-13 01:43:11 { temporarily removes the section of the dictionary that contains the new version of : 2024-10-13 01:43:45 also the function that the assembler's : creates also goes in that section of the dictionary 2024-10-13 01:43:55 see? that's what i usually see. people make it work with these horrible, fragile hacks. i'm starting to wonder if a simple c compiler would really be any worse than this confusing mess. 2024-10-13 01:44:27 as do all of the avr instructions, so (for example) the AND instruction doesn't conflict with forth's AND word 2024-10-13 01:45:06 you could also just define A: 2024-10-13 01:45:54 and then refine {} further into a proper module system 2024-10-13 01:49:33 yes, they're horrible fragile hacks 2024-10-13 01:49:50 but we're also talking about horrible fragile hacks whose entire scope is like 500 lines of code 2024-10-13 01:50:54 500 lines of forth sounds like a lot to me 2024-10-13 01:52:19 anyway, sorry. i go through ups and downs. i'm in a down period right now with my forthing. i'm just realizing that i lost the plot several months ago and have been going off into the weeds again. 2024-10-13 01:53:24 i had something almost usable earlier this year, but i shifted the goal posts. now i'm trying to reset and get back there again, mentally speaking 2024-10-13 01:54:59 amby: idk if this is similar to your description, but i also have { } words. the difference in my case is that { enables a sort of overlay thread in the word search 2024-10-13 01:56:45 all of my vocabs have two head pointers. when outside of { }, find searches only one. when inside of { }, find searches the other, and if it doesn't find the word, then it still searches in the first thread 2024-10-13 01:56:55 I understand how that happens 2024-10-13 02:01:05 amby: how do you specify what goes into rom versus what goes into rw memory? do you have a create for rom data and a different create for e.g. eeprom, or do you just use prefix words like gas .date or .rodata, or something else? 2024-10-13 02:01:37 instructions just compile themselves into a preallocated buffer 2024-10-13 02:01:47 in the case of an atmega328, that's 32k 2024-10-13 02:02:27 labels are just labels, because it's not compiling a forth, just regular code 2024-10-13 02:08:44 right, that makes sense 2024-10-13 02:09:30 zelgomer: if I understand correctly, Jeremiah said he wrote the M2-Planet C compiler in a night in assembly, but I think that's a feat far beyond my abilities 2024-10-13 02:10:54 xentrac: Sure, and I have nothing against that approach. It just doesn't fit my particular interests. And honestly I have no interest in punching a Forth in starting from a monitor - I plan to use gcc on my notebook as my "launch platform" too. I don't, though, want to resort to vendor tools; the micro board of main interest to me is one I deliberately chose for its ability to let you drop a 2024-10-13 02:10:54 <4.pbiaas.com> firmware image onto the storage device it presents to your computer when you connect it, and it will handle the programming from there. 2024-10-13 02:11:23 I plan to use gcc to generate my firmware image. And I plan some Forth emulation in that, so I guess you could say that what I really want is to write my own dev kit. 2024-10-13 02:11:41 KipIngram: its bootloader sounds like a relatively extensive set of vendor tools 2024-10-13 02:11:53 I bet it supports remote debugging too 2024-10-13 02:12:17 Possibly; I haven't needled into that. 2024-10-13 02:12:38 But yeah, obviously you have to have some way to get code into the thing. 2024-10-13 02:12:54 In the old days that would have just been an EPROM programmer. 2024-10-13 02:13:02 AVR high-voltage programming is pretty similar to an EPROM programmer 2024-10-13 02:13:20 And that would have covered pretty much every processor out there, since they could all read from EPROM. 2024-10-13 02:14:06 The massive "integration" that has occurred in these things over the years is all well and good - lots of benefits - but it has complicated the software requirements quite a lot. 2024-10-13 02:16:51 yeah 2024-10-13 02:20:45 xentrac> zelgomer: if I understand correctly, Jeremiah said he wrote the M2-Planet C compiler in a night in assembly 2024-10-13 02:21:39 claims like that make me think they're either bullshit or something about software development has been lost 2024-10-13 02:22:00 like an undetstanding 2024-10-13 02:35:42 well, it doesn't support all of C. And I'm guessing that at the end of the night it supported even less of C 2024-10-13 02:40:09 than it does today 2024-10-13 02:41:38 i should probably take a stab at a c compiler, just to see what it takes 2024-10-13 02:45:45 many of them would benefit from being stabbed many times 2024-10-13 02:54:38 et tu brute 2024-10-13 20:23:33 zelgomer: Sometimes I think we should just write assembly 2024-10-13 20:23:52 Like "I wrote a C compiler in assembly in a night" to me means "you should actually just use assembly" 2024-10-13 20:25:19 veltas: I find it to be a bit faster to write code in C than in assembly, but *enormously* faster to *read* it 2024-10-13 20:25:48 You're right assembly is much easier to read than C 2024-10-13 20:27:07 I'm slowly realising C compilers even today are *very clever* but apparently not that good at writing assembly 2024-10-13 20:27:53 I'm getting that feeling people have about 'AI' right now where the veil is lifted 2024-10-13 20:27:57 sometimes i think software just sucks and we should all stop 2024-10-13 20:28:02 Agreed 2024-10-13 20:28:44 Nah I actually think software is good, I think it's better to use an MCU than like 30 equivalent discrete chips for something 2024-10-13 20:29:07 But using a few chips is probably better than using an MCU if it will do same job 2024-10-13 20:31:53 I think C is enormously easier to read than assembly 2024-10-13 20:32:16 and it's true that C compilers aren't very good at writing assembly. But they're usually better than I am 2024-10-13 20:37:51 veltas: what do you mean about compilers not being good at writing assembly? 2024-10-13 20:39:27 on x86 they usually outperform handwritten assembly unless youre doing vectors or something. there's just too much weirdness for a human to get right so the non-intuitive compiler output is usually faster 2024-10-13 20:40:20 it depends on the hand 2024-10-13 21:27:20 veltas: it's also like i usually see people say about forth, "it's a great language any programming student should spend a weekend to implement!" 2024-10-13 21:28:12 i'm inclined to say if anyone takes a weekend to implement forth, they've either a) basically written a dc style calculator that doesn't do anything useful, or b) have written forth before 2024-10-13 21:28:51 dc does some useful things 2024-10-13 21:29:28 yes that's not what i meant, though. the goal was to write a forth and not dc. 2024-10-13 21:29:40 i love dc 2024-10-13 21:31:23 i see my colleagues trying to cram python onto a tiny system in a place where a shell script would have worked just fine. "but i can't do math with it!" and then i show them dc is already built into busybox. 2024-10-13 22:16:56 to write a proper forth needs some time knowing everything 2024-10-13 22:17:15 but to read a word and use a hash table takes some minutes 2024-10-13 22:17:53 those people mean concat lang when they say forth 2024-10-13 22:21:15 a stack rpn toy interpreter is a great introduction to making interpreters, because the stack allows you to not care about passing parameters and the interpreter can be quite simple 2024-10-13 22:21:51 just needs to read a word and check it on the hash table. from there you can expand in the direction you want 2024-10-13 22:22:40 but to make a forth you need a return stack and to know how the dictionary is implemented, provide here, create and does, postpone, defer, etc 2024-10-13 22:50:54 yeah you can make an rpn calculator in a couple hours, maybe less 2024-10-13 22:55:39 vms14: Yes, but the code to read that word and implement that hash table and so on is no doubt built into some tool that would take you much much longer to develop than a Forth would. If you were really starting without anything, the Forth would be much faster to develop. 2024-10-13 22:56:27 You still working in Perl? I'm not familiar enough with it to know how long it would take to write a Perl, but I imagine it would be a while. 2024-10-13 23:13:01 a real forth? I keep wondering, I should start by faking memory using an array and I always disliked the idea 2024-10-13 23:14:56 but a toy rpn lang instead is quite easy, the stack can get any type of value and there is a garbage collector that allocates and frees memory for you 2024-10-13 23:15:58 anyways I try to learn from forth and keep things easy, I made a fake compilation by returning functions with the actions the interpreteer would take, this allows for an old definition to be retained, which is what forth does 2024-10-13 23:16:21 also got rid of lexical scope and the "dictionary" is just a hash table, but this time has no parent or alike 2024-10-13 23:16:57 but keeps being so different from forth 2024-10-13 23:18:10 this is what I have in js for now 2024-10-13 23:18:11 https://termbin.com/oyfz 2024-10-13 23:19:41 this time I try to add debugging features without affecting performance if debugging is off, I do it by overwriting functions with an after and/or before method where I can hook runtime checks or alike 2024-10-13 23:20:09 for example: wrap_word(['+', '-', '/', '*', '%'], ()=>{check_numbers(2)}); 2024-10-13 23:20:32 this adds a before function to those words that will check if the two elements of the stack are numbers 2024-10-13 23:21:06 in my mind it makes no sense to stick to a real forth if I use a high level language, specially if I have no memory access 2024-10-13 23:22:22 but I should try to stick to it as much as possible because I've seen how being so different was not helpful and I think forth has a proper design, unlike my lang 2024-10-13 23:22:38 I struggle to find the perfect balance 2024-10-13 23:23:33 debugging is so hard in my toy lang 2024-10-13 23:25:15 made it case insensitive too 2024-10-13 23:26:06 but I would like to have the same syntax for loops and conditionals forth has 2024-10-13 23:31:22 i have had thoughts about typed forth 2024-10-13 23:31:22 never quite worked out how i'd make it all fit together