2024-10-05 02:48:37 I wonder if anyone has thought about peephole optimizing forth code to convert it to assembly 2024-10-05 02:49:20 since you wouldn't get as much impact as full optimization but maybe the you can get a lot of the benefit for a lot less work 2024-10-05 02:50:54 and at least cut down on stack thrashing by spotting common 2-3 word combinations and replacing those with custom assembly 2024-10-05 02:51:20 yeah, I definitely did that in StoneKnifeForth 2024-10-05 02:54:44 MrMobius: I guess that would have the most potential in a code/subroutine threaded system with inlining? 2024-10-05 02:56:25 ya good if youre outputting machine code but could work for threaded code too if you code fused primitives or have an efficient way to generate them 2024-10-05 02:58:06 HP calculators do an interesting thing where they reuse code snippets that conveniently exist elsewhere in the ROM so you see calls to things like SWAPDUP1+ROTDROP 2024-10-05 02:58:31 since that's followed by a return 2024-10-05 03:05:50 yeah, nowadays that's called "ROP gadgets" 2024-10-05 14:14:11 I've never played with such ideas, since theyr'e a mite harder to integrate into indirect threaded systems (like you noted, you'd need to be able to auto-gen primitives). But this next one will be code threaded on a virtual machine layer, so it'll be quite easy to try such things out. 2024-10-05 16:47:17 sometimes i question whether variable should be a word at all 2024-10-05 16:47:57 create foo 0 , is the same thing, but with explicit initialization 2024-10-05 16:48:30 that's a crash waiting to happen on my forth 2024-10-05 16:48:45 your variables work differently? 2024-10-05 16:49:04 `S" FOO" CREATE DOVAR , 0 ,` is the same as `VARIABLE FOO` 2024-10-05 16:49:18 (ignoring the issue with CREATE overwriting the string) 2024-10-05 16:49:40 then i suggest you don't do this in your forth 2024-10-05 17:07:53 the Forth 2012 standard permits variable to put its variables somewhere else than where create does 2024-10-05 17:08:04 but it's an unusual thing to do 2024-10-05 17:09:28 the way i understand it, a word created with VARIABLE returns the address of the variable when executed 2024-10-05 17:09:31 but yeah, create foo 0 , gives you a foo that will work wherever you can use a variable foo — in standard Forths 2024-10-05 17:10:54 myself, I generally prefer using value and to because I fetch variables far more often than I store into them 2024-10-05 17:10:54 and value also has the virtue of explicitly initializing it 2024-10-05 17:11:30 really I think if you didn't have to worry about backward combatibility you'd do well to eliminate both variable and constant in favor of value 2024-10-05 17:12:37 though I'd prefer my and =: as spellings of value and to 2024-10-05 17:22:26 xentrac: how would i pass a value by reference? 2024-10-05 17:22:48 i don't like that to has to take something from the input stream 2024-10-05 17:36:11 use create 2024-10-05 17:37:03 or you could add a word like & that returns the dfa of the value 2024-10-05 17:37:45 I mean that's probably a factor of to anyway, right? 2024-10-05 18:37:01 i suppose 2024-10-05 18:42:11 xentrac: I wouldn't want to actually give up variable, because it's not ALWAYS the case that one fetches far more often than storing. I see variable as the "fundamental thing," and then if you want to build on it great. 2024-10-05 18:42:47 I have nothing against value/to, but I don't think it should *replace* variable. It could certainly replace constant, though. 2024-10-05 18:43:15 I don't think I've ever seen a codebase that contained more writes to variables than reads 2024-10-05 18:43:39 Well, I don't mean "more" - I just mean that writes can be significant as well. 2024-10-05 18:44:15 But really it's just that variable is more "fundamental" to what computers do - you manipulate memory locations. I think Forth should always expose the most fundamental capabilities. 2024-10-05 18:44:28 that's what create is for 2024-10-05 18:44:30 except in assembly, in the majority of cases if you only read something in one place you don't store it in a variable, you just leave it on the stack or as a temporary result of an inline expression 2024-10-05 18:44:37 It's like keeping block stuff even if you have a file system. It's all BUILT on block. 2024-10-05 18:44:59 Well, sure - variable is just shorthand for create cell allot. 2024-10-05 18:45:07 not in the Forth 2012 standard, but sure 2024-10-05 18:45:13 you can implement it that way 2024-10-05 18:45:31 Sounds like I might not like that standard. 2024-10-05 18:45:54 well, it's intended to allow you to allocate your variables somewhere else than your created arrays and whatnot 2024-10-05 18:46:04 I have a strong love for "simplicity," and want my Forths to stick close to that. 2024-10-05 18:46:05 which could be a reasonable tradeoff under some circumstances 2024-10-05 18:46:41 if you write to a variable in two places and read it in one, then you probably have convergent control flow (otherwise you can remove the earlier write safely) 2024-10-05 18:47:24 if that convergent control flow is an if else then, you will usually be better off leaving the result on the stack and writing it to the variable after the conditional 2024-10-05 18:48:00 if it's a loop of some kind, where you're initializing a variable before the beginning of the loop and then updating it inside the loop, in the vast majority of cases you're also reading it in order to update it 2024-10-05 18:48:40 in which case you only have two write-sites and one read-site if you don't use the variable except to update it; in which case, why do you have it at all? 2024-10-05 18:50:53 you have to get into cases like three write-sites and two read-sites for a variable before you start running into cases where good code writes to a variable in more places than it reads it 2024-10-05 18:50:53 and those are rare enough that they never dominate 2024-10-05 18:52:40 so I think that in almost all cases if you replace variable foo with 0 value foo, foo @ with just foo, and foo ! with to foo, you improve the program. It forces you to initialize the variable (which I regard as a benefit), shortens the code, and potentially makes it easier for a compiler to optimize. 2024-10-05 18:54:24 The drawbacks are: the standard fucked up the definition of to with respect to 2value, value is still too long of a name, to is still longer than !, there isn't any standard way to get the address of a value, and it doesn't actually simplify the implementation to support *both* value and variable, as you have to do if you want to run any standard Forth program 2024-10-05 18:55:25 also clearly {value to @ !} is a larger set than {variable @ !} and you can't eliminate @ and ! in any case 2024-10-05 18:55:35 Variable is closer to what the hardware does - that's really my bottom line. If I only get one of them, then it will always be variable. 2024-10-05 18:55:50 And if I want value/to it's easy to write. 2024-10-05 18:56:09 The best of both words would be valuable. :) 2024-10-05 18:56:11 what's close to what the hardware does is create, though 2024-10-05 18:56:19 And I'm never interested in running "any standard Forth." I just want MY Forth programs, written for that system, to run. 2024-10-05 18:57:00 ?branch is also closer to what the hardware does than if or loop 2024-10-05 18:57:12 What I mean is that what you do in assembly is store to addresses and fetch from addresses. It's the only way you access memory. And that's what a variable puts in your hands. 2024-10-05 18:58:06 "Data" doesn't really exist in its own right at the hardware/assembly level. It's the addresses that are primary, and then you do operations on them to store and get your data. 2024-10-05 18:58:12 that's what create puts in your hands 2024-10-05 18:58:15 more generally, assembly is closer to what the hardware does than Forth is 2024-10-05 18:58:27 Whatever - that's splitting hairs from where I sit. 2024-10-05 18:58:43 create is more about configuring your dictionary than about actually operating on anything. 2024-10-05 18:59:06 My point is that fundamentally we should think in terms of ADDRESSES. 2024-10-05 18:59:16 Because that's what RAM is - an array of address locations. 2024-10-05 18:59:22 well, a created word (without does>) puts a data-space address on the stack 2024-10-05 18:59:59 Splitting hairs. It's the general notion of address vs. content that I'm emphasizing. I don't care whether you want to attach that idea to variable or to create - six of one half dozen of the other. 2024-10-05 19:00:28 I've no interest in arguing that aspect of the issue. 2024-10-05 19:01:31 well, I'm not proposing to abolish create, which is essential for any kind of structured or compound data. What I'm proposing is to eliminate variable. If create vs. variable is "six of one, half a dozen of the other" to you, and you're seeking simplicity, you should prefer just having create over having both create and variable 2024-10-05 19:02:31 I feel no strong necessity to have variable be built in. That's also easy to write if you want it. I generally include it (and don't include value), but if you really want to strip your system down and offer ony create, fine - I wouldn't argue with that. 2024-10-05 19:02:41 But one of the first things I'd probably do would be to write variable. 2024-10-05 19:02:51 Except I'd call it var. 2024-10-05 19:03:10 KipIngram: "terms of ADDRESSES" -- one of the things I was hoping for my C forth to have in source was some sort of orthogonality (I'm not certain that's the right word) between the C source and the forth runtime. What I did was declare variable as single-element arrays, say 'int example[1];'. Mentally, I thought about it as 'forth is always at the address level'. 2024-10-05 19:03:10 Those extra five characters are just wasteful. 2024-10-05 19:03:38 I don't think that's an unreasonable choice; I just think we can do a little better by using value (with a shorter name) instead 2024-10-05 19:03:45 Not wasteful of disk space or RAM - wasteful of spaces on your source code line. 2024-10-05 19:04:07 Yeah. 2024-10-05 19:04:11 But you LOSE something that way. 2024-10-05 19:04:24 Well, ok - not if you still have CREATE. 2024-10-05 19:04:48 And I agree with you that create is indispensable. 2024-10-05 23:21:53 i mean on jonesforth, CREATE creates a dictionary header 2024-10-05 23:22:03 doesn't populate the code field