2022-07-11 07:31:04 <KipIngram   > So, I mentioned yesterday that some of the major assemblers (nasm confirmed and I read that the Microsoft assembler is the same) won't actually allow one to assemble explicit IP-relative addressing modes, though they do use apparently use those modes implicitly in certain cases.  Anyone have any idea why this choice might have been made?  It seems like it's a "wart" to me, but maybe there's some good logical
2022-07-11 07:31:06 <KipIngram   > reason?
2022-07-11 07:31:55 <KipIngram   > I mean, these are perfectly well-defined instructions; it just seems odd to me that they're not supported.
2022-07-11 07:39:29 <X-Scale     > KipIngram: there are some very knowledgeable folks over the ##asm channel
2022-07-11 07:40:24 <KipIngram   > Good idea.
2022-07-11 07:45:12 <KipIngram   > I asked; if someone sheds light I'll share.
2022-07-11 07:45:41 <KipIngram   > My guess is that I'll get at least one "you're misguided to want to do that" answer.  :-)
2022-07-11 07:46:15 <KipIngram   > That seems to be a common type of response in "learned forums."
2022-07-11 07:47:02 <KipIngram   > My own opinion, really, is "if it's a valid instruction you should be able to write it."
2022-07-11 07:47:11 <KipIngram   > It's an *assembler*.
2022-07-11 07:47:38 <KipIngram   > An assembler should make any attempt to "impose good habits" on you.
2022-07-11 07:47:44 <KipIngram   > shouldn't
2022-07-11 07:48:02 <ecraven     > it can always warn you, but it shouldn't just fail to assemble valid instructions
2022-07-11 07:48:13 <KipIngram   > That's fair - yeah.
2022-07-11 07:48:18 <ecraven     > do you have an example that doesn't assemble correctly?
2022-07-11 07:48:36 <KipIngram   > Yeah, one second.
2022-07-11 07:49:25 <KipIngram   > In nasm, this:
2022-07-11 07:49:35 <KipIngram   > lea rcx, [rip]
2022-07-11 07:49:39 <KipIngram   > gives me
2022-07-11 07:49:41 <KipIngram   > 64.asm:1223: error: symbol `rip' not defined
2022-07-11 07:49:52 <KipIngram   > but on defuse.ca it assembles to this:
2022-07-11 07:50:32 <KipIngram   > 0x48, 0x8D, 0x0D, 0x00, 0x00, 0x00, 0x00
2022-07-11 07:50:41 <KipIngram   > maybe nasm uses some other symbol for rip?
2022-07-11 07:51:01 <KipIngram   > And if I db those bytes into the code, it seems to do precisely what I expect it to do.
2022-07-11 07:51:51 <dave0       > KipIngram: you might need to specify a label
2022-07-11 07:52:40 <ecraven     > KipIngram: this seems relevant https://forum.nasm.us/index.php?topic=1245.0
2022-07-11 07:52:50 <ecraven     > they do   lea eax, [$]
2022-07-11 07:53:01 <KipIngram   > Aha.
2022-07-11 07:53:09 <KipIngram   > Thank you.
2022-07-11 07:53:12 <KipIngram   > I had looked here:
2022-07-11 07:53:14 <KipIngram   > https://www.nasm.us/doc/nasmdo12.html
2022-07-11 07:53:14 <dave0       > KipIngram: oh never mind i just tried it and it didn't work, still said "rip undefined"
2022-07-11 07:53:30 <KipIngram   > Which has a list of register names, but doesn't mention $ (at least not in the lists there).
2022-07-11 07:53:31 <ecraven     > they seem to say RIP isn't a proper register, so nasm doesn't pretend it is
2022-07-11 07:53:33 <KipIngram   > Thank you.
2022-07-11 07:53:37 <KipIngram   > Oh.
2022-07-11 07:53:40 <ecraven     > very welcome, this is interesting ;)
2022-07-11 07:53:41 <KipIngram   > It didn't work.
2022-07-11 07:54:11 <ecraven     > hm.. maybe you need this too?  %idefine rip rel $
2022-07-11 07:54:15 <ecraven     > not sure how %idefine works
2022-07-11 07:55:29 <KipIngram   > Well, I'm content using the db approach if I actually need to do it; I just found it a curiosity.
2022-07-11 07:56:02 <KipIngram   > One responder on ##asm said that nasm supports this:
2022-07-11 07:56:04 <KipIngram   > lea rax, [rel foo]
2022-07-11 07:56:11 <KipIngram   > And that's fine for actual labels.
2022-07-11 07:56:45 <KipIngram   > But the application I had in mind (this had to do with supporting dave0's "next == ret" design) needed an actual immediate offset.
2022-07-11 07:57:52 <ecraven     > it's been a long time, but doesn't $ mean "current instruction address" in nasm?
2022-07-11 08:00:17 <KipIngram   > This works:
2022-07-11 08:00:19 <KipIngram   > lea     rcx, [rel $]
2022-07-11 08:00:33 <KipIngram   > Yes, looks like, but also seems to require that rel
2022-07-11 08:00:41 <KipIngram   > It assembles at least, without error.
2022-07-11 08:00:49 <KipIngram   > I haven't checked function yet.
2022-07-11 08:01:53 <KipIngram   > One guy said $ might not be quite the same as rip in that, though.
2022-07-11 08:02:07 <KipIngram   > $ may be the address of THIS instruction, whereas rip already points to the next one.
2022-07-11 08:02:35 <dave0       > KipIngram: hang on i'll zip up when i've written, it's hardly commented but hopefully you can follow it
2022-07-11 08:04:03 <KipIngram   > I've been enamored with this idea ever since you first talked about it.  I'm not really a direct threading guy, but I suspect this is likely the best way to do direct threading.  And has the really nice feature of a one-byte NEXT.
2022-07-11 08:04:59 <KipIngram   > Though I guess it does require that you have 64-bit instruction cells, right?  If you're in 64-bit mode?
2022-07-11 08:05:31 <dave0       > i made it 128-bit lol
2022-07-11 08:05:35 <dave0       > but yes, amd64
2022-07-11 08:06:07 <KipIngram   > It might be really hard to manage on a Mac, given their reqirement of total relocatability.  Because those addresses in a definition get *returned* to, so they have to be absolute addresses.
2022-07-11 08:06:29 <dave0       > i'm on netbsd... i had to use a netbsd program to compile because it doesn't like executable + writable sections
2022-07-11 08:06:37 <KipIngram   > In my system they're offsets, and NEXT adds a base address on.
2022-07-11 08:06:51 <dave0       > hang on i'll zip it up
2022-07-11 08:10:23 <dave0       > lets see if dcc works
2022-07-11 08:11:16 <dave0       > ooh is it working??
2022-07-11 08:11:22 <KipIngram   > Oh, I had no idea my client would do that.
2022-07-11 08:11:30 <KipIngram   > Yeah - it told me how to receive it.
2022-07-11 08:11:33 <KipIngram   > Cool.
2022-07-11 08:11:39 <dave0       > oh good it's even working
2022-07-11 08:11:49 <dave0       > saves me pasting it on a website
2022-07-11 08:11:52 <KipIngram   > Yeah - new pony trick.
2022-07-11 08:12:05 <dave0       > slow but good!
2022-07-11 08:12:11 <KipIngram   > Yep.
2022-07-11 08:12:13 <dave0       > nice
2022-07-11 08:12:15 <dave0       > very nice
2022-07-11 08:12:20 <dave0       > cool
2022-07-11 08:12:59 <KipIngram   > Of course, it went to my server that I have weechat running on.  But that's ok - that's a screen session so I can just open another window to check it out.
2022-07-11 08:13:13 <dave0       > ehehe
2022-07-11 08:13:59 <KipIngram   > And yes - 'lea rcx, [rel $]` does assemble, but it assembles using a negative 7 byte offset, so $ is referring to the "current" instruction.
2022-07-11 08:14:13 <KipIngram   > But at least it's an official nasm syntax that gets at the general functionality.
2022-07-11 08:14:45 <KipIngram   > You'd just use 'lea rcx [rel $+7]' to get the exact same bytes.
2022-07-11 08:14:51 <dave0       > lea rcx,[rip+$]   makes more sense, but rel doesn't look bad
2022-07-11 08:15:21 <KipIngram   > I guess their reasoning there is that rip isn't a generally usabe register.
2022-07-11 08:15:30 <KipIngram   > usable
2022-07-11 08:15:36 <KipIngram   > So, fair enough.
2022-07-11 08:15:49 <KipIngram   > I no longer completely disapprove.  :-)
2022-07-11 08:15:55 <dave0       > lol
2022-07-11 08:17:23 <dave0       > KipIngram: so the file you want is    amd64/dtc.sx
2022-07-11 08:18:30 <KipIngram   > thanks
2022-07-11 08:18:45 <KipIngram   > Well, today's the end of my vacation.  Back to the mill tomorrow.
2022-07-11 08:19:14 <KipIngram   > It's been nice - I usually cover "light work" requests when I'm off; I don't really have a "backup person," but this time I didn't a single ping from them.
2022-07-11 08:19:18 <dave0       > KipIngram: amd64/ i386/ i286/   are the "native" code files,   realmode/   works in dos/dosbox   sectorFORTH/  is my 417(!) byte bootsector forth   temp/   is nothing,  verified/   is where i tested some arithmetic code
2022-07-11 08:19:35 <KipIngram   > Oh, sectorforth is in there too?
2022-07-11 08:19:35 <dave0       > oh cool, did you get a tan on your vacation? lol
2022-07-11 08:19:50 <dave0       > KipIngram: yeah my version, not the one on github
2022-07-11 08:19:51 <KipIngram   > Not really - I hung around the house mostly.
2022-07-11 08:20:37 <KipIngram   > We've had several days of 105 degree or so highes here this past week.
2022-07-11 08:20:38 <dave0       > KipIngram: yesterday i saved 4 bytes in sectorforth in the line input code
2022-07-11 08:20:52 <KipIngram   > :-)  Stuff like that gets to be a "personal challenge."
2022-07-11 08:21:24 <dave0       > the gall of sectorlisp saying it is shorter than sectorforth !
2022-07-11 08:21:39 <KipIngram   > Once you're under 512, you win - but it's still fun to optimize.
2022-07-11 08:22:06 <dave0       > KipIngram: sectorlisp was bragging about 435 bytes
2022-07-11 08:22:21 <KipIngram   > What are you down to now?
2022-07-11 08:22:27 <dave0       > 417 bytes
2022-07-11 08:22:32 <KipIngram   > Booyah!
2022-07-11 08:22:35 <dave0       > ehehehe
2022-07-11 08:24:20 <KipIngram   > Does it actually run a computer in some way?  I mean, if you boot it can you type at it?
2022-07-11 08:24:55 <KipIngram   > Are all those old BIOS routines we used to use in the DOS days still there?
2022-07-11 08:25:01 <KipIngram   > Real mode stuff?
2022-07-11 08:25:45 <dave0       > yup
2022-07-11 08:25:51 <dave0       > i run it in dosbox
2022-07-11 08:26:08 <dave0       > dosbox is a fine program
2022-07-11 08:27:01 <KipIngram   > That's really pretty interesting. Does it have BLOCK?  Could I in theory use it to bootstrap a computer and build from there, using Forth source on disk?
2022-07-11 08:27:06 <dave0       > oh i haven't tried it on a real machine .. i guess i could put it on a flash drive and try booting on the laptop
2022-07-11 08:27:34 <dave0       > KipIngram: oh no
2022-07-11 08:27:34 <KipIngram   > It would be interesting, but if it works in DOSbox I guess it should run on a real machine too.
2022-07-11 08:27:42 <KipIngram   > Ok.
2022-07-11 08:27:45 <dave0       > KipIngram: check    sectorFORTH/readme
2022-07-11 08:28:54 <KipIngram   > Seems like that would be "total success" - if you could POTENTIALLY boot a computer with it and then proceed to bring that computer up to any level of functionality you wanted to.
2022-07-11 08:29:00 <KipIngram   > Even if it was cumbersome at first.
2022-07-11 08:29:05 <dave0       > KipIngram: it's nearly a carbon copy of   https://github.com/cesarblum/sectorforth
2022-07-11 08:29:20 <KipIngram   > Yeah, just opened that.
2022-07-11 08:29:22 <dave0       > KipIngram: there's a `hello world` example
2022-07-11 08:29:39 <KipIngram   > Well, you now have 95 bytes available...
2022-07-11 08:30:00 <dave0       > KipIngram: my example  hello.forth  resembles cesarblum's except i swapped + to -
2022-07-11 08:30:20 <KipIngram   > Maybe disk access could be added with that space.
2022-07-11 08:30:21 <dave0       > KipIngram: there's actually a more functional forth in 512 bytes that supports writing to disk
2022-07-11 08:30:30 <dave0       > hang on let me look it up
2022-07-11 08:31:11 <KipIngram   > I mean, if you can LOAD you can do anything.
2022-07-11 08:31:59 <dave0       > https://github.com/NieDzejkob/miniforth
2022-07-11 08:32:18 <dave0       > yes miniforth can .. i haven't actually tried it
2022-07-11 08:32:24 <KipIngram   > So if you could boot it, laboriously peck content onto the disk, and LOAD... the sky's the limit.
2022-07-11 08:32:43 <dave0       > sectorforth is more of a proof-of-concept ... sectorforth strongly went for minimalist
2022-07-11 08:32:51 <KipIngram   > I'm pretty unlikely to try to do that, but knowing it was possible would be pleasing.
2022-07-11 08:32:59 <KipIngram   > Sure.
2022-07-11 08:33:34 <KipIngram   > BLOCK, FLUSH, and LOAD would get you there.
2022-07-11 08:34:03 <KipIngram   > And it wouldn't have to be a high performance BLOCK.  So long as it moved the content back and forth.
2022-07-11 08:34:26 <KipIngram   > Actually just blk-read and blk-write would do.
2022-07-11 08:34:32 <dave0       > i think it just uses the bios `read disk` interupt
2022-07-11 08:34:45 <dave0       > miniforth does, that is
2022-07-11 08:34:46 <KipIngram   > I went to a good bit of trouble with my BLOCK to make it as fast as possible when the data is already resident in a buffer.
2022-07-11 08:35:10 <KipIngram   > That part's in assembly and when you run BLOCK the first thing that runs is that primitive.
2022-07-11 08:35:29 <KipIngram   > If it finds the block is NOT resident, it hands off to blk-read and blk-write which are written in Forth, so they're slower.
2022-07-11 08:36:36 <KipIngram   > Anyway, yeah - if you're down to 417 bytes then I imagine soeone could get a real "bootstrapable" design in a sector.  It's a nice idea.
2022-07-11 08:36:59 <KipIngram   > but wow - actually following through from there would be a heck of a lot of work.
2022-07-11 08:37:07 <KipIngram   > You'd literally have to create EVERYTHING.
2022-07-11 08:38:03 <KipIngram   > But I really enjoyed those days, when the whole computer was right there at your fingertips, and you could diddle with the hardware without any muss or fuss.
2022-07-11 08:38:13 <KipIngram   > Everything's so carefully "walled away" these days.
2022-07-11 08:39:27 <KipIngram   > It might be fun to set some old PC up that way in the garage workshop and use it for controlling hardware I built, and things like that.
2022-07-11 08:39:34 <thrig       > leaky walls, what with the meltdown and what
2022-07-11 08:39:49 <KipIngram   > Yeah, no doubt.
2022-07-11 08:39:54 <KipIngram   > Sad thing.
2022-07-11 08:40:19 <KipIngram   > I think meltdown is a perfect example of getting bitten by complexity.  Hoist by our own petard.
2022-07-11 08:40:41 <KipIngram   > Everyone thought they'd done a good job - but there was just too much stuff in play to catch all the possibilities.
2022-07-11 08:40:55 <KipIngram   > When I read how meltdown and spectre "worked," I was pretty impressed with the hackers.
2022-07-11 08:41:02 <KipIngram   > It's a subtle thing.
2022-07-11 08:41:27 <eris[m]     > the fun thing is we keep discovering these kinds of things
2022-07-11 08:41:39 <KipIngram   > Well, it is fun in a way, isn't it?
2022-07-11 08:41:55 <eris[m]     > like, the spectre-type vulnerabilities seem to be an inherent design flaw
2022-07-11 08:41:59 <eris[m]     > because the fancy new arm chips get em too
2022-07-11 08:42:17 <eris[m]     > any chip with speculative execution seems to either have one, or will have one
2022-07-11 08:42:28 <KipIngram   > Yeah - the cache guys and the speculative execution guys just hadn't pow-wowed enough.
2022-07-11 08:42:54 <KipIngram   > The problem is that they didn't undo ALL of the effects of the speculative execution.
2022-07-11 08:43:21 <KipIngram   > They should have checked security on the instruction BEFORE speculatively executing it, but that must have been a lot harder.
2022-07-11 08:43:32 <eris[m]     > like, the m1 folks had years to design a workaround, right?
2022-07-11 08:43:38 <eris[m]     > redesign speculative execution
2022-07-11 08:43:39 <KipIngram   > They figured so long as it was eventually invalidated, it was no problem.
2022-07-11 08:43:42 <KipIngram   > But it was.
2022-07-11 08:44:12 <KipIngram   > They were greedy for performance.
2022-07-11 08:44:25 <eris[m]     > exactly!
2022-07-11 08:44:27 <KipIngram   > "It'll get invalidated later - we don't have to worry about that here."
2022-07-11 08:44:29 <eris[m]     > and so we have pacman
2022-07-11 08:44:32 <KipIngram   > Ooops.
2022-07-11 08:45:22 <KipIngram   > I think I can grok the mindset that led them there.  I suspect someone felt very very clever at the time.
2022-07-11 08:46:31 <eris[m]     > (fyi, pacman is the name for the vulnerability that exploits speculative execution in the new apple chips)
2022-07-11 08:46:42 <KipIngram   > Ah.
2022-07-11 08:47:03 <eris[m]     > i call it 'spectre type'
2022-07-11 08:47:09 <eris[m]     > because fundamentally, it's the same type of thing
2022-07-11 08:47:15 <KipIngram   > yeah; makes sense.
2022-07-11 08:47:16 <eris[m]     > hmm, i wodner
2022-07-11 08:47:38 <eris[m]     > when are we going to see rowhammer in the wild?
2022-07-11 08:47:44 <KipIngram   > I can only assume that there must have been a noticeable performance penalty for checking security on those instructions sooner rather than alter.
2022-07-11 08:47:52 <KipIngram   > since it seems like everyone made the same call.
2022-07-11 08:48:23 <KipIngram   > Oh - that's fascinating.
2022-07-11 08:48:30 <KipIngram   > Just pulled up rowhammer on wikipedia.
2022-07-11 08:48:34 <KipIngram   > I hadn't heard of that one.
2022-07-11 08:48:48 <eris[m]     > one of my friends did a talk on rowhammer
2022-07-11 08:49:05 <KipIngram   > Wow - it truly just never ends.
2022-07-11 08:49:09 <eris[m]     > it appears to have disappeared from the internet
2022-07-11 08:49:22 <KipIngram   > There is a similar type of interaction in NAND flash used in data storage.
2022-07-11 08:49:25 <eris[m]     > but spectre is a consequence of cpu design
2022-07-11 08:49:29 <eris[m]     > and rowhammer of physics!
2022-07-11 08:49:30 <KipIngram   > Yes.
2022-07-11 08:50:05 <KipIngram   > You can't design physics out.
2022-07-11 08:50:28 <KipIngram   > Spectre could have, in theory, been avoided.
2022-07-11 08:55:14 <KipIngram   > Ok, that's the most interesting part of the morning so far; thanks for mentioning that.
2022-07-11 09:02:47 <KipIngram   > I wish that it was possible to more easily intersperse different kinds of execution models in Forth.  But since NEXT makes a presumption about the structure of what follows, there's really just no high performance way to hope back and forth between "models."  I'm talking about being able to have some stuff threaded, some stuff in code, some stuff in byte code, etc.
2022-07-11 09:03:16 <KipIngram   > You CAN do different things different ways, but by the time you've put the necessary transition wrappers in you've lost most of the benefit.
2022-07-11 09:35:53 <dlowe       > isn't the threading the transition wrapper?
2022-07-11 09:37:01 <dlowe       > at least in jonesFORTH, there's a pointer to the code that implements the word. For primitives, it points to the code block, and for everything else it points to the word interpreter
2022-07-11 09:37:15 <dlowe       > but it could point to different interpreters
2022-07-11 09:39:35 <dlowe       > random idea: a magic system consisting of side-channel attacks on our reality's simulation host.  Drumming for rowhammer attacks, for instance
2022-07-11 09:41:36 <thrig       > I don't think humans can drum that fast
2022-07-11 09:52:33 <dlowe       > may not need to if it hits the same row
2022-07-11 10:27:52 <KipIngram   > Yeah, that's exactly what the threading is.  But what I was getting at is that you can't very easily "change thread models" on the fly without some sort of extra layer, or else duplication of primitives.
2022-07-11 10:28:09 <KipIngram   > Because the bit of code at the end of the primitive expects a particular threading model for the next word.
2022-07-11 10:29:25 <KipIngram   > So if I wanted to switch, for example, from 32-bit cells to a chunk of byte code, there would have to be something in between, that you can get to with the 32-bit thread model, that then expects the next thing in the stream to be byte code.
2022-07-11 10:29:37 <KipIngram   > And at the end of the byte code you'd have to change back.
2022-07-11 10:30:10 <KipIngram   > Or, you could jam some machine code into a definition, just by having a primitive just before it that ends with "jmp <instruction pointer>'.
2022-07-11 10:30:40 <KipIngram   > And to get back you'd need something that re-loaded the instruction pointer to the right thing, using that kind of stuff we were discussing earlier.
2022-07-11 10:31:45 <KipIngram   > So if you wanted to do that it would need to look something like 'word word word inline code code code threaded word word word...
2022-07-11 10:32:17 <KipIngram   > So having to call those 'inline' and 'threaded' words would nix most of the benefits of an inline operation.
2022-07-11 10:32:29 <KipIngram   > May as well put that code in its own word and call it in the usual way.
2022-07-11 10:32:54 <KipIngram   > Whenever I've thought about tricky stuff like that, that's the usual answer: just do what you can already do.
2022-07-11 10:34:56 <KipIngram   > In a perfect world we could have some kind of Huffman encoded structure, where we used bytes for the really common operations and larger things for the more occasional ones.
2022-07-11 10:35:12 <KipIngram   > But there's a fair bit of overhead in setting that up, having to do with these transitions.
2022-07-11 10:35:57 <KipIngram   > Even if you're doing it in hardware it can still force you to a slower clock rate or something like that.
2022-07-11 10:36:48 <KipIngram   > You can make Forth work with just two levels of combinational logic between clock edges, but if you start trying to add tricks that stops being possible pretty quickly.
2022-07-11 10:39:45 <KipIngram   > The point being that yeah, hardware is faster, but ultimately it faces the same sort of issues that software does.
2022-07-11 10:40:01 <KipIngram   > complexity->time
2022-07-11 11:15:49 <dlowe       > most lisp compilers will use the low bits of a value as tags since pointers to objects are aligned to multiples of 8
2022-07-11 11:17:25 <dlowe       > so you could check for those bits as length indicators
2022-07-11 11:17:33 <dlowe       > that would be a rather extreme space optimization
2022-07-11 13:00:33 <KipIngram   > Yeah - that's often the smart place to put "bits."
2022-07-11 13:00:56 <KipIngram   > Two of my header status bits are in the low end; I'm four-byte aligned.
2022-07-11 13:01:03 <KipIngram   > Then there's one more in the MSB.
2022-07-11 13:01:40 <KipIngram   > That's in the field that tells me how far back the next header is.
2022-07-11 13:06:02 <KipIngram   > I used to have the MSB of the name length and the last byte of hte name set, to support traversing the name.  But eventually I re-arranged the header fields so that the name is last; no longer need to traverse the string.
2022-07-11 13:06:46 <KipIngram   > That was a very good change, because it meant that checking parsed words against names became an exact match process that I could do with rep cmpsb instead of a masked comparison.
2022-07-11 13:07:49 <KipIngram   > So I wrote a fast string compare primitive using that approach and leveraged it into FIND.
2022-07-11 19:04:08 <KipIngram   > Just picked up an interesting factoid in another channel.
2022-07-11 19:04:37 <KipIngram   > First use of computer generated graphics in a mainstream theater movie.  Anyone want to guess?
2022-07-11 19:05:14 <thrig       > sorry my targetting computer is offline
2022-07-11 19:06:09 <KipIngram   > I would never have gotten it - I wasn't even in the right era.
2022-07-11 19:07:07 <KipIngram   > 1958 - the opening credits of Vertigo (Hitchcock thriller).
2022-07-11 19:07:12 <KipIngram   > https://www.youtube.com/watch?v=SkLn8mamU78
2022-07-11 19:07:35 <KipIngram   > It was done with an analog computer that had been used for gunnery operations.
2022-07-11 19:07:53 <KipIngram   > Well, not the whole thing, but parts of it that show up during.
2022-07-11 19:14:52 <KipIngram   > Analog computers are pretty nifty.  I've always been intrigued by them.
2022-07-11 19:15:13 <KipIngram   > But... these days they really just offer no real advantage.
2022-07-11 19:15:24 <thrig       > I recall some discussion where someone was insisting they weren't computers
2022-07-11 19:15:35 <KipIngram   > I can see that argument.
2022-07-11 19:15:51 <KipIngram   > You don't really "program" them in the same sort of way.
2022-07-11 19:16:22 <KipIngram   > There might be some much better name.
2022-07-11 19:16:30 <thrig       > also you get 0.0 .. 1.0 (or whatever) and not 0,1
2022-07-11 19:16:40 <KipIngram   > Dynamic emulator?
2022-07-11 19:16:44 <KipIngram   > Well, that's the "analog" part.
2022-07-11 19:16:47 <thrig       > fuzzy results
2022-07-11 19:17:47 <thrig       > an analog computer did help with chaos math back in the late 70s/early 80s
2022-07-11 19:20:33 <KipIngram   > Yeah.
2022-07-11 19:21:03 <KipIngram   > You read the Gleick book?
2022-07-11 19:21:08 <KipIngram   > It's good.
2022-07-11 19:21:36 <KipIngram   > Good coverage of the history of that work.
2022-07-11 19:23:16 <thrig       > yeah that's where I found that reference
2022-07-11 22:59:48 <KipIngram   > Well, I have to say that just reading through sectorforth.asm made me feel warm and happy.
2022-07-11 23:00:17 <KipIngram   > So clean, so simple, so straightforward.
2022-07-11 23:00:28 <KipIngram   > The way things used to be - the good old stuff.
2022-07-11 23:21:13 <KipIngram   > I like how NEXT was defined near the middle of the sector to make it a short jump from as wide a range as possible.  :-)
2022-07-11 23:21:46 <thrig       > don't want a sudden expensive long jump
2022-07-11 23:22:17 <KipIngram   > I point a register at it and jmp <reg>
2022-07-11 23:23:31 <KipIngram   > And that register does double duty - it's also the pointer to the base address of the system.  When I load an instruction cell from a definition, it's an offset, so I add that register to it to get the address.
2022-07-11 23:23:50 <KipIngram   > So that means my NEXT is right at the bottom - first code in the system.
2022-07-11 23:24:14 <KipIngram   > thrig: I don't konw if you know my background on that.  This system was originally written on MacOS.
2022-07-11 23:24:33 <KipIngram   > The MAC executable format requires that sort of relocatability; it just won't let you do absolute addresses.
2022-07-11 23:24:49 <KipIngram   > When I shifted to Linux I didn't attempt to go remove that bit of inefficiency.
2022-07-11 23:24:55 <KipIngram   > Or haven't yet, at least,
2022-07-11 23:25:27 <KipIngram   > Eventually it'll be able to re-compile itself, and I can change from offsets to absolute addresses then if I want to.
2022-07-11 23:25:43 <KipIngram   > That would shave a couple of instructions out of NEXT and a couple out of docol.
2022-07-11 23:26:16 <thrig       > I recall Mac OS X not really following the system V ABI for amd64
2022-07-11 23:27:55 <KipIngram   > I'd have been unlikely to know; it's not as though I was familiar with that to start with.
2022-07-11 23:28:07 <KipIngram   > I just dug around until I figured out how to make it work on MacOS.
2022-07-11 23:28:43 <thrig       > andq $-16,%rsp # manually align stack because Apple does not follow System V ABI for AMD64
2022-07-11 23:30:03 <KipIngram   > Interesting.  I don't touch the stack pointer at all, or use it for anything other than a few register push/pops.  I do make some syscalls; I presume it's used then.
2022-07-11 23:30:07 <KipIngram   > But I just leave it alone.
2022-07-11 23:30:32 <KipIngram   > And my signal catching stuff had to poke around in the stack frame.
2022-07-11 23:31:19 <KipIngram   > My system catches divide by zero type errors and addressing errors - instead of segfaulting it just runs through the Forth error handling and returns to the interpreter.
2022-07-11 23:32:12 <KipIngram   > And I use a very expensive error recovery system, given that I'm on such a resource rich thing as a modern notebook.  Before I start interpreting each line from the keyboard, I make a snapshot of the entire system.
2022-07-11 23:32:20 <KipIngram   > If an error occurs while processing that line, I restore it.
2022-07-11 23:32:41 <KipIngram   > So on error I am guaranteed to be in exactly the state I was in before I typed the first character of the line that had the error.
2022-07-11 23:32:50 <KipIngram   > Same stack data, same everything.
2022-07-11 23:33:00 <remexre     > (how) does that do file descriptors and other non-memory state?
2022-07-11 23:33:25 <KipIngram   > Well, except for the disk buffers.  If they get changed then those changes stick.
2022-07-11 23:33:38 <KipIngram   > I don't do anything with the file system; I just have Forth blocks.
2022-07-11 23:34:54 <KipIngram   > The disk buffers aren't in the same RAM region as "the system."
2022-07-11 23:35:53 <KipIngram   > I eventually will have command history; I want it like this so that if I get an error on a line I can just "cursor up" to go back to that line in the history, fix the error, and hit Enter again.
2022-07-11 23:36:26 <KipIngram   > Obviously that means the command history won't be in "the system" either - I actually plan to cache it in disk buffers too.
2022-07-11 23:43:39 <KipIngram   > So if that line of code modified a disk buffer in some "incremental" way (added something to one of its fields), then that would be an issue - I wouldn't want to just repeat the line then.
2022-07-11 23:44:41 <imode       > KipIngram: https://github.com/nineties/planckforth
2022-07-11 23:46:00 <KipIngram   > Oh, that's kind of cute too.
2022-07-11 23:46:21 <imode       > more than cute.
2022-07-11 23:46:25 <imode       > https://github.com/nineties/planckforth/blob/main/bootstrap.fs
2022-07-11 23:47:15 <imode       > scrolling through it is like scrolling through the gradient of abstractions.
2022-07-11 23:48:05 <KipIngram   > Are there spaces in there?
2022-07-11 23:48:15 <imode       > yeah.
2022-07-11 23:48:17 <KipIngram   > Everything looks all packed together.  Maybe it's my font.
2022-07-11 23:48:38 <imode       > screenshot?
2022-07-11 23:49:30 <KipIngram   > https://imgur.com/a/ZYjesvZ
2022-07-11 23:49:56 <imode       > oh.
2022-07-11 23:50:07 <imode       > no, there's no spaces.
2022-07-11 23:50:13 <imode       > you have to.. build up to that.
2022-07-11 23:50:15 <KipIngram   > do you see what I'm talking about?
2022-07-11 23:50:30 <imode       > yeah, individual characters are commands.
2022-07-11 23:50:37 <KipIngram   > Ah.  I see.
2022-07-11 23:50:41 <KipIngram   > Ok, fair enough.
2022-07-11 23:51:01 <KipIngram   > So all that is moving the system forward.
2022-07-11 23:51:22 <imode       > yup.
2022-07-11 23:51:41 <KipIngram   > I like it.  I've thought a little about things like that, but never earnestly sat down to try it.
2022-07-11 23:51:49 <imode       > building up the system one command at a time, until it can parse complex definitions.
2022-07-11 23:51:53 <KipIngram   > "How little can you begin with?"
2022-07-11 23:51:54 <imode       > and you can write complex programs.
2022-07-11 23:52:01 <thrig       > thegreeksalsodidnotusespac
2022-07-11 23:52:02 <thrig       > !yawsihtetorwoslayehtdnase
2022-07-11 23:52:24 <imode       > lol.
2022-07-11 23:52:42 <thrig       > nobody uses boustrophedon byte order (thank goodness)
2022-07-11 23:52:54 <KipIngram   > I didn't think about it being quite that cryptic at the beginning.
2022-07-11 23:53:09 <KipIngram   > But probably if you're more tolerant of early cryptic you can start with less.
2022-07-11 23:53:37 <KipIngram   > And honestly, that's the sort of thing where if you built it yourself you  probably know EXACTLY what you're doing and feel comfortable with it.
2022-07-11 23:54:28 <thrig       > it's the LISP macro problem... what the hell is this language you've invented