2023-07-24 01:27:18 <xelxebar    > Ended up having dreams about decoding x86 opcodes last night. lol
2023-07-24 03:14:55 <veltas      > More than dreams, I will literally hallucinate things after doing something really intensely for hours
2023-07-24 03:16:15 <veltas      > It's my belief rdi and rsi are chosen to match memcpy usage, i.e. "destination" and "source" registers are correct
2023-07-24 03:16:50 <veltas      > And there are a number of functions that match the same usage, although lots of nu C programmers like putting destination after the size... they will have to go cry to someone else
2023-07-24 04:25:26 <xelxebar    > veltas: Haha. That happens to me too, though maybe not as intensely as you. In grad school, after having my head in differential geometry stuff all day, walking home my brain would literally be trying to differentiate random things like people's faces or street lamps. It was a weird experience.
2023-07-24 04:26:09 <xelxebar    > That's... a really good point about rsi and rdi. The designers of the sysv syscall interface might be the ones to be lauding.
2023-07-24 08:58:59 <KipIngram   > xelxebar: I've had dream situations like that.  Once back when I was consulting I'd been working on a PCB layout for a client, and one night I dreamed weird 3D PCB layout dreams.  Not really "like" anything real, being 3D in a much stronger sense that real layout, but nonetheless in my  mind it was definitely "PCB layout."  That dream just felt like it lasted forever.
2023-07-24 09:00:01 <KipIngram   > veltas: Yes, to the extent I "optimized" register choices around that kind of thing it was to optimize the efficiency of move / cmove.
2023-07-24 09:00:52 <KipIngram   > Which mostly meant using rcx as my TOS register.  Since we cache only one stack item in registers, that was as far as it went.  Before I added the A and B address registers to my system, I left rsi and rdi free, so I wound't need to save them.
2023-07-24 09:01:17 <KipIngram   > Once they got promoted to A and B, though, I needed to push and pop them.
2023-07-24 09:02:07 <KipIngram   > On this next one I'm planning to use rsi as the instruction p ointer, so that I can use  lods in NEXT.
2023-07-24 09:02:40 <KipIngram   > Oh, differential geometry.  Fun fun...
2023-07-24 09:03:54 <KipIngram   > xelxebar: What did you study in grad school?  I guess the best way to sum mine up would be "electromagnetic theory."  I worked for a lab at the time where we did pulsed energy conversion systems.  Railguns / coilguns and rotating machinery we invented to power them.
2023-07-24 09:04:55 <KipIngram   > We dealt in extremely high current levels, like mega-amperes.
2023-07-24 09:12:47 <KipIngram   > The basic idea on those rotating machines was to design them for good impedance match with the railgun or whatever load we were focused on.
2023-07-24 10:19:22 <KipIngram   > So it says in the documents for that Maxim board that the daplink utility can be used to flash it.  But I go to the daplink.io site, and that particular part number is not in the list of supported items.  So I don't know exactly what that means.  I'm wondering if daplink is a simpler way of working with the thing compared to all that fancy Eclipse based stuff.
2023-07-24 10:19:55 <KipIngram   > Heck, if I can just have a tool that will let me take a binary file that I create with hexedit and shove it into the boot record of the thing, that's sufficient I think.
2023-07-24 10:20:22 <KipIngram   > I just don't need something that's carrying a whole bucket of fancy library routines with it.
2023-07-24 10:44:08 <xelxebar    > KipIngram: That sounds like a fun lab to work in! Mega-Amperes is a bit scary though. lol
2023-07-24 10:45:48 <xelxebar    > I was working in a cosmological simulation lab, and my research was trying to port GR over into the language of discrete manifolds as a way to potentially control error propagation.
2023-07-24 10:54:28 <KipIngram   > Oh, that sounds fun too.
2023-07-24 10:55:09 <KipIngram   > Yeah, we got to get our hands dirty.  We had our biggest railgun installed in a tower aimed into a deep hole in the ground.  We'd put various pieces of armor plating down there (tank armor) and blow holes in it.
2023-07-24 10:55:26 <KipIngram   > There was a lot of money for that research at the time - the military was hungry to have railgun equipped tanks.
2023-07-24 10:56:08 <KipIngram   > That just never panned out, though.  I think there a couple of big naval vessels with railguns installed (experimental), but the energy storage and barrel containment stuff was just too big and heavy for tank deployment to ever make sense.
2023-07-24 10:56:31 <thrig       > why not have a drone kamikaze instead
2023-07-24 10:57:01 <KipIngram   > The big problem was that you couldn't use steel to hold the rails in place - interfered with the magnetic field.  You had to have a layer of some kind of strong plastic, with steel outside of that, and it just got big and heavy.
2023-07-24 10:57:12 <KipIngram   > This was before we had the microelectronics to make drones feasible.
2023-07-24 10:57:21 <KipIngram   > This was second half of the 1980's.
2023-07-24 11:04:48 <KipIngram   > Even a little bit of flex in those long rails affected the area of the magnetic circuit and took a big bite out of muzzle velocity.
2023-07-24 11:05:06 <KipIngram   > You want the only way for that area to increase to be the projectile moving down the barrel.
2023-07-24 11:06:09 <KipIngram   > There was a sister lab, also at UT, that made the proejctiles.  Tipped with depleted uranium pentrators and all that jazz.  Very swanky "scifi" looking things.
2023-07-24 11:06:35 <thrig       > why not shoot something with an A-10 warthog
2023-07-24 11:07:05 <KipIngram   > This isn't one of ours, but along these lines:
2023-07-24 11:07:07 <KipIngram   > https://www.defensedaily.com/wp-content/uploads/2017/07/hypervelocity-projectile-7-20-17-onr-expo-2.jpg
2023-07-24 11:07:31 <KipIngram   > Those pieces surrounding it fly off to the sides after it leaves the barrel.
2023-07-24 11:07:53 <KipIngram   > Hey man, I didn't make all those plans.  They had money - we had expertise.
2023-07-24 11:12:40 <KipIngram   > I suspect they were spending money on "every possibility" - this just happened to be the one we worked on.
2023-07-24 13:00:19 <DKordic     > KipIngram: Link to that DevBoard please.  I can't find it in my log.  Interesting idea.
2023-07-24 13:01:05 <xelxebar    > DKordic: Here you go:
2023-07-24 13:01:11 <xelxebar    > 22:51 <KipIngram> https://www.digikey.com/en/products/detail/analog-devices-inc-maxim-integrated/MAX32655FTHR/17885194
2023-07-24 13:01:13 <xelxebar    > 22:51 <KipIngram> https://www.analog.com/media/en/technical-documentation/data-sheets/MAX32655FTHR.pdf
2023-07-24 13:01:32 <DKordic     > Thank You.
2023-07-24 13:04:23 <xelxebar    > So, I'm a pretty big fan of APL because of how simple and direct it is, but I'm not a huge fan of how giant the de facto implementations are.
2023-07-24 13:05:43 <xelxebar    > The idea of bootstrapping an APL out of Forth is one that's been tickling my subconscious since I first encountered JonesForth.
2023-07-24 13:06:52 <xelxebar    > So, a lot of the affordances of APL come from its one-glyph symbols.
2023-07-24 13:07:51 <xelxebar    > It'd be really painful if we needed to separate them out with spaces.
2023-07-24 13:08:58 <xelxebar    > But if we assume utf8 encoding, it occured to me that it's pretty easy to detect non-ascii characters.
2023-07-24 13:11:43 <xelxebar    > The word parser could simply parse ascii-only words normally, otherwise, simply declare a fiat that non-ascii characters are one character long.
2023-07-24 13:12:35 <xelxebar    > s/non-ascii characters/non-ascii words/
2023-07-24 13:14:46 <xelxebar    > Of course, multi-character graphemes would be broken, but that's probably okay for the low-level parser.
2023-07-24 13:17:34 <xelxebar    > Is there some clever bit-twiddling we can do to count the number of consecutive 1's starting at the most significant bit of a byte?
2023-07-24 13:18:16 <thrig       > bit twiddling hacks is a thing
2023-07-24 13:28:05 <DKordic     > I guess You already found https://www.jjj.de/bitwizardry/bitwizardrypage.html
2023-07-24 13:33:42 <KipIngram   > https://www.digikey.com/en/products/detail/analog-devices-inc-maxim-integrated/MAX32655FTHR/17885194
2023-07-24 13:33:50 <KipIngram   > DKordic: ^
2023-07-24 13:34:02 <KipIngram   > Oh, I see you already got it.  Sorry.
2023-07-24 13:34:36 <KipIngram   > xelxebar: I'm also quite interested in APL.  I like the attempt at mathematical rigor in it, and I find the terse symbology quite appealing.
2023-07-24 13:34:43 <KipIngram   > Matches how I tend to name words anyway.
2023-07-24 13:35:15 <KipIngram   > And yes, a "conceptual merger" between APL and Forth is of high interest to me.
2023-07-24 13:35:51 <KipIngram   > I've also thought about having a list of "atomic characters" that will get recognized as one-char words, even if they're adjacent to other characters.
2023-07-24 13:36:07 <KipIngram   > You could start up with that list empty - stock  Forth behavior - and modify as you desired.
2023-07-24 13:36:46 <KipIngram   > xelxebar: See "Hacker's Delight."  it's a book you should procure.
2023-07-24 13:36:56 <KipIngram   > It has all kinds of little cleverisms of the sort you just asked about.
2023-07-24 13:38:12 <KipIngram   > The topic at hand when I thought of that list idea was JSON processing.
2023-07-24 13:38:38 <KipIngram   > I think if you could have certain characters definable as words and recognize them non-space-delimited a JSON processor would be straightforward.
2023-07-24 13:39:31 <KipIngram   > I have a love-hate relationship with the space delimitation requirement.  It's so, soooo simple - that's nice.  But it just totally shuts the door on really sophisticated lexical processing.
2023-07-24 13:40:12 <KipIngram   > Forth gives us a great way to specify what we want our code to look like.  But it doesn't give us similar flexibility in specifying what our input looks like.  And I often think it would be nice if it did.
2023-07-24 13:40:43 <KipIngram   > Chuck would have us re-define the problem so that it was Forth amenable, and that probably is the formula for the "simplest overall" solution.
2023-07-24 13:40:49 <KipIngram   > But sometimes you can't control your input.
2023-07-24 13:41:13 <thrig       > ." this isn't awkward"
2023-07-24 13:45:25 <KipIngram   > Oh, and the related shortcoming is that we're limited to integer literals.  Not everything is a number.
2023-07-24 13:45:49 <KipIngram   > Why can't we express literal strings and for that matter literal structures, as an integral part of the language?
2023-07-24 13:46:25 <KipIngram   > "this is a string" is something that really ought to be sensible in any language.
2023-07-24 13:46:36 <KipIngram   > But in Forth we don't have a good place to put that data.
2023-07-24 13:47:38 <KipIngram   > I think "this is a string" should leave an address on the stack.
2023-07-24 13:47:42 <thrig       > "but then there are \"complications\""
2023-07-24 13:47:49 <KipIngram   > Yes.
2023-07-24 13:48:09 <KipIngram   > The most "Forth friendly" solution I've thought of is
2023-07-24 13:48:12 <KipIngram   > s "this is a string"
2023-07-24 13:48:22 <KipIngram   > or s \this is a "string"\
2023-07-24 13:48:41 <KipIngram   > Use any character at all as the delimiter.
2023-07-24 13:49:05 <thrig       > balanced delimiters are somewhat popular, {string} or qq{string}
2023-07-24 13:49:13 <KipIngram   > But that's complicated too because if you want to compile it it has to be handled altogether differently.
2023-07-24 13:53:27 <KipIngram   > and that isn't "innate literal processing."
2023-07-24 13:53:39 <KipIngram   > Because you have to call out that s word.
2023-07-24 13:53:57 <KipIngram   > You don't have to tell it you're about to give it a number.
2023-07-24 13:56:01 <DKordic     > KipIngram: I see it as /elegant variation/.  It's IMMEDIATE.  IMHO JSON has no place there.  And more interesting and inevitably complex problems would have a matching... foundation.
2023-07-24 13:56:01 <DKordic     > How would You define those Literals in an idealization where clarity and elegance is at the first place and efficiency is not a concern?!  Executable Specification if You like.
2023-07-24 14:07:11 <KipIngram   > I think JSON is an *application choice*.  So do you you want to be able to write the applications you want to write, or not?
2023-07-24 14:07:16 <KipIngram   > I want a "capable language."
2023-07-24 14:08:04 <KipIngram   > Anway, someone here, back when we were discussing that, pointed out that all one would  need to do is make a pass over the JSON text and insert spaces in certain places, and then feed THAT to the interpreter.
2023-07-24 14:08:10 <KipIngram   > and that's true - that would work.
2023-07-24 14:08:33 <KipIngram   > It just doesn't quite qualify as being able to "tell Forth what you input looks like."
2023-07-24 14:10:53 <KipIngram   > Anyway, it's a general concern I have, but in particularly nimble string handling just seems like a fundamental requirement to me, and usually Forth doesn't have it.
2023-07-24 14:10:57 <KipIngram   > You can code it, of course.
2023-07-24 14:11:07 <KipIngram   > But it feels like something that should be out of the box to me.
2023-07-24 14:11:24 <KipIngram   > Strngs are... ubiquitous.
2023-07-24 14:12:47 <veltas      > I think Forth 'has it', it's just not in a C-style format
2023-07-24 14:12:59 <veltas      > And JSON has C-style syntax
2023-07-24 14:14:13 <KipIngram   > Fair enough.  But JSON has come to be used much more generally, as a serialization mechanism.
2023-07-24 14:14:15 <DKordic     > I completely agree with You.  I would even add HTML5 these days.  Only for interoperability, I can not recomend it in any way.
2023-07-24 14:15:02 <KipIngram   > I would debate, though, the point that Forth "has" string handling.  You can implement anything in Forth, but on startup it doesn't know much what to do with strings.
2023-07-24 14:15:32 <KipIngram   > You can't just start up your Forth and slap a string onto the stack.
2023-07-24 14:16:42 <DKordic     > I agree with You.  Not until someone does it...
2023-07-24 14:20:26 <DKordic     > I should study F83 to see how little has changed at all.
2023-07-24 14:23:10 <veltas      > KipIngram: You sort of can, if you consider PAD to be a size 1 stack
2023-07-24 14:23:41 <veltas      > What's a good 'stringy' exercise that we can write in Forth? I think an example might be fun
2023-07-24 14:24:53 <DKordic     > veltas: strstr?
2023-07-24 14:26:30 <DKordic     > IMHO GC must be an option, however inefficient it might be.
2023-07-24 14:57:19 <KipIngram   > DKordic: I'm not so sure.  I've thought a lot about having a reigon of RAM that's treated as scratch space.  Much like PAD, but large enough to provide storage for many items.  A pointer would just advance through that region, and wrap around when it hit the end.  The idea would be that by the time you wrapped around and overwrote an item, you would no longer need it.
2023-07-24 14:57:49 <KipIngram   > That's not "rigorously safe," but I think in practice it could be made to work fine.  And it wouldn't need performance impairing garbage collection.
2023-07-24 14:58:50 <thrig       > AMD CPU just had a "use after free" vulnerability
2023-07-24 14:58:54 <KipIngram   > I don't have a specific example in mind, veltas, but the sort of functionality I usually find valuable in Python involves splitting strings on specified characters (which takes a string and a char and leaves an array of strings), concatenating strings, etc.
2023-07-24 14:59:40 <KipIngram   > When I run a test job at work, the "job name" might look like t his:
2023-07-24 15:00:18 <KipIngram   > 2023-07-23-0811_FCM4-38p4TB_v4p0p1p44_2p85to1-50Percent-PCIe4-30W_Combo-c2.
2023-07-24 15:00:42 <KipIngram   > There's a lot of information embedded in that name, and when building the name or interpreting the name I make heavy use of those string diddling functionalities.
2023-07-24 15:00:58 <KipIngram   > Splitting on either "_" or "-" or both as needed.
2023-07-24 15:01:15 <veltas      > thrig: People complain about the Z80 but it doesn't have any use-after-free flaws
2023-07-24 15:01:18 <KipIngram   > string.replace() is useful too.
2023-07-24 15:01:48 <KipIngram   > I imagine there were people in the business who had a "total understanding" of the Z80.
2023-07-24 15:02:03 <KipIngram   > It was a tractable device to understand, potentially down to the gate level.
2023-07-24 15:02:11 <thrig       > Z80 probably isn't speculating
2023-07-24 15:02:20 <KipIngram   > Right.
2023-07-24 15:02:29 <KipIngram   > Had no cache either.
2023-07-24 15:02:46 <veltas      > thrig: No need to speculate, the manual says as much
2023-07-24 21:49:17 <xelxebar    > KipIngram: Yeah, Hacker's Delight just does a binary search to find number of leading 1s or 0s.
2023-07-24 21:52:36 <xelxebar    > On second thought, though, with utf8, we know there are precisely 0-4 leading ones, so we could probably just do a block of mask-and-jumps to copy the correct number of bytes.
2023-07-24 21:53:00 <xelxebar    > At least, assuming well-formed utf8 makes life *way* easier:
2023-07-24 22:02:09 <xelxebar    > KipIngram: On APL, I'm not sure it's so much about mathematical rigor. Have you encountered Iverson's "Notation as a Tool of Thought" paper? https://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf
2023-07-24 22:04:28 <xelxebar    > IMO, the "ability to subordinate detail" feature is absolutely killer.
2023-07-24 22:05:28 <xelxebar    > The current zeitgeist in programming is declarative and explicit everything, which is fine as far as it goes, but the cognitive cost of that is completely insignificant.
2023-07-24 22:30:09 <xelxebar    > Okay, I think this would get the utf8 bytes into %rax: http://ix.io/4Bqh
2023-07-24 22:33:25 <xelxebar    > No need to even convert those into unicode values as long as input encoding is utf8.
2023-07-24 23:44:19 <KipIngram   > xelxebar: Yeah, I forget exactly how I decided to do that utf8 handling, but it was fairly straightforward.  I think I may have shifted a byte every time around the loop and when I finished going over those 1's and came to a 0 I was done.  Can't remember for sure.
2023-07-24 23:45:19 <KipIngram   > Yes, I've read over Iverson's paper.  I felt like what he was trying to do was extend the basic process of arithmetic in a way that maintained its logical nature.