2024-12-23 00:00:23 Ok, I was thinking of a system with memory protection. 2024-12-23 00:00:23 Where address 1 is usually not an authorized address. 2024-12-23 00:00:36 So I shouldn't have said "any system" or anything close to that. 2024-12-23 00:03:12 any forth running as a userspace program 2024-12-23 00:09:17 I think it's pretty common on microcontrollers with MPUs to be able to read the zero page 2024-12-23 00:09:36 Yeah. 2024-12-23 00:09:54 also, segmentation-based protection schemes like the PDP-11 usually don't have a lower limit on how low you can address, just an upper one 2024-12-23 00:10:53 (which suggests that you ought to use -1 as your null pointer there, but often people don't because jumping on a register being zero is easier) 2024-12-23 00:11:03 Interesting. GForth doesn't seem to have 0 and 1 defined as constants. 2024-12-23 00:11:15 That's not really related to what we're talking about, but I just didn't know that. 2024-12-23 00:11:26 ' 0 and ' 1 throw errors. 2024-12-23 00:11:52 that's interesting! 2024-12-23 00:12:30 Oh man, GForth has COLD but it doesn't reset the dictionary. 2024-12-23 00:12:41 I almost feel like that's a bug. 2024-12-23 00:12:49 F83 of course does have constants for 0 and 1 2024-12-23 00:12:52 In my opinion at least. 2024-12-23 00:13:23 but not, interestingly, -1. Just 0, 1, 2, and 3 2024-12-23 00:22:47 there's no actual lower limit on where userspace can access 2024-12-23 00:22:59 you could map 0 to a userspace process 2024-12-23 00:23:23 it's just nobody does, because you have virtual address space to spare and it's convenient to have null as a sentinel value 2024-12-23 00:35:50 also Linux won't let you 2024-12-23 00:39:33 exactly 2024-12-23 00:40:01 no reasonable operating system would do it 2024-12-23 01:16:21 I could probably come up with scenarios where it would be a useful thing to do. emulating a Commodore 64 or a PDP-11, maybe 2024-12-23 01:20:25 not really? 2024-12-23 01:20:51 because even if you're jit transpiling machine code you can just add a constant to all the emulated memory accesses 2024-12-23 01:21:13 or rather, not a constant 2024-12-23 01:22:43 it's less code and usually faster to not add a constant or base register to all the emulated memory accesses 2024-12-23 01:24:35 the memory access will be much slower than the addition 2024-12-23 01:24:47 even an l1 cache hit is gonna be slower than an add 2024-12-23 01:25:36 no. and making the code smaller reduces the number of L1 cache misses 2024-12-23 01:25:46 but it's kind of speculative because I don't know of anybody doing this 2024-12-23 01:26:08 wym "no" 2024-12-23 01:26:22 an l1 cache hit is like 4 cycles on modern processors 2024-12-23 01:26:39 an add is gonna be 1, tops 2024-12-23 01:26:50 are you saying that every time the CPU wants to fetch an instruction from its L1I cache it has to wait 4 cycles? 2024-12-23 01:26:52 pipelining is magic so you might end up with no overhead in some cases 2024-12-23 01:27:00 yep 2024-12-23 01:27:02 that would limit it to a max of 1 instruction per 4 cycles, like a Z80 2024-12-23 01:27:13 that's why it prefetches so many 2024-12-23 01:28:55 "Intel Haswell's L1 load-use latency is 4 cycles for pointer-chasing, which is typical of modern x86 CPUs. i.e. how fast mov eax, [eax] can run in a loop, with a pointer that points to itself." 2024-12-23 01:29:20 "That 4-cycle latency special case only applies if the pointer comes directly from another load, otherwise it's 5 cycles." 2024-12-23 01:33:43 yeah, I believe it for latency, but I thought we were talking about throughput 2024-12-23 01:38:53 in this case throughput depends on latency 2024-12-23 01:39:25 you're limited by how soon after the load you can do something with the value 2024-12-23 01:41:04 if you're JIT-compiling, ILP in the code you're emulating can manifest as ILP in the compiled code, depending on what you're trying to do and how 2024-12-23 04:24:36 re ' 0 and ' 1, there was a bug in the HP48 ROM where numbers up through about 42 were actually words but an off by one error meant 42 itself wasn't defined so referencing the constant 42 could crash the calculator but not 41 or 43 2024-12-23 04:37:28 it's weird that an off-by-1 would create a hole 2024-12-23 06:15:45 How funny that it was 42. 2024-12-23 10:05:47 zelgomer, vms14: My Forth system is written in AMD64 assembly at moment, designed to interoperate with C code and libraries though. It's a shared object 2024-12-23 10:06:20 I have paused looking at it but need to get it running in some half-baked buggy form before I will make it open, and then you can look 2024-12-23 10:06:34 But I will make it clear it's not 'done' 2024-12-23 10:10:53 Darn I've missed out on a lot of cool conversations this weekend 2024-12-23 10:11:12 I'll have to catch gedamo and pgimeno when they're around again 2024-12-23 10:13:34 pgimeno's code looks absolutely great 2024-12-23 10:15:45 Better than anything I've written in a while 2024-12-23 10:16:07 or ever 2024-12-23 10:17:39 The "solid-state register allocator" looks like a fantastic read, will check that out 2024-12-23 10:22:37 It's clear to me I'll need to understand LuaJIT to write a Forthy Forth optimiser 2024-12-23 13:36:01 veltas: written in gas, i would guess? 2024-12-23 13:36:33 No I'm actually using nasm 2024-12-23 13:37:08 I have found nasm's documentation marginally better for this job, although it's piss poor for both really and you need to do your own legwork to figure out the 2024-12-23 13:37:13 necessary relocations / syntax 2024-12-23 13:37:36 Mostly trying the same in C with GCC and seeing what it dumps, and 'guessing' syntax 2024-12-23 13:37:42 for the assembler 2024-12-23 13:41:24 everything gnu is horribly documented. and not for lack of volume, but presentation and substance are always awful 2024-12-23 13:45:06 I like their info docs, but there are a lot of holes, and unfortunately typical of open source software 2024-12-23 13:45:32 One of the reasons I like small/lightweight software, because then at least I can expect to rely on the source code as documentation 2024-12-23 13:47:43 i hate info 2024-12-23 13:48:51 if i type 'man something' and i find a stub that says "fuck you it's documented in gnu info" i start looking for different software 2024-12-23 13:52:45 I hate super long man pages, info structures that better, but I also hate it if the manpage is incredibly short and defers to info. It should at least attempt to summarise/document what the options do 2024-12-23 13:53:32 But I wouldn't exactly expect or prefer to read e.g. all the different architecture syntax differences in an assembler's manpage, and pages aren't that good at traversing a massive manpage 2024-12-23 13:53:37 info at least has links etc 2024-12-23 13:54:19 I guess it's okay if software breaks it up over many manpages, e.g. git 2024-12-23 14:18:27 might as well just give me the html docs then and open them in lynx. then at least i have some chance of knowing a few of the key bindings 2024-12-23 15:08:01 Well I just view info in browser anyway, I don't use the terminal info app much 2024-12-23 15:11:04 Browser or PDF reader, the PDFs they generate are quite good 2024-12-23 15:11:11 But sometimes they don't maintain the PDF well 2024-12-23 15:14:22 Right - I agree. Man pages are useful, but they're better for certain kinds of information than others. I find they work fairly well for things like listing option flags. But they're not a good way at all to really "learn a tool." 2024-12-23 15:19:42 i hate having to open a graphical browser for anything these days 2024-12-23 15:19:43 instantly watch my system load quadruple 2024-12-23 15:20:49 and doxygen started the most intolerable trend of documenting code with a web page 2024-12-23 15:22:27 is there actually anything on earth worse than having to launch a browser to read about an api? doubtful. 2024-12-23 15:23:14 in general I find the GNU manuals to be first-class. They're complete and comprehensive and generally written with careful thought given to organizing things in a sensible sequence 2024-12-23 15:24:09 GNU find only added examples in 2006, unlike the OpenBSD manual 2024-12-23 15:24:27 and texinfo is enormously better than man pages for large documents (though WWW browsers are better than native info browsers generally) 2024-12-23 15:24:43 also function info { /usr/bin/info "$@" 2>/dev/null | $PAGER; } makes info less horrible 2024-12-23 15:25:41 on a plus side, Debian has started putting everything into manuals, rather than having them scattered across whatever thing folks are into this year 2024-12-23 15:25:55 xentrac: please find me the page that comprehensively documents how i specify x86 registers in an extended asm clobbers list 2024-12-23 15:26:05 thrig: that's a good tip, thsnks! 2024-12-23 15:26:06 the problem with Doxygen is that generally there's no organization by topic or sequencing to minimize forward references 2024-12-23 15:26:29 zelgomer: maybe check the Stack Overflow Kiwix ZIM 2024-12-23 15:27:18 wtf is a kiwix zim? 2024-12-23 15:29:16 ZIM is a file format used for storing web sites offline, Kiwix is a reader 2024-12-23 15:40:29 sorry, my ISP was sabotaged and I was 17 hours without inet, but I've caught up via the channel log. Thanks for the answers. @zelgomer I don't get what you mean about "name your things by what they produce, not by how they do it" as somewhat equivalent to "a variable today could change to a colon definition tomorrow abd still work as long as it takes no args and pushes an address" 2024-12-23 15:43:52 @veltas thanks, I'm surprised that you like it that much, I thought it was really poor (partly due to the BASIC program using very short variable names due to memory constraints, and me translating these names literally) 2024-12-23 15:44:53 It reads well to me, I think some of the names could be better, but importantly it does a job 2024-12-23 15:45:09 The comments are helpful 2024-12-23 15:45:21 by the way, I hate gas "AT&T" style syntax, nasm was a good choice IMO 2024-12-23 15:45:38 Yeah well gas at least supports intel syntax now 2024-12-23 15:46:19 And objdump can spit out that syntax too, which is useful for discovery 2024-12-23 15:46:19 ah I'm very outdated in assemblers for PC 2024-12-23 15:46:42 But objdump won't tell you how to annotate your globals etc for relocation 2024-12-23 15:47:55 nasm at least documents how to do this for 32-bit, and then educated guesswork and the SysV AMD64 supplement lets you get further 2024-12-23 15:51:45 I actually contributed a fix to nasm a while after it appeared; it crashed when you had too many symbols (something to do with a wrong pointer when allocating a new page for more symbols, can't remember the details right now) 2024-12-23 15:52:59 @xentrac I don't know VALUE but more importantly, I'm constrained by what the Jupiter supports, which doesn't include that 2024-12-23 15:53:07 https://thrig.me/tmp/bridge-building.gif 2024-12-23 15:53:34 Also I hope this has been a good exercise, I think Forth is a good candidate for rewriting BASIC, hopefully that's been your experience 2024-12-23 15:54:30 Even this older dialect, has most of what I care for in Forth anyway 2024-12-23 15:55:02 yeah, it became easier and easier in the end. Also Forth looks like a good candidate as a "portable assembler" for the output of a compiler, sort of. 2024-12-23 15:55:17 Absolutely 2024-12-23 15:56:19 but yeah, I went from "because there's no other way" to "because I'm starting to like it" 2024-12-23 15:59:12 Unfortunately this is about as good as it gets 2024-12-23 15:59:38 But I'd certainly rather write Forth than BASIC or pure assembly 2024-12-23 15:59:58 Beyond that it's more of a sentimental choice 2024-12-23 16:00:53 There are some who use it beyond that, for embedded work, or consulting etc 2024-12-23 16:21:45 pgimeno: yeah, it's easy enough to implement value and to in Forth-79 with does> but they aren't present natively 2024-12-23 16:22:05 only matters if you prefer that 2024-12-23 16:22:30 Open Firmware was an instance of Forth-as-portable-assembler-output 2024-12-23 16:37:37 Ultimately Forth is capable of being a surprisingly powerful programming environment for a small size, or an incredibly painful language purism exercise 2024-12-23 16:38:11 haha 2024-12-23 16:38:26 only rarely both at once 2024-12-23 16:38:50 It is entirely possible to torture yourself with Forth, but also to write things that do stuff 2024-12-23 16:39:05 And I think you've got to make a conscious decision to do things with it 2024-12-23 16:39:22 rather than just self-harm 2024-12-23 16:41:09 I didn't know about Open Firmware, nice 2024-12-23 16:46:59 hahaha 2024-12-23 16:56:56 I think the main attractions of Forth for me are that Forth is small and retro 2024-12-23 16:57:03 And more pleasant than BASIC 2024-12-23 16:59:22 Also having several public standards is useful, even if they are quite flawed 2024-12-23 17:00:25 the nice thing about standards is that there 2024-12-23 17:09:45 I keep trying to fall in love with old FORTRAN too, but it's difficult 2024-12-23 17:10:50 FORTRAN 2 was about the right level of complexity, ignoring lack of a standard I/O 2024-12-23 17:12:21 second system syndrome! no, wait 2024-12-23 17:19:16 If you removed the punch card massaging and added a concept of a standard I/O, maybe swapped arithmetic IF for statement IF, then you've got a nice static bootstrapping language 2024-12-23 17:19:33 called BASIC... the original BASIC was much like this I think(?) 2024-12-23 17:21:20 I'm trying to move the return stack to another location. Is it possible for the return stack to contain addresses pointing to the stack itself, that need relocation? and by possible I mean using normal words, without doing strange manipulations 2024-12-23 17:22:13 Not normally I don't think 2024-12-23 17:22:23 But obviously it's not impossible in general 2024-12-23 17:22:28 okay, good, thanks 2024-12-23 17:26:11 yeah I control the running program, so I know I'm not doing these kinds of weird things, I just wondered if there was something the system could be doing behind my back 2024-12-23 17:26:50 Obviously I can't rule that out, but normally I would guess not 2024-12-23 17:26:58 Especially not in a system that old 2024-12-23 17:27:18 Why are you moving it? 2024-12-23 17:28:12 I'm allocating free space, just a precaution against overwriting a memory area that is used for data 2024-12-23 17:29:03 in BASIC you did that with CLEAR ; I want to do the same thing in the JA 2024-12-23 17:30:55 pgimeno: a number of Forths do provide rp! and rp@ words which you can use to get pointers to the stack, but they aren't standard 2024-12-23 17:30:55 I don't know if the Jupiter's software did that 2024-12-23 17:31:18 yeah I can see why 2024-12-23 17:32:25 A lot of old Forths are very carefree about avoiding overlapping stuff 2024-12-23 17:32:57 the Juppy doesn't even implement the full "Required word set" from Forth-79 (I guess for lack of space in ROM) 2024-12-23 17:33:06 I think typically the end of the dictionary is the return stack (?) 2024-12-23 17:33:49 in the Jupiter the end of the dictionary is actually the data stack, and the machine stack is the return stack 2024-12-23 17:36:15 " 6. Ace FORTH lacks ', +!, -TRAILING, 79-STANDARD, >IN, ?, CMOVE, COMPILE, COUNT, DEPTH, EXPECT, FILL, KEY, MOVE, NOT, STATE, [COMPILE]. " 2024-12-23 17:36:15 Or rather I think often the terminal input buffer would be placed at the start of return stack area (the 'deepest' point) on the basis that you don't care about terminal input if you're in a deeply nested routine 2024-12-23 17:36:18 Some sort of fuzzy logic like that 2024-12-23 17:36:47 I don't blame them for leaving crap like 79-STANDARD out 2024-12-23 17:38:03 The rest of those are mostly easy to implement, some aren't though. I'm guessing they don't have STATE because : is a separate interpreter? 2024-12-23 17:38:54 no idea 2024-12-23 17:39:16 Is there an annotated disassembly for it somewhere? 2024-12-23 17:39:22 Or source even? 2024-12-23 17:39:22 yes 2024-12-23 17:39:25 Nice 2024-12-23 17:39:27 https://www.jupiter-ace.co.uk/romlisting.html 2024-12-23 17:39:30 That makes things easier 2024-12-23 19:12:20 Nah looks like they use a variable FLAGS to store STATE and a few other things 2024-12-23 19:12:31 Looks like it's really RAM-constrained, explains some of these choices 2024-12-23 19:13:31 3KB on the lower end models 2024-12-23 19:13:31 actually 1K; the other 2K are video RAM 2024-12-23 19:13:57 Well nobody's stopping you from doing your working-out in there :P 2024-12-23 19:15:07 but like with the ZX81, 16K was pretty standard, and in Mazogs the machine code alone is already almost 4K long 2024-12-23 19:15:39 but the 1KB base explains the choices made in the ROM 2024-12-23 19:15:56 The disassembly is nice 2024-12-23 19:16:42 This feels like a fig-Forth 2024-12-23 19:20:40 I think a token threaded forth would have been a good idea, for 1KB of normal RAM in the base model 2024-12-23 19:20:51 But fuck poor people, really 2024-12-23 19:27:06 Also might be older than the concept of token threading 2024-12-23 19:55:00 So pgimeno do you own one of these, do you have a particular reason for being interested in the Jupiter Ace? 2024-12-23 19:55:54 I don't, I own a clone that was developed by a friend and me. He does own one. The hardware fascinated me. 2024-12-23 19:56:34 https://codeberg.org/wilco2009/Mercury_Ace 2024-12-23 19:56:50 I'm assuming they're expensive as they seem quite rare 2024-12-23 19:57:02 that's the clone we developed, but he owns the real thing 2024-12-23 19:57:46 yes, I wish I could afford one, but there were just 3,000 units ever made before the company went bankrupt 2024-12-23 19:58:03 if you wanted to define a standard such that you wouldn't have to use an entire word of memory for state you could have defined a getter and a setter: compiling? and ->compiling 2024-12-23 19:58:38 the Jupiter Ace may be older than token-threaded Forths but it's younger than things like the UCSD P-system 2024-12-23 20:02:06 However old Forth is meant to be simple to the point of being stupid, and STATE fits that bill 2024-12-23 20:02:42 I am an old Forth enjoyer, personally 2024-12-23 20:04:23 Also old Forths were loaded into minicomputer RAM, so COMPILING? ->COMPILING would have actually used more RAM 2024-12-23 20:09:46 I think it would be fun to port some of the software available for the Jupiter Ace to gforth etc 2024-12-23 20:10:50 Saying that aloud, it feels like this is something that's already been done 2024-12-23 20:13:28 I doubt it 2024-12-23 20:14:24 I bet most software for the JA was games, which most likely means they used character redefinition, BEEP and other JA-exclusive things 2024-12-23 20:15:30 but of course, if there's any software that does not use any JA-specific features, then yes it would be nice to port 2024-12-23 20:15:33 yes, in RAM I agree 2024-12-23 20:39:35 There's a "Spreadsheet" program that has whet my appetite 2024-12-23 20:40:17 Believe it or not, gforth is capable of displaying custom character graphics 2024-12-23 20:40:55 oh cool 2024-12-23 20:41:16 Because I mean you can link to SDL and just draw arbitrary graphics 2024-12-23 20:41:52 And custom characters you can do blitting or as a texture map 2024-12-23 20:42:28 btw, I'm in Debian, what stock Forth is recommended? I see there is gforth, pforth and yforth 2024-12-23 20:42:49 There's no good answer, I use gforth in the mud like all the other plebs 2024-12-23 20:43:12 maybe I'm missing one, I checked with apt-cache search forth | grep -i forth 2024-12-23 20:43:35 gforth at least has newer standard of Forth, and the debian gforth lets you build the later gforth snapshots which are better 2024-12-23 20:43:47 You can't build a new gforth snapshot without 0.7.3 (in debian) installed 2024-12-23 20:43:51 Which is annoying 2024-12-23 20:44:24 The snapshot if you want to try building https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz 2024-12-23 20:44:37 But as I said you need gforth 0.7.3 installed to build it, as far as I can tell 2024-12-23 20:48:48 https://github.com/howerj/embed for something smaller and much less standard, or retroforth for something different, or ... 2024-12-23 20:55:17 veltas: so far I've been underwhelmed with GForth's FFI 2024-12-23 20:55:56 pgimeno: Debian yforth for me segfaults at startup. GForth and PForth seem okay 2024-12-23 20:56:32 segfaults? rude! 2024-12-23 20:56:45 I haven't tried PForth's FFI 2024-12-23 20:57:40 my first Forth (on Slackware, last millennium) was PFE. It's been updated since then (the original version of PFE requires hours of work to build on current Linux) 2024-12-23 20:57:51 current PFE builds and runs fine on Debian 2024-12-23 20:58:16 (it's in C) 2024-12-23 20:59:45 also if you like malleable stack languages, Debian has GhostScript, of course 2024-12-23 21:00:34 I don't think ATLAST, Factor, Joy, Cat, or Kitten is in Debian 2024-12-23 21:00:54 nor crc's RetroForth 2024-12-23 21:03:30 I kind of like kipple :) 2024-12-23 21:03:37 not familiar 2024-12-23 21:03:47 https://esolangs.org/wiki/Kipple 2024-12-23 21:04:49 it's not extremely useful, but it's funny 2024-12-23 21:37:37 xentrac: Really sorry to hear about that sir, I've opened case #82443 to track this support case regarding your satisfaction with the FFI 2024-12-23 21:38:01 Would you like a beverage or some snacks while you wait? 2024-12-23 21:45:04 haha 2024-12-23 21:45:22 I have a feeling I might be waiting a long time... 2024-12-23 22:05:06 Kipple is interesting