2023-08-12 00:26:25 <xelxebar    > next4th: Still poking at SmithForth much?
2023-08-12 00:26:29 <xelxebar    > Been going through the system.fs defs. It's a little hard to keep track of the levels at play.
2023-08-12 00:26:33 <xelxebar    > Instead of just immediate vs. compile mode, it's like there's a third "compile this immediately" set of instructions.
2023-08-12 00:26:37 <xelxebar    > For example the syscall word doesn't actually perform a syscall. Instead, it plops down the syscall asm instruction.
2023-08-12 00:26:47 <xelxebar    > So, in practice, it gets shove in immediate mode definitions, e.g. : foo  some words [ ... syscall ... ] blah ;
2023-08-12 00:28:06 <xelxebar    > I see why it's done like this. Definitely saves lots of repetitive code, but I'm kind of bearish on the particular vocab design used for bootstrapping like this.
2023-08-12 00:28:52 <xelxebar    > Like, we the . (dot) word that move a number from the stack (r15) to the data area (rdi).
2023-08-12 00:29:33 <xelxebar    > But then we also have ` (backtick) which inserts code to effectively do what dot does at call time.
2023-08-12 00:40:47 <next4th     > i just start to look at SForth, step it within blinkenlights, see that its binary interpreter build up the initial dict.  to be honest i haven't remember enough x86 instructiotns encoding yet..
2023-08-12 03:48:30 <veltas      > KipIngram: I do think 'company culture' policy is bad, but it's part of a larger cultural shift in the west to be more anal/controlling about everything
2023-08-12 03:49:22 <veltas      > Making HR do that is just part of how authoritarian things are now, because who do they answer to?
2023-08-12 03:49:56 <veltas      > If you purchase a company and can't drive them via the executive without HR then you can't do it anyway
2023-08-12 05:25:18 <Riviera     > veltas: got anything citable about this?
2023-08-12 06:07:35 <veltas      > If a tree falls in the forest and nobody cites a peer reviewed study...
2023-08-12 06:09:36 <veltas      > I have properly torn my neck muscle this morning, really agonizing
2023-08-12 06:14:36 <veltas      > In all seriousness I'm happy to discuss this in good faith but this is my analysis based on my own perspective. I am not a social scientist and I'm convinced at this point that a lot of that (not all) is pseudo-science
2023-08-12 06:15:17 <veltas      > And people are welcome to disagree, and most likely correct to disagree with at least some of what I say
2023-08-12 06:23:06 <veltas      > Might be the drugs talking after this line ---------
2023-08-12 07:12:15 <xelxebar    > next4th: Oh, cool. I forgot that Justine's blinkenlights exists. Gonna try that myself.
2023-08-12 07:24:55 <next4th     > blinkenligts have some io issues in its GUI tty, still it's very useful for me, saw the hex, predict the asm inst, then step to confirm its effect, a very pleasure loop :)
2023-08-12 09:17:30 <next4th     > 
ACTION try to see what 'REX + 80/0 ib',  ADD sign-extended imm8 to r/m8 means..

2023-08-12 09:48:02 <KipIngram   > xelbar: It's fairly common for assembly-language related code to compile instructions; there's really no case in which it makes sense to "execute a single assembly instruction" NOW.  You're usually always using the instructions to create a new, self-contained word, and emitting the code into the current dictionary point is the logical way to do that.
2023-08-12 09:48:52 <KipIngram   > veltas: I agree re: "anal and controlling."  I think we've made a lot of improvements over the years, to our attitudes and behaviors, but we've also lost some positive things too.
2023-08-12 09:49:20 <KipIngram   > Oh, sorry to hear about your neck.  :-(
2023-08-12 09:49:25 <KipIngram   > That's no fun at all.
2023-08-12 09:51:28 <next4th     > um, it seems the REX for 80 /0 is not for "sign-extened", but change ah/ch/dh/bh to spl/bpl/sil/dil..
2023-08-12 09:52:56 <KipIngram   > next4th: You guys are *really* getting down to the nitty gritty of the encodings.  I've mostly looked at the highest level patterns for "common instructions," and for the most part only at the operations that do full 64-bit data/register handling.
2023-08-12 09:53:56 <KipIngram   > My real goal is to use my assembly as part of having my Forth meta-compile itself, and you definitely don't need the entire instruction set for that.  And I'll be completely happy with a 95/5 type solution where I can write "almost" all of what I need using some proper assembly format.  If there are a few corner cases I have to encode manually, that's fine.
2023-08-12 09:54:45 <KipIngram   > My most recent work covers all of the "binary" operations, including MOV, for reg/reg, reg/[reg+offset], and [reg+offset]/reg, for 64-bit regs.
2023-08-12 09:56:05 <KipIngram   > Takes about 50 lines of code for that (about 1.5k of source).
2023-08-12 09:56:45 <KipIngram   > I picked up a few unary operations (inc, dec, neg, and not).
2023-08-12 09:56:52 <KipIngram   > also, that is.
2023-08-12 09:57:15 <KipIngram   > That already will cover "most" of what I'd need to implement a Forth system.
2023-08-12 09:59:15 <KipIngram   > What I'm looking at doing right now, though, is to base a system on a vm closely patterened after the F18A processor instruction set, and then "write the system" using that instruction set.  It looks nice and compact, and would port easily to whatever platform I wanted to use.
2023-08-12 10:00:42 <next4th     > you're thousands miles ahead me!  i just got a little curious reading the manual, about what imm8 signed-extend to imm8 means..
2023-08-12 10:01:19 <KipIngram   > Well, in certain parts of the instruction encoding I feel like you're ahead of me, too.
2023-08-12 10:01:37 <KipIngram   > I've not got the foggiest idea about the REX bytes.
2023-08-12 10:02:19 <KipIngram   > There may be REX bytes in the code my stuff generates, but I haven't identified them as such per se - I just saw a pattern and grabbed hold of it.
2023-08-12 10:03:11 <KipIngram   > My big problem is that I don't see any easy way to do any kind of exhaustive validation of my generator.  Everything I've spot checked has turned out right, but there may be bad corner cases lurking in there.
2023-08-12 10:05:05 <KipIngram   > I kind of invented my own "syntax."  I have four words s[] d[] s[+] and d[+] to get the indirect addressing modes.
2023-08-12 10:05:27 <KipIngram   > So, I might write something like thiS:  rcx rax d[] .add
2023-08-12 10:05:33 <next4th     > REX is [0100WRXB], SmitchForth have a good comment.  W=1 for 64bit, R/X/B=1 to change A:B -> R8:R15 in different oprand (reg SIB), I haven't test it though..
2023-08-12 10:05:41 <KipIngram   > That would be 'add [rcx], rax'
2023-08-12 10:06:48 <KipIngram   > 'add [rcx+0x08], rax' would be rcx rax 8 d[+] .add
2023-08-12 10:07:54 <KipIngram   > I did find that rsp, rbp, and the two matching registers in r8-r15 are "different" from the other registers.  They break the pattern a little bit and have to be special-cased.
2023-08-12 10:08:11 <KipIngram   > r12 and r13 I think.
2023-08-12 10:09:04 <veltas      > Has anyone here heard of the DRY principle?
2023-08-12 10:09:17 <KipIngram   > It is kind of a fun game to look at ideosynchracies of the encoding and try to suss out the "hardware why" of those things.
2023-08-12 10:09:24 <veltas      > Some of the best Forth code I've seen totally ignores DRY, which I think makes me think it's a bad principle
2023-08-12 10:09:30 <KipIngram   > You can kind of see how certain choices they made would have led to simpler hardware structure.
2023-08-12 10:09:43 <next4th     > your syntax looks resonable,  and yes the pattern for SP/BP is different in the table http://192.168.1.254/asm/geek64.html#modrm_byte_32_64
2023-08-12 10:09:50 <KipIngram   > No, but now I have to look it up.
2023-08-12 10:09:58 <veltas      > Don't Repeat Yourself
2023-08-12 10:10:29 <KipIngram   > yeah.  Kind  of like how databases are supposed to store any given piece of information only once.
2023-08-12 10:10:32 <veltas      > Basically you have to factor *everything* as much as possible, so you can't have anything repeat in code, even if the result is *longer*
2023-08-12 10:10:46 <next4th     > oh, i have no idea about hardware, just seem random to me..
2023-08-12 10:10:54 <KipIngram   > I don't adhere strictly to it in my database - in particular I store raw data but also store some statistics of that data in another place.
2023-08-12 10:11:02 <KipIngram   > In theory that offers an opportunity for inconsistency.
2023-08-12 10:11:17 <KipIngram   > But it saves me having to recalculate those quantities every time I want them.
2023-08-12 10:12:08 <next4th     > um, i pasted one my local url, lol
2023-08-12 10:15:40 <KipIngram   > next4th: I'm actually a hardware guy by original education.  My best skill was gate level digital logic circuitry, so I tend to peer into such things.
2023-08-12 10:16:14 <KipIngram   > One thing I'm particularly talking about is the way source register indirect and destination register indirect encodings "reverse" the positions of source and dest register specs in the encoding.
2023-08-12 10:16:57 <KipIngram   > I think what that's indicating is that the hardware that could be connected to RAM was in a particular place, and that place gets used for the reg that has the address info, regardless of whether it's source or dest.
2023-08-12 10:17:06 <KipIngram   > Some other bit in the encoding would call out the direction.
2023-08-12 10:17:52 <KipIngram   > If you wanted to stick to "source here, dest there" then you'd need RAM access in two parts of the circuitry.
2023-08-12 10:18:43 <KipIngram   > I think it's dest indirect that keeps things in the same position as reg/reg instructions, and source indirect flips them.
2023-08-12 10:19:10 <KipIngram   > I handled that in my code with a strategically placed swap of my register parameters on the stack.
2023-08-12 10:20:52 <KipIngram   > Here's what the code looks like:
2023-08-12 10:20:54 <KipIngram   > https://pastebin.com/h6npHt4n
2023-08-12 10:21:29 <KipIngram   > It's kind of "second draft" code.  Which means it's nicer than the first stuff I wrote, but still isn't anywhere near as clean as I'd like to make it.
2023-08-12 10:21:55 <KipIngram   > I apologize for the non-standard words; I've "invented" some features in my system.
2023-08-12 10:24:10 <veltas      > Is it gross to write 10. DO to mean 10 0 DO ?
2023-08-12 10:28:32 <KipIngram   > lmao...
2023-08-12 10:28:49 <KipIngram   > Well, probably, but on the other hand, if you like it...
2023-08-12 10:29:31 <KipIngram   > It wouldn't run on my system, because I use the . to indicate floating point.  I've just never been able to convince myself double ints are worth the effort on a 64-bit system.
2023-08-12 10:30:26 <KipIngram   > But I laugh because that looks exactly like the sort of thing I might do.
2023-08-12 10:30:45 <KipIngram   > In the name of a slightly shorter line of code.
2023-08-12 10:31:26 <next4th     > oh, i see you form a rule make inst from const op / reg, and s[] d[] [i] s[i] d[i], that's where need validate..
2023-08-12 10:31:59 <KipIngram   > those [] words just twiddle the bits to get indirect addressing, mostly.
2023-08-12 10:32:35 <KipIngram   > There's nothing there that's "cleanly designed."  I just started at the docs I had and ran off examples here:
2023-08-12 10:32:45 <KipIngram   > https://defuse.ca/online-x86-assembler.htm#disassembly
2023-08-12 10:32:59 <KipIngram   > until I started to see patterns emerged, and then hacked up code around them.
2023-08-12 10:33:20 <KipIngram   > And noodled on it to eliminate incorrect stuff until I couldn't find anymore incorrect stuff.
2023-08-12 10:34:04 <KipIngram   > There definitely could still be problems in it, though.
2023-08-12 10:48:25 <veltas      > Yeah double ints are pointless on 64-bit
2023-08-12 10:48:46 <next4th     > that sounds a wild adventure!  the complex x86-64 address mode is [base+(index*scale)+disp], eg: https://blog.yossarian.net/2020/06/13/How-x86_64-addresses-memory , well i'd read that next day..
2023-08-12 10:49:32 <veltas      > Honestly they're pretty much pointless on 32-bit as well
2023-08-12 10:49:51 <veltas      > It really was just very necessary on 16-bit forths to have 32-bit
2023-08-12 10:50:34 <veltas      > If I did a non-standard Forth without 16-bit support I would allow delimiters in numbers without any semantic meaning
2023-08-12 10:50:44 <thrig       > I recall some DOS assembly programmer complaining about segmented memory back in the day
2023-08-12 10:52:50 <veltas      > Or maybe what I did for my NewB design where stuff like "1.0" is 1 * some_big_number
2023-08-12 10:53:16 <veltas      > Well I think 1.0 was 0x100000000 on 64-bit systems
2023-08-12 10:53:30 <veltas      > And 1.0 would be 0x10000 on 32-bit
2023-08-12 13:24:13 <KipIngram   > So, my reMarkable came a couple of days ago.  It really does offer a considerably more "friendly" writing experience than iPad/Android tablets (at least the ones I've used).
2023-08-12 13:24:59 <KipIngram   > I already wish the software was more feature-rich, though; like I wish I could establish links among my notebooks.  Links in pdf files work fine, but the native notebook format doesn't support them.
2023-08-12 13:25:24 <KipIngram   > There's a process for creating one's own templates, though, by making suitable PDF files - you can draw on top of the pdf content.
2023-08-12 13:25:48 <KipIngram   > So I'm likely to gen up some "template" that I feel like would suit the way I'd like to operate.
2023-08-12 13:28:29 <KipIngram   > Also, it looks like it will be spectacular for reading textbooks, journal articles, etc., and being able to highlight, add notes, and so on - very  nice.
2023-08-12 13:29:39 <KipIngram   > The main thing I always disliked about tablets is the registration error between the stylus tip and where exactly the writing appears.  There's usually a little layer of glass there, and your stylus tip is on top of the glass and the writing appears below.  That tiny little gap can just really foul up the creation of neat content.
2023-08-12 13:29:44 <KipIngram   > no such issue on this thing.
2023-08-12 13:29:55 <KipIngram   > And the texture of the surface really does feel like paper.
2023-08-12 14:20:43 <veltas      > What resolution is it?
2023-08-12 14:20:54 <veltas      > Is it a square 2D grid of pixels?
2023-08-12 14:32:23 <thrig       > mind. the gap.
2023-08-12 14:42:26 <veltas      > I miss that noise
2023-08-12 14:50:13 <gordonjcp   > MINARDOR
2023-08-12 15:14:28 <KipIngram   > 1872x1404, 227 dpi.
2023-08-12 15:14:49 <KipIngram   > Gray scale - I'm guessing 16 levels.
2023-08-12 15:15:15 <KipIngram   > It lets you select colors, and you'll see them on color capable displays, but the native display just shows shades of gray.
2023-08-12 15:49:24 <veltas      > 227 DPI is alright, should be good for reading PDFs yeah
2023-08-12 17:29:09 <KipIngram   > It's plent food for reading - as good as my ereader.  I tossed one of my Dresden pdfs over onto it to check that out, and it's quite nice.
2023-08-12 17:29:36 <KipIngram   > I'll probably continue to prefer my reader for that kind of reading, but I think the reMarkable will be better for technical materials.
2023-08-12 17:30:10 <KipIngram   > My experience in the past as been that equations and so forth often don't render very well in the ereader.
2023-08-12 17:30:24 <KipIngram   > But this think can show a journal page "full size."
2023-08-12 17:33:22 <rendar      > usually, in normal langs f(x,y) is the normal way to express a function of 2 vars, while f(x,y,z) of 3 vars.. what about forth? Since we do all with the stack, is the common practice to express parameters in reverse order like `z y x f` or `y x f` or just in normal order like `x y z f` or `x y f` ?
2023-08-12 17:35:15 <thrig       > forth probably depends on the expected stack order to avoid needless swapdupfoo
2023-08-12 17:37:23 <rendar      > so x y f ?
2023-08-12 17:37:52 <thrig       > maybe, maybe not. maybe some other word produces x f y so in that case ...
2023-08-12 17:56:12 <veltas      > Exactly as thrig says the word order is chosen to avoid extra shuffling
2023-08-12 17:56:35 <thrig       > soooo you need to think about stack design and context matters
2023-08-12 17:57:06 <veltas      > For example compare memset() and FILL. memset(adr, val, num) and FILL ( adr num val)
2023-08-12 17:57:37 <veltas      > That's because when you write FILL you probably want to put the value to fill with there, so it's the top stack item
2023-08-12 17:57:47 <veltas      > and you can write '0' FILL
2023-08-12 17:58:29 <veltas      > And then often (but not always) you want to specify a fixed size, so you can... 1024 BL FILL
2023-08-12 17:58:53 <veltas      > But also it's conventional to put size over the address
2023-08-12 17:59:38 <veltas      > Likewise ! takes the address from the top of the stack, because of how often you will use a named location
2023-08-12 18:00:36 <veltas      > e.g.  >IN @ ... >IN !
2023-08-12 18:03:48 <veltas      > If I wrote a non-standard Forth I would probably have more 'core' words leave things on the stack
2023-08-12 18:04:19 <veltas      > e.g. I'd have FILL leave the address on the stack
2023-08-12 18:07:35 <KipIngram   > veltas:  I would call that .FILL
2023-08-12 18:07:56 <KipIngram   > That's what my . prefix does: it keeps the deepest otherwise discarded argument.  It's quite useful in some situations.
2023-08-12 18:09:46 <veltas      > What about FILL|
2023-08-12 18:09:57 <veltas      > Because you're 'piping' the object
2023-08-12 18:10:16 <KipIngram   > You could do that.  I think the important thing is consistency.
2023-08-12 18:10:36 <veltas      > I don't think I have any use for | character so far
2023-08-12 18:10:40 <KipIngram   > I just "know" now what to use . like that.
2023-08-12 18:10:51 <KipIngram   > of course, not "all" words have that - it's not built into the system or anything.
2023-08-12 18:11:02 <KipIngram   > I just have <word> and .<word> in some cases.
2023-08-12 18:11:16 <KipIngram   > I have it for all of the conditional returns and conditional recurse words.
2023-08-12 18:11:18 <veltas      > You have a lot of coded variations of words
2023-08-12 18:11:31 <KipIngram   > I do.
2023-08-12 18:11:35 <veltas      > Being systematic is certainly useful
2023-08-12 18:12:03 <KipIngram   > I generate the source for that big matrix of words with Python.
2023-08-12 18:12:24 <KipIngram   > It just creates a file I can #include.
2023-08-12 18:14:47 <veltas      > I have a few of my own conventions
2023-08-12 18:15:06 <veltas      > Like WORD! usually means "try something and throw/abort on error"
2023-08-12 18:19:43 <veltas      > And WORD? means "check something and return a flag" and ?WORD means "consume a flag and optionally do something"
2023-08-12 18:21:26 <veltas      > I usually use WORD: for an immediate word that parses the next word
2023-08-12 18:21:59 <veltas      > I suppose [WORD] would be more conventional
2023-08-12 18:23:43 <veltas      > But I think [WORD] means a little more, it's more like "this is the compiled version of WORD"
2023-08-12 18:31:11 <KipIngram   > That all makes good sense.
2023-08-12 18:33:42 <KipIngram   > I do similar things with ?word / word? but I'm afraid I haven't been as disciplined about that.
2023-08-12 18:34:24 <KipIngram   > One nice little side-effect of the . prefix is that .. prints the top stack item without consuming it - it's useful for debugging.
2023-08-12 18:48:36 <veltas      > Regarding discipline, 'perfect is the enemy of good'