2024-08-31 00:03:02 is there another kind? 2024-08-31 00:05:10 The stack in forth is a bit like the registers on an old CPU with very few registers 2024-08-31 00:05:10 It's not meant to handle a lot of things 2024-08-31 00:05:39 i guess the only real kind are the ones actually in silicon and microcoded? 2024-08-31 00:05:49 and *not* microcoded 2024-08-31 00:06:37 even silicon is only simulating a virtual machine in terms of a three-dimensional field of voltages, current densities, and carrier densities 2024-08-31 00:07:55 veltas: yeah. but it *can* handle as many things as you want. that's the appeal of the Dark Side 2024-08-31 00:08:30 an old CPU with very few registers tends to be less confusing because things don't move from the T register to the X register spontaneously 2024-08-31 00:09:29 What I mean is we shouldn't treat the stack like variables, it's more like a small temporary area 2024-08-31 00:09:48 Even though, to facilitate program structure, it's secretly much larger than that 2024-08-31 00:11:39 yeah 2024-08-31 00:11:44 A good Forth program doesn't do a lot of stack manipulation: avoid it, factor it, refactor it, cop out and use variables 2024-08-31 00:11:55 I try to cop out early and often 2024-08-31 00:11:59 People are allergic to variables 2024-08-31 00:12:42 Even though classic forths are littered with helpful variables and words 2024-08-31 00:13:10 F83 has what seems to me to be a dismayingly small number of variables in it 2024-08-31 00:14:23 leading to definitions like : PLACE (S str-addr len to -- ) 3DUP 1+ SWAP MOVE C! DROP ; 2024-08-31 00:14:37 Is that real? 2024-08-31 00:14:39 yes 2024-08-31 00:15:07 and of course see can't see the stack comment or the spacing 2024-08-31 00:15:32 I eventually got the screen editor working well enough that I could say fix place and it would show me that definition in context 2024-08-31 00:15:37 Does F83 have LOCATE or similar? 2024-08-31 00:15:40 and a and it would show me the shadow screen 2024-08-31 00:15:53 what's LOCATE? 2024-08-31 00:16:17 Shows source code rather than SEE 2024-08-31 00:16:29 Which is a Forthy disassembler 2024-08-31 00:16:30 yeah, fix takes you to the source code in the screen editor 2024-08-31 00:16:35 Nice 2024-08-31 00:17:08 I was having a hard time getting it to work because the F83 I got from https://github.com/ForthHub/F83 was trying to find the block words on A: 2024-08-31 00:17:15 and I had the directory mounted on C: 2024-08-31 00:17:46 and error recovery is somewhat manual 2024-08-31 00:18:59 [bot]dpans: place 2024-08-31 00:19:07 [bot]dpans: help 2024-08-31 00:19:12 dpans: place 2024-08-31 00:19:12 <[bot]dpans > not found 2024-08-31 00:19:19 okay, I didn't think so 2024-08-31 00:19:51 place in F83 (and Gforth) converts a regular string into a counted string 2024-08-31 00:20:04 not sure how there's no standard word for doing this 2024-08-31 00:20:15 Oh right 2024-08-31 00:24:18 I'm also not sure how find got defined to take a counted string? at the time there wasn't even a c" (I had to write it the other night) 2024-08-31 00:24:42 That's ancient 2024-08-31 00:24:56 WORD produces a counted string, I would say that's related 2024-08-31 00:25:38 dpans: parser 2024-08-31 00:25:38 <[bot]dpans > not found 2024-08-31 00:25:40 dpans: parse 2024-08-31 00:25:40 <[bot]dpans > not found 2024-08-31 00:25:52 huh, parse wasn't standardized either? 2024-08-31 00:25:57 dpans: PARSE 2024-08-31 00:25:57 <[bot]dpans > not found 2024-08-31 00:26:06 PARSE is in ANS 2024-08-31 00:26:52 yup: https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/The-Input-Stream.html#index-parse-_0040var_007b-char-_0022ccc_003cchar_003e_0022-_002d_002d-c_002daddr-u---_007d--core_002dext-1557 2024-08-31 00:27:04 well, I guess that's referring to Forth 2012 now 2024-08-31 00:27:22 WORD can be defined so that the buffer it stores the counted string in lines up with where the next CREATE/: def name is stored 2024-08-31 00:27:47 So no transfer is necessary when making a def if BL WORD implements the parsing 2024-08-31 00:27:55 you could do that with parse too 2024-08-31 00:28:16 you'd just need an extra c! that word is doing 2024-08-31 00:28:16 No because the header/def would overwrite TIB 2024-08-31 00:28:28 PARSE returns the TIB directly 2024-08-31 00:28:34 oh, thanks 2024-08-31 00:28:41 I didn't realize 2024-08-31 00:28:53 So PARSE is faster than WORD most of the time 2024-08-31 00:29:57 But WORD is more convenient for stack manipulation, counted strings are useful 2024-08-31 00:30:45 And why they didn't do similar to strtok, probably because >IN backtracking was a thing even early on 2024-08-31 00:30:45 I'm just speculating 2024-08-31 00:30:47 Or maybe it didn't occur to them 2024-08-31 00:31:48 I mean Forth went through *many* iterations, an early improvement to Forth was the concept of compiled words 2024-08-31 00:33:00 Counted strings are just cruft, but it's cruft I enjoy 2024-08-31 00:34:25 you don't need to do the horrible thing strtok does because Forth didn't make C's design error with representing string lengths ;) 2024-08-31 00:40:27 Controversial statement 2024-08-31 00:44:54 maybe 30 years ago? I think it's pretty universally accepted now 2024-08-31 00:52:37 Among certified internet experts 2024-08-31 00:57:24 I think a big reason something like strtok didn't happen is it only makes sense for tokenising 2024-08-31 00:57:28 As the name implies 2024-08-31 00:57:41 And Forth doesn't 'do' tokens 2024-08-31 01:01:17 it's true; C is pretty oriented towards text, Unix having been funded originally as a word processor project 2024-08-31 01:01:52 and designed by professional writers 2024-08-31 01:22:49 is it worth buffering the top element of the return stack in a register 2024-08-31 01:27:35 Depends on arch 2024-08-31 01:27:38 Not on x86 2024-08-31 01:27:46 Warning: opinion inside 2024-08-31 01:27:57 i was thinking about doing it to make do loop faster 2024-08-31 01:28:16 Do what you want 2024-08-31 01:28:25 The issue is you add extra handling/complexity everywhere else 2024-08-31 01:28:25 but it's gonna add an extra instruction into every call/return 2024-08-31 01:28:38 It's absolutely worth it for parameter stack though, on almost all platforms 2024-08-31 01:28:47 yeah i'm buffering TOS in ebx 2024-08-31 01:29:01 Exactly amby, this is the problem (extra ins for every call/ret) 2024-08-31 01:29:07 so that i can still use lodsl in NEXT and LIT 2024-08-31 01:29:25 Also in code return stack isn't something you can use directly anyway 2024-08-31 01:29:35 Whereas parameter stack is impacted directly by most words 2024-08-31 01:32:00 For instance in zenv, a Z80 Forth, using TOS register for data stack actually makes the definitions smaller and faster 2024-08-31 01:32:25 I use HL as TOS, the most important 16-bit register pair, and it is absolutely worth it 2024-08-31 01:32:26 you save a memory access on most words 2024-08-31 01:33:07 my WIP avr forth uses 24-25 as TOS 2024-08-31 01:33:24 specifically because you can use ADIW and SBIW on those 2024-08-31 01:33:27 If you're thinking about it in those terms you should generate with register selection 2024-08-31 01:33:41 And then you've made it too complicated and should just use LLVM or GCC 2024-08-31 01:34:03 huh? 2024-08-31 01:34:04 terms of saving memory access 2024-08-31 01:34:37 The actual *feature* of Forth, a thing that it's actually good at, is saving space 2024-08-31 01:34:59 Forth is *not* performant, C is a good 10x improvement or more most of the time 2024-08-31 01:35:26 It is still a damn sight faster than a lot of things, like Python, old BASIC's etc 2024-08-31 01:35:45 but if i can make it faster i may as well 2024-08-31 01:36:05 Small and simple 2024-08-31 01:37:41 I'm just saying the reason I use TOS is for simplicity and size of code, the lesser reason is performance 2024-08-31 01:41:39 everyone wants performance in secret 2024-08-31 01:44:42 I want it openly, I just don't have a good solution for it, and it gets super complex super quickly 2024-08-31 01:46:57 I am interested in things like how we might effectively and simply integrate vector acceleration into Forth code 2024-08-31 01:51:26 I think this covers most of the higher performance concerns if you can get it right 2024-08-31 01:52:10 Forth *can* be performant, though not on an 8-bit CPU 2024-08-31 01:52:18 I try to not care about performance as much as possible, except for things that are just wrong, like for example iterating a list twice when you could do it once 2024-08-31 01:52:32 on a stack machine, forth can be pretty performant 2024-08-31 01:52:53 vms14: Using a linked list for dictionary lookup is "just wrong", more so than iterating twice 2024-08-31 01:53:07 But I do it anyway, because it doesn't matter 2024-08-31 01:53:09 dictionary lookup doesn't need to be fast 2024-08-31 01:53:53 xentrac: Forth is a great fit for 8-bit cpu's, though 2024-08-31 01:53:53 I mean in general call/return is faster in a native-code Forth than in C 2024-08-31 01:54:00 yes, I agree, it is 2024-08-31 01:54:25 there is always a tradeoff 2024-08-31 01:54:38 but usually you can write C code for 8-bit CPUs that is faster than Forth code, because Forth really wants your arithmetic to be done on pointer-sized things 2024-08-31 01:54:53 "than in C" you mean than in a C-implemented Forth? 2024-08-31 01:54:53 in my case instead of a linked list I have hash tables with a parent slot 2024-08-31 01:54:59 no, I mean than in C 2024-08-31 01:55:08 without any Forth 2024-08-31 01:55:11 Oh because of ABI alignment etc? 2024-08-31 01:55:33 it might be even worse than a linked list, but gives me lexical scope 2024-08-31 01:55:33 not alignment so much as parameter copying 2024-08-31 01:55:52 Yes but the parameter stack, see.... 2024-08-31 01:55:55 right 2024-08-31 01:56:15 Also that parameter copying's not happening on good ABI's / functions 2024-08-31 01:56:22 it usually has to in C 2024-08-31 01:56:45 i'm fairly sure all the 64 bit calling conventions pass in registers 2024-08-31 01:56:59 when they can, yeah 2024-08-31 01:57:13 Which is most small 'leaf' functions we'd compare with simple Forth code 2024-08-31 01:57:15 and that often reduces that cost 2024-08-31 01:57:22 thinking in performance will always limit you 2024-08-31 01:57:25 but they don't return structs in registers, for example 2024-08-31 01:57:40 im fairly sure they do 2024-08-31 01:57:47 If they're small enough they do 2024-08-31 01:57:48 but it's something hard to avoid in the end 2024-08-31 01:58:12 to godbolt! 2024-08-31 01:58:16 C ABI for AMD64 is quite good 2024-08-31 01:58:47 Or just objdump 2024-08-31 01:59:07 Whereas PPC64 ABI's are bad 2024-08-31 01:59:13 yeah, I was surprised to find out the other day that the C ABI for AMD64 returns struct {void *x[3];} in memory 2024-08-31 01:59:20 amby don't take the motorbike this time 2024-08-31 01:59:28 you will end dying in front of us 2024-08-31 01:59:35 it passes in a pointer to the return value location in `rdi` 2024-08-31 01:59:47 It's 3 64-bit values 2024-08-31 01:59:50 yeah 2024-08-31 01:59:58 I was expecting it to use three registers, but no, three is too big 2024-08-31 02:00:11 Yeah there's only two regs defined for returning 2024-08-31 02:00:18 I guess that's a bit of a weakness 2024-08-31 02:00:23 this was for http://canonical.org/~kragen/sw/dev3/sumnums.c 2024-08-31 02:00:32 Better than 32-bit x86 situation 2024-08-31 02:00:36 yes, much 2024-08-31 02:00:54 but I agree, the C AMD64 ABI is very nice 2024-08-31 02:01:12 I am someone who has a habit of objdumping simpler C code to tune for register usage etc 2024-08-31 02:01:35 I've done that sometimes but I hadn't done it enough to see how struct return worked 2024-08-31 02:01:53 it wasn't until I had to implement it in assembly that I saw 2024-08-31 02:01:54 there's a reason that riscs typically have a million billion registers 2024-08-31 02:01:57 then I was dismayed 2024-08-31 02:02:08 (normally 32 but a million billion is close enough right) 2024-08-31 02:02:19 And riscs tend to have 1-2 return regs 2024-08-31 02:02:23 So same problem 2024-08-31 02:02:31 SPARC has 8 ;) 2024-08-31 02:02:33 AMD64's got a good few 2024-08-31 02:02:46 now sparc does have a million billion registers 2024-08-31 02:02:55 good few registers I mean, not return registers 2024-08-31 02:03:06 amd64 has 16 "gprs" 2024-08-31 02:03:06 xentrac: SPARC has 8 regs or 8 return regs? 2024-08-31 02:03:17 several of which aren't actually general purpose 2024-08-31 02:03:31 The encoding is quite different for some 2024-08-31 02:03:36 veltas: sparc has 32 registers visible at any given time 2024-08-31 02:03:41 anyway, a good Forth compiler can in theory generate code that's within ε of C compiler output, and I've heard that MPE Forth actually does this 2024-08-31 02:04:06 8 are globals, 8 are shared with the caller, 8 are locals (only visible to current function), 8 are shared with the callee 2024-08-31 02:04:14 xentrac: hard mode, using standard forth code 2024-08-31 02:04:33 Because a lot of these performance comparisons cheat, e.g. use local vars and do register selection on them 2024-08-31 02:04:36 yeah, using standard Forth code, though of course there are pathological cases that you can't solve 2024-08-31 02:04:45 Not really Forth then, it's just C-without-infix 2024-08-31 02:05:02 but (unless you're on SPARC!) call and return operations are cheaper for the Forth compiler 2024-08-31 02:05:24 i mean register windowing doesn't actually make calling cheaper 2024-08-31 02:05:29 it kinda does and kinda doesnt 2024-08-31 02:05:34 xentrac: Yes but C and Forth compilers inline 2024-08-31 02:05:41 because if you call too deep you need to shunt stuff to memory regardless 2024-08-31 02:05:47 agreed 2024-08-31 02:06:02 We don't care about CALL/RET performance, that's not the bottleneck usually 2024-08-31 02:06:08 register windowing does make Forth calling more expensive though 2024-08-31 02:07:02 you do tend to have to inline quite a bit to get decent performance on recent processors 2024-08-31 02:07:13 In Forth especially 2024-08-31 02:07:15 Where + is a word 2024-08-31 02:07:23 heh, yes 2024-08-31 02:08:01 i wish stack machines were still a thing people made 2024-08-31 02:08:11 how's your Verilog? 2024-08-31 02:08:20 i have been designing a stack machine actually 2024-08-31 02:08:34 cool! 2024-08-31 02:08:36 A pragmatic Forth approach I think is to provide tools to let you manually optimise when you need to 2024-08-31 02:08:58 or more specifically a weird register machine that will work as a microcode core for a stack machine 2024-08-31 02:09:20 yeah, I think using Forth as a scripting shell over assembly-language programs is a pretty flexible approach 2024-08-31 02:09:32 Not just assembly 2024-08-31 02:09:36 my dad was telling me the other night about a project he did on an 8051 in the 80s 2024-08-31 02:09:50 the 8051 came with BASIC in the ROM 2024-08-31 02:09:52 guess how many instructions it has 2024-08-31 02:09:57 given that the opcode is 8 bits 2024-08-31 02:10:21 "so you wrote the application in BASIC?" "No, in assembly, but I called the BASIC interpreter's floating-point routines" 2024-08-31 02:10:23 For example [ ] LITERAL lets you do constant-folding manually, if you want 2024-08-31 02:10:36 I considered doing that in zenv 2024-08-31 02:10:40 veltas: i defined `],` to be equivalent to `] LITERAL` 2024-08-31 02:10:43 because i do it so often 2024-08-31 02:10:44 Decided fixed point is goodnuf 2024-08-31 02:10:50 amby: Noice 2024-08-31 02:11:11 so u1 has 4 instructions 2024-08-31 02:11:14 yeah, in general I think Forth's compile-time facilities are a notable strength 2024-08-31 02:11:16 move, jump, load, store 2024-08-31 02:11:38 all arithmetic is done with move 2024-08-31 02:11:53 but the compiler semantics are pretty janky, which makes it less of a strength than it could be; that's why cmForth and Pygmy Forth abandoned the idea of "immediate words" 2024-08-31 02:12:03 and Gforth has generalized them 2024-08-31 02:12:17 I think gforth's approach is a misstep 2024-08-31 02:12:46 I'm not sure if it is or not, but I'm sure the standard approach is :) 2024-08-31 02:12:58 Obsession with making words have some sort of strict semantic meaning and smartness, instead of just handing the revolver to the teenager and telling him where to point it 2024-08-31 02:13:07 i like immediate words 2024-08-31 02:13:28 IMMEDIATE is the right approach, the standard and gforth are trying to be smart 2024-08-31 02:13:29 i think forth works best when you're slinging numbers around, rather than trying to make it something with a formal high level spec and behaviour 2024-08-31 02:13:41 well, I want to be able to extend the language easily 2024-08-31 02:14:05 "there is a profound philosophical truth concealed in how much we can accomplish by moving numbers around" 2024-08-31 02:14:06 and state is a big stumbling block 2024-08-31 02:14:15 It's easier to play with the language when the language is a dumb simple program, in my opinion 2024-08-31 02:14:29 I was thinking the other night about how to add, for example, a new kind of variable 2024-08-31 02:16:34 something like : my create 0 , does> @ ; : & ' >body state @ if literal then ; immediate : =: ' & >body state @ if literal postpone ! else ! then ; 2024-08-31 02:16:56 i still havent got my head around does> 2024-08-31 02:18:17 I guess I want postpone literal in those two places 2024-08-31 02:18:21 Yeah 2024-08-31 02:18:26 But I understood the code 2024-08-31 02:18:42 but anyway the idea is that by default you want to read variables normally 2024-08-31 02:19:12 oh i see so 2024-08-31 02:19:16 I FILL CELLS WITHIN HERE 2024-08-31 02:19:21 create makes the word 2024-08-31 02:19:28 0 , is the default value 2024-08-31 02:19:36 yes, exactly 2024-08-31 02:19:44 and then does> @ makes it so that then the word runs, it fetches the value 2024-08-31 02:19:48 right 2024-08-31 02:19:54 rather than calling into it 2024-08-31 02:20:00 And now you understand does> 2024-08-31 02:20:03 or just pushing its address 2024-08-31 02:20:05 that seems like. an interesting way of doing it 2024-08-31 02:20:32 particularly because create works differently in jonesforth 2024-08-31 02:20:52 but I don't like the idea that I can't postpone these words in a sensible way 2024-08-31 02:21:21 well my is logically the same as constant 2024-08-31 02:21:25 yes 2024-08-31 02:21:47 but the standard doesn't specify how constant is defined, so & and =: aren't guaranteed to work with it 2024-08-31 02:22:05 this is why i don't read the standard 2024-08-31 02:22:14 The standard is not ideal 2024-08-31 02:22:26 in jonesforth, `10 CONSTANT TEN` is identical to `: TEN 10 ;` 2024-08-31 02:22:37 it can be useful to write portable code sometimes 2024-08-31 02:22:59 right, so that definition of =: won't work with Jonesforth constant 2024-08-31 02:23:27 and in the forth that i'm writing, you have DOCON 2024-08-31 02:23:56 (I mean, as written, it won't work with anything, but the definition of =: that I was *trying* to write) 2024-08-31 02:24:30 so you'd go `WORD CREATE DOCON , ,` 2024-08-31 02:24:37 what does postpone do 2024-08-31 02:24:48 because it seems kinda similar to jonesforths `[COMPILE]` 2024-08-31 02:24:49 dpans: postpone 2024-08-31 02:24:49 <[bot]dpans > not found 2024-08-31 02:24:51 but clearly isn't 2024-08-31 02:25:03 yes, postpone is [compile] and compile 2024-08-31 02:25:04 because `[COMPILE] !` is identical to just `!` 2024-08-31 02:25:58 there's an explanation at https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Macros.html 2024-08-31 02:26:14 which I'm referring you to not because I don't want to answer your question 2024-08-31 02:26:26 but because my understanding of the situation is very poor and I don't want to mislead you 2024-08-31 02:26:44 POSTPONE is trying to be too smart really 2024-08-31 02:26:59 so `postpone foo` is equivalent to `' foo ,` 2024-08-31 02:27:05 iff foo is not immediate 2024-08-31 02:27:07 ? 2024-08-31 02:28:21 well, , and compile, are identical in Jonesforth but very different in things like subroutine-threaded Forths and even Gforth 2024-08-31 02:29:42 I *think* postpone foo is equivalent to ' foo compile, for a normal non-immediate word 2024-08-31 02:29:54 it is 2024-08-31 02:30:41 judging by that link 2024-08-31 02:30:41 e.g. POSTPONE IF is [COMPILE] IF and POSTPONE + is ['] + COMPILE, 2024-08-31 02:30:44 The point is POSTPONE x means "compile x when this executes" 2024-08-31 02:31:08 right. as I understand it, the reason for postpone is that earlier Forth standards like Forth-83 had to nail down specifically which words were immediate and which weren't so that you would know whether to use compile or [compile] 2024-08-31 02:31:30 And that was a source of language-envy for some people 2024-08-31 02:31:47 it also made the standard unnecessarily restrictive 2024-08-31 02:32:14 How? 2024-08-31 02:32:39 The issue is the restrictiveness, which I don't doubt exists, is a result of our simplistic programming language 2024-08-31 02:32:52 And in order to work around it they made it more complicated 2024-08-31 02:33:08 the beauty of forth is that if you want a feature you can just add it 2024-08-31 02:33:12 and you should 2024-08-31 02:33:21 The beauty of most forths 2024-08-31 02:33:49 I think specifically there were words that were not immediate that one or another implementation wanted to make immediate 2024-08-31 02:33:56 like, maybe + is a good example 2024-08-31 02:33:57 It's like how LEAVE in fig forth would set I to I' , but not jump out the loop 2024-08-31 02:34:16 after a while of using it, you should end up with your own weird homebrew extensions that make sense for your particular problems and programming style 2024-08-31 02:34:29 like how i have `#` and `[[ ]]` 2024-08-31 02:34:50 xentrac: R@ is a good example 2024-08-31 02:34:57 oh? 2024-08-31 02:35:16 Well really >R and R> 2024-08-31 02:35:27 how so? 2024-08-31 02:35:39 dpans: parse 2024-08-31 02:35:39 <[bot]dpans > 6.2.2008 PARSE CORE EXT 2024-08-31 02:35:39 <[bot]dpans > ( char "ccc" -- c-addr u ) 2024-08-31 02:35:40 <[bot]dpans > Parse ccc delimited by the delimiter char. 2024-08-31 02:35:40 <[bot]dpans > c-addr is the address (within the input buffer) and u is the length of 2024-08-31 02:35:40 <[bot]dpans > see http://forth.works/dpans/6_2_2008.txt for full description 2024-08-31 02:35:52 dpans: [compile] 2024-08-31 02:35:52 <[bot]dpans > 6.2.2530 [COMPILE] "bracket-compile" CORE EXT 2024-08-31 02:35:52 <[bot]dpans > Interpretation: Interpretation semantics for this word are undefined. 2024-08-31 02:35:52 <[bot]dpans > Compilation: ( "name" -- ) 2024-08-31 02:35:53 <[bot]dpans > Skip leading space delimiters. Parse name delimited by a space. Find 2024-08-31 02:35:53 <[bot]dpans > see http://forth.works/dpans/6_2_2530.txt for full description 2024-08-31 02:36:20 Because you can't execute >R and R> at the interpreter normally, so forths would be within their rights to make them IMMEDIATE 2024-08-31 02:36:20 dpans: postpone 2024-08-31 02:36:20 <[bot]dpans > 6.1.2033 POSTPONE CORE 2024-08-31 02:36:21 <[bot]dpans > Interpretation: Interpretation semantics for this word are undefined. 2024-08-31 02:36:21 <[bot]dpans > Compilation: ( "name" -- ) 2024-08-31 02:36:21 <[bot]dpans > Skip leading space delimiters. Parse name delimited by a space. Find 2024-08-31 02:36:21 <[bot]dpans > see http://forth.works/dpans/6_1_2033.txt for full description 2024-08-31 02:36:30 thanks crc! 2024-08-31 02:36:51 No problem, sorry I missed this earlier 2024-08-31 02:37:12 veltas: what's the incentive? I was thinking that for + there were a variety of possible optimizations you might want to use 2024-08-31 02:37:41 C's errno is maybe another example, but in Forth it would be a user variable rather than a macro 2024-08-31 02:38:00 In a STC you might want : >R (compile ret stack push) ; IMMEDIATE 2024-08-31 02:38:02 errno is honestly pretty silly 2024-08-31 02:38:09 To make >R inlined 2024-08-31 02:38:25 especially when returning multiple variables is trivial in forth 2024-08-31 02:38:31 *multiple values 2024-08-31 02:38:41 yeah, but I think subroutine threading isn't normally implemented by making all the primitives immediate 2024-08-31 02:39:04 if i was doing STC i'd have an `inline` bit in the header 2024-08-31 02:39:28 You can't inline >R 2024-08-31 02:39:58 i dont see why not 2024-08-31 02:40:05 Because I said so 2024-08-31 02:40:09 I'm the king 2024-08-31 02:40:11 understandable 2024-08-31 02:40:24 sure you can, it might be something like push rbx; mov rbx, [rsi]; lea rsi, [rsi-8] 2024-08-31 02:40:44 i mean in u1, >R is something like 2024-08-31 02:40:53 S XH R 2024-08-31 02:40:57 S X R 2024-08-31 02:40:57 xentrac: talking about STC 2024-08-31 02:41:04 oops, that's R> 2024-08-31 02:41:06 L D X 2024-08-31 02:41:09 L D XH 2024-08-31 02:41:41 and then in the stack machine built on top of it, >R is [whatever number >R gets given] 2024-08-31 02:41:50 If you remove the RET then your return stack is in a different state at end of inlined code 2024-08-31 02:41:53 veltas: yeah, I guess with STC you'd want to use rsp for the return stack 2024-08-31 02:42:06 So >R and immediate >R are different 2024-08-31 02:42:10 yeah, you can't simply inline the assembly code 2024-08-31 02:42:29 And the distinction is pointless because >R can't be executed at interpreter anyway 2024-08-31 02:42:42 Unless you go out of your way to do weird and wonderful things with the interpreter 2024-08-31 02:42:53 I struggled with this a lot the other night when I had to implement 2r> 2024-08-31 02:43:07 my first attempt was the obviously stupid : 2r> r> r> ; 2024-08-31 02:43:18 or maybe : 2r> swap r> r> ; 2024-08-31 02:43:32 well if you can't execute >R at the prompt then yes you can inline it 2024-08-31 02:43:37 uh, that's even worse. I mean : 2r> r> r> swap ; 2024-08-31 02:43:38 because you'll only ever inline it 2024-08-31 02:44:19 Yeah I was going to say, I would have just done : 2r> postpone r> postpone r> postpone swap ; immediate 2024-08-31 02:44:24 haha 2024-08-31 02:44:37 yes, exactly! 2024-08-31 02:44:41 which brings us to the point about postpone 2024-08-31 02:44:41 `: 2R> [[ R> R> SWAP ]] ; 2024-08-31 02:44:49 The main thing I'd change with your code would be packing all three states in one cell 2024-08-31 02:45:04 For hanoi 2024-08-31 02:45:24 hm 2024-08-31 02:45:42 i could have a funny interpreter for u1 forth 2024-08-31 02:45:49 I don't like POSTPONE[ and equivalents because it makes it too easy to inline 2024-08-31 02:45:52 DOINSTR 2024-08-31 02:45:54 or something 2024-08-31 02:46:02 if you write a new 2r> that is immediate, then existing words that compile 2r> will fail, as I understand it 2024-08-31 02:46:06 for builtins 2024-08-31 02:46:13 whereas if they're written in terms of postpone they will work 2024-08-31 02:46:38 Is this hypothetical possible? 2024-08-31 02:46:43 if i write a new 2R> then anything ive written before that (ie. before it in the file) will still work 2024-08-31 02:46:46 I think so, yes 2024-08-31 02:46:52 anything i write after it will respect the new behaviour 2024-08-31 02:46:55 When would you postpone 2r> ? 2024-08-31 02:47:03 I guess implementing 4r> 2024-08-31 02:47:14 or rswap 2024-08-31 02:47:22 It's possible but not as likely as some would have you believe 2024-08-31 02:47:23 i'd just write rswap in asm tbh 2024-08-31 02:47:44 packing all three states in one cell is a very reasonable thing to do 2024-08-31 02:47:59 At least POSTPONE , for all its issues, isn't "state-smart" 2024-08-31 02:48:19 but my objective with the hanoi code was sort of to see if let! made it possible to write straightforward, stupid recursive code and have it work 2024-08-31 02:48:25 That's where the real trouble starts, with S" et al 2024-08-31 02:48:34 which it sort of does 2024-08-31 02:48:48 It's a good feature xentrac 2024-08-31 02:49:04 i mean if i was having trouble with S" being state smart 2024-08-31 02:49:08 it's too slow and uses too much return stack 2024-08-31 02:49:13 i'd split it into S" and (S") 2024-08-31 02:49:28 S" is the convenience function for when you're writing "normal" code 2024-08-31 02:49:31 as normal as forth can be 2024-08-31 02:49:35 but for some purposes that doesn't matter 2024-08-31 02:49:36 I would need something like CHAR " PARSE 2024-08-31 02:49:42 But where would I get something like that 2024-08-31 02:49:50 Oh wait, right in the standard 2024-08-31 02:50:21 (S") is non-immediate and when executed just dumps chars at HERE 2024-08-31 02:50:31 when I added c" to F83 the other day I made it out of pieces of " 2024-08-31 02:50:59 so S" checks state and frobs the return value of (S") accordingly 2024-08-31 02:51:08 F83 gives your (S") the name ," 2024-08-31 02:51:33 but its "" and ." have to compile something before it 2024-08-31 02:52:02 otherwise the inner interpreter will run into the text string and start trying to interpret it as execution tokens 2024-08-31 02:52:03 S" at the prompt is the same as (S") 2024-08-31 02:52:18 S" in a definition is uhhhh 2024-08-31 02:52:48 ' LITSTRING , 0 , (S") ( fix up litstring offset ) 2024-08-31 02:52:57 yeah, basically 2024-08-31 02:53:11 except F83's ," stores the offset too. with place 2024-08-31 02:53:12 which means S" is state smart but (S") isn't 2024-08-31 02:53:42 But then S" the main one breaks if you POSTPONE it, depending on STATE at execution time 2024-08-31 02:53:47 F83's s" (spelled ") isn't state-smart, it just doesn't work in interpret state 2024-08-31 02:53:51 yeah so don't postpone S" 2024-08-31 02:54:19 SLITERALly no altneratives tho 2024-08-31 02:54:41 Okay I'm going to bed, nighty night 2024-08-31 02:57:55 goodnight 2024-08-31 02:58:30 dpans: s" 2024-08-31 02:58:30 <[bot]dpans > 6.1.2165 S" "s-quote" CORE 2024-08-31 02:58:30 <[bot]dpans > Interpretation: Interpretation semantics for this word are undefined. 2024-08-31 02:58:31 <[bot]dpans > 58 2024-08-31 02:58:31 <[bot]dpans > see http://forth.works/dpans/6_1_2165.txt for full description 2024-08-31 02:58:51 because 'Interpretation semantics for this word are undefined.' it doesn't have to be state-smart 2024-08-31 03:02:41 dpans: smudge 2024-08-31 03:02:41 <[bot]dpans > not found 2024-08-31 03:02:45 dpans: reveal 2024-08-31 03:02:46 <[bot]dpans > not found 2024-08-31 03:02:52 dpans: s" 2024-08-31 03:02:52 <[bot]dpans > 6.1.2165 S" "s-quote" CORE 2024-08-31 03:02:53 <[bot]dpans > Interpretation: Interpretation semantics for this word are undefined. 2024-08-31 03:02:53 <[bot]dpans > 58 2024-08-31 03:02:54 <[bot]dpans > see http://forth.works/dpans/6_1_2165.txt for full description 2024-08-31 03:02:58 I liked it more when it spammed 2024-08-31 03:03:13 I think it could reformat things a bit more productively 2024-08-31 03:03:16 it should be noted that in ANS, 11.6.1.2165 adds interpretation semantics to S" 2024-08-31 03:03:33