2024-12-22 01:18:36 KipIngram: I have indeed found the register allocation and instruction selection bits to be particularly interesting, although there's been a paradigm shift in register allocation since Appel's book 2024-12-22 01:19:57 most modern architectures have 15, 16, 31, or 32 general-purpose registers, which is enough that it's profitable to not allocate them all to system-level functions 2024-12-22 01:24:41 GeDaMo: this post on register allocation looks really interesting, thanks! I'm not yet sure what "backwards" means in some kind of arbitrarily structured graph of basic blocks or EBBs though 2024-12-22 01:48:06 xentrac: without contrxt I am assuming that one starts at the last instruction of an basic block or extended basic block and allocate registers based on what needs that value 2024-12-22 01:48:19 context* 2024-12-22 01:48:59 basically "forwards" is the direction of execution 2024-12-22 01:51:31 Zarutian_iPad: sure, it's easy to see what it would mean to go backwards inside a basic block or EBB, but register allocation inside an EBB is a pretty trivial problem, isn't it? https://www.mattkeeter.com/blog/2022-10-04-ssra/ is the context 2024-12-22 01:52:11 Well, I have 16 in the x64. I leave rsp alone so that I can make system calls on it, and otherwise I use all except one or two. 2024-12-22 01:53:11 But I do a fair bit of non-standard stuff. 2024-12-22 01:55:21 xentrac: if you think about it, register alloc is a bit like ensuring you have the datastack in same 'stack image' regardless which way you arrived at the entry of that basic block 2024-12-22 01:56:16 yeah, I've tried thinking about it that way 2024-12-22 01:56:49 this is why I am intrequed by the Mill architecture where they use a belt 2024-12-22 01:57:59 basically a finate datastack where the 'register selectors' in an instruction tells which recent values to use as arguments 2024-12-22 01:58:27 painful to keep track of by hand though 2024-12-22 02:13:24 Yeah, I watched those videos in some depth a while back - it would be fairly nightmarish to try to program it by hand. 2024-12-22 02:14:02 It is a really interesting approach. 2024-12-22 02:42:20 I think you could probably make programming it by hand doable 2024-12-22 03:39:29 I'm sure you could come up with some bookkeeping system for keeping track of everything. 2024-12-22 04:11:36 https://woset-workshop.github.io/PDFs/2024/4_pyngspice_A_High_performance.pdf 2024-12-22 13:00:10 Is it usual to distinguish constants from variables by using some naming convention? Several of the bugs I had were due to using a @ after a constant. 2024-12-22 13:57:31 no. that's one reason I prefer value to variable 2024-12-22 14:08:47 I figured that if I suffix constants with @, it would suggest that the @ is "already part of the word" so you wouldn't add a @ after it, but if it's not common practice, it can be confusing to readers of the program 2024-12-22 14:11:57 if they see x@ they will understand it fetches x 2024-12-22 14:12:09 same for x! 2024-12-22 14:12:34 but I like to have them general so I can append ! or @ instead 2024-12-22 14:12:47 x ! or x @ 2024-12-22 14:13:16 anyways I'm not a forthwright so I can't have opinion xd 2024-12-22 14:13:35 I'm just a perl dev at the end 2024-12-22 18:25:14 pgimeno: I'd say one of the nice things about Forth is that that's up to you. You can absolutely choose to do that if you wish. I personally don't share the fondness for VALUE. I'd rather have the address so I can do whatever I want with it. 2024-12-22 18:25:48 Suffixing @ seems like a reasonable approach. 2024-12-22 18:26:18 vms14: You still get an opinion. 2024-12-22 18:29:00 I just regard variables as "closer to the raw processor" than values, since in assembly you work with addresses. There's basically no way to access a variable at the machine code level without first accessing its address. 2024-12-22 18:29:14 Explicitly. 2024-12-22 18:29:49 On the other hand, in languages like C there is, and I think that's what sways some people toward VALUE. Makes it more "familiar" somehow. 2024-12-22 20:16:59 I'm surely biased towards value by decades of programming in languages where you don't have to explicitly mention variables' addresses to get their values: BASIC, C, Pascal, PostScript, Perl, Python, Lua, etc. The only exceptions I've seen are Forth, BLISS, and arguably Tcl and the Bourne shell 2024-12-22 20:19:18 it seems to be less bug-prone and more concise to do things that way, but perhaps it's more bug-prone because I'm the person writing the bugs and I have that other experience 2024-12-22 20:20:45 and perhaps without that familiarity I wouldn't weigh concision so heavily 2024-12-22 20:26:06 in theory something like $ref = \$foo + 4096; pack "p", $ref allows lookup by address in perl 2024-12-22 21:09:09 Perl5 does have a \ operator, but when you read a variable (as in `pack "p", $ref;`) you aren't applying a fetch operator to that address the way you are with a variable in Forth when you say @. Perl tempts you to think $ is such an operator, because you can say `my $x = 3; my $y = \$x; print $$y, "\n";` and in that context it does actually work as such an operator 2024-12-22 21:10:50 but in the context of `pack "p", $ref;` there isn't actually a `$` operator being applied to the bareword `ref`; it's actually just a single token. If `$` were acting like Forth's @ in that context, then instead of `$ref = \$foo + 4096;` you'd have to say `ref = \$foo + 4096;` as you do in the shell (it's irrelevant in this context that the shell doesn't allow whitespace there) 2024-12-22 21:15:51 as a separate issue, `pack "p"` allows you to access raw memory in Perl, but that's also not relevant here, because what I'm talking about is the necessity of explicitly dereferencing ordinary variables to read their runtime in-memory values, the way you do in Forth, BLISS, and assembly. It's a question of how the language semantics are organized, not what facilities one or another function in the 2024-12-22 21:15:57 language can provide 2024-12-22 21:21:59 the sigil stuff is by far the biggest hurdle to perl for me 2024-12-22 21:23:08 it can be a little confusing, and it's a bit visually noisy 2024-12-22 21:24:23 the most confusing part is when you say something like `my @x = split; print $x[3] * 2, "\n"` 2024-12-22 21:24:37 well 2024-12-22 21:24:49 the most confusing part is when you say something like `my @x = split; my $x = 37; print $x[3] * 2, "\n"` 2024-12-22 21:25:26 because intuitively you'd think that the `$x` in `$x[3]` refers to `$x` that has been defined as 37, but actually it refers to (an element of) `@x` 2024-12-22 21:26:13 also i don't view c's variables like forth values. i usually do think of a c symbol as an address, but the operators have built-in dereferences 2024-12-22 21:26:37 right 2024-12-22 21:26:43 it's hard to compare c and forth this way, forth is more functional here 2024-12-22 21:27:16 well, sort of 2024-12-22 21:28:13 which i think is my answer for pgimeno, though he's not here to see it. name your things by what they produce, not by how they do it 2024-12-22 21:28:44 I mean, if you have `*p + 1` if you want to say that `+` is applying a built-in implicit dereference to its arguments, you'd have to say that C is storing the `1` at some address, which it isn't 2024-12-22 21:29:02 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-22 21:29:08 yeah 2024-12-22 21:29:26 but more commonly you would want it to push a computed result that doesn't have an address 2024-12-22 21:29:46 which favors value 2024-12-22 21:30:55 unless you want to use +! 2024-12-22 21:30:55 yes, the absence of +! and the impossibility of defining it in standard Forth is definitely a drawback of value 2024-12-22 21:32:09 xentrac> I mean, if you have `*p + 1`... still thinking on this one. it definitely isn't a property of the operator, you're right that i'm wrong to say that 2024-12-22 21:32:51 well, maybe it is though. c has overloaded operators 2024-12-22 21:33:07 p + 1 throws an error when p is an array 2024-12-22 21:33:22 you'd think, but no, it returns a pointer to the second item in the array 2024-12-22 21:33:37 sorry p += 1 2024-12-22 21:33:41 yes 2024-12-22 21:33:43 oh, yes 2024-12-22 21:33:57 because an array isn't an lvalue in C 2024-12-22 21:34:04 yeah 2024-12-22 21:34:36 these kind of philosophical quandries are why i often think i don't need to be in the language business 2024-12-22 21:35:11 just write programs to make the lights blink and get a life 2024-12-22 21:36:50 I think the general rule in C is that converting an lvalue to an rvalue performs, conceptually, a fetch from its address (though if the lvalue is allocated to a register this may not happen in the actual assembly) and converting an array to an rvalue computes a pointer to the beginning of the array 2024-12-22 21:37:31 Common Lisp has a somewhat hairier notion of "generalized places" to use with SETF 2024-12-22 22:04:23 xentrac: I'm probably affected there by my first ever programming experience on the HP-41CV calculator, where you put a register number on the stack and then either ran STO or RCL. 2024-12-22 22:06:37 I would read that *p + 1 as "fetch what's pointed to by p and add 1 to it." Is that not right? In this case p is a pointer, yes? 2024-12-22 22:08:35 So in Forth p @ 1+ 2024-12-22 22:10:50 Part of my heartburn with VALUE is that with a variable you can easily fetch or store the content - it's just a couple of machine instructions. And if you want the address you do nothing - you have it. But with a value you do nothing to get the value, but if you do happen to want the address, which you will need to do anything other than use the value, it's a big rigamarole. 2024-12-22 22:11:06 Variable seems more flexible. It feels to me like the only time it would make sense would be if you VERY rarely did anything other than use the value, and in that case I'd use CONSTANT. 2024-12-22 22:12:41 I guess I don't really see much difference, in terms of implementation, between VALUE and CONSTANT. Having both in a system feels like it's more about programming semantics - like VALUE is a CONSTANT that, well, you MIGHT want to chagne the value of. 2024-12-22 22:13:08 Whereas you'd think of changing a constant as an error, like trying to change a #define in C. 2024-12-22 22:13:45 Well, I mean changing a #define by assignment. I guess you are allowed to re-#define it? 2024-12-22 22:13:55 Runtime change. 2024-12-22 22:14:45 I'm assuming that TO would normally mount some kind of dictionary search? I don't really think of any other way to do it. 2024-12-22 22:14:54 I wouldn't want that in my runtime. 2024-12-22 22:26:52 KipIngram: yes, `*p + 1` is "fetch what's pointed to by `p` and add 1 to it", which would be p @ @ 1 + in Forth if p is a variable 2024-12-22 22:29:09 what zelgomer was saying was that the second @ was being put there by C's `+`, but that isn't really right, because it's not p @ @ 1 @ +, which would crash in many cases 2024-12-22 22:29:37 to is potentially rather complicated in Forth, but yes, it invokes ' or comp' or similar in order to mount a dictionary search. but it happens at compile time, not runtime 2024-12-22 22:30:54 so for example in GForth 37 value x : setx to x ; see setx explains that setx is implemented as : setx 7F0EADB964B8 ! ; (in one particular run of GForth on my machine) 2024-12-22 22:32:33 I mean, it's *sort of* true that `+` is putting the @ there, because it's coercing its arguments to rvalues, and in the case where an argument is an lvalue like `*p`, that amounts to @ or its moral equivalent 2024-12-22 22:34:15 but `1` is already an rvalue 2024-12-22 22:34:18 on my machine GForth's interpret-time implementation of to boils down to 16 + ! after some error checking 2024-12-22 22:34:53 well, 10 + ! in hex 2024-12-22 22:35:20 sorry, ' 16 + ! 2024-12-22 22:36:21 and the corresponding part of the compile-state implementation of to is comp' 10 + postpone ALiteral 55F3B4A62518 compile, 2024-12-22 22:36:41 presumably 55F3B4A62518 is ! 2024-12-22 22:38:11 yes, ' ! . confirms that 2024-12-22 22:39:32 in compile state, there are some other cases where to dispatches on the "class" (definer) of the word it's ticked and compiles different sequences to store into it 2024-12-22 22:49:32 Oh, well, fair enough if you were STORING your address at p, which I guess is a better match with C. 2024-12-22 22:49:45 So yes, p @ @ 1+ 2024-12-22 22:50:50 Yeah, I think 1 @ would crash almost any system, or at least throw an error. 2024-12-22 22:50:50 Ok, compile time is a lot better. 2024-12-22 23:13:11 no, in F83 1 @ . just prints -224 ok 2024-12-22 23:13:35 and I think behavior like that is what you'd see on almost any 8-bitter 2024-12-22 23:16:18 my argument in favor of concision (and I'm aware that I'm possibly biased here by experience with things like C) is that it's better if things that are more often correct code are shorter than things that are more often incorrect code, because it's more common to accidentally leave tokens out than to accidentally insert tokens. and if x is a variable things like x 3 + and x cells are always going 2024-12-22 23:16:25 to be incorrect code 2024-12-22 23:17:12 so moving from x @ and x ! to x and to x seems like an improvement to me. something like → x would be even better 2024-12-22 23:18:16 the fact that standard Forth has some brain damage in its definitions around to and value that make them less composable seems like a drawback of the particular implementation of the idea in the standard, not a drawback of the idea in the abstract 2024-12-22 23:42:53 x 3 + isn't necessarily wrong 2024-12-22 23:43:06 well. if you allow longer variables 2024-12-22 23:43:22 if your variables are always one cell then yeah it's probably not what you meant