2023-07-23 00:24:22 <xelxebar    > Think I've hand-disassembled about half of SmithForth now. Kind of fun exercise.
2023-07-23 00:25:32 <xelxebar    > Was surprised to learn that flags in the segment descriptors on x86 affect operand size defaults.
2023-07-23 00:26:01 <KipIngram   > That does sound fun.
2023-07-23 00:29:30 <xelxebar    > You ever look at SmithForth in detail?
2023-07-23 00:30:36 <xelxebar    > The the 0x99 byte marker stuff is cute. It's a bit funky how the primitive dictionary lookup only matches on the name's first character, though.
2023-07-23 00:46:55 <xelxebar    > I'm a bit fuzzy on the exact operand-size semantics for some instructions, though.
2023-07-23 00:49:31 <xelxebar    > For example, `C7 rm/16 imm16` vs `C7 rm/32 imm32`.
2023-07-23 00:52:16 <xelxebar    > Which is a mov instruction, but the documentation doesn't say how C7 disambiguates chooses which operand size to look for.
2023-07-23 00:53:26 <xelxebar    > Like, the former would get encoded as bytes `C7 XX YY ZZ`, and the latter `C7 XX YY ZZ WW VV`.
2023-07-23 00:54:10 <xelxebar    > I'm guessing it's the D flag in CS, but the docs on the instruction don't mention this.
2023-07-23 00:56:24 <xelxebar    > I assume that REX.R let's you override whatever happens to be the default.
2023-07-23 00:58:14 <xelxebar    > Also, say we do `mov ax, 42`, does the immediate get sign-extended into eax/rax? I'm not sure what to expect if we did something like `mov [rdi], rax` immediately afterward.
2023-07-23 01:03:40 <xelxebar    > Oh, there it is. Volume 1, Section 3.6.
2023-07-23 01:49:11 <xelxebar    > More Intel Manualling answered my question. It looks like long-mode specs the D-flag of the CS descriptor to be 0.
2023-07-23 01:50:53 <xelxebar    > It also defaults to 32-bit immediates, which get sign-extended for 64-bit operands.
2023-07-23 01:52:00 <xelxebar    > Can use REX.W to allow specifying a 64-bit immediate.
2023-07-23 02:00:02 <xelxebar    > Oh! I see. So C7 defaults to `mov r/m32 imm32` in long mode, and we can get `mov r/m64 imm32` or `mov r/m64 imm64` by setting REX.R and REX.X prefixes.
2023-07-23 02:01:34 <xelxebar    > I wonder what `mov r/m32 imm64` would do. Probably just truncate? Doesn't look like any fault would happen.
2023-07-23 02:02:27 <xelxebar    > Okay, but I'm still unclear on how `mov eax, 42` followed by `mov [rdi], rax` would behave. Probably zero-extend the 42?
2023-07-23 02:14:42 <xelxebar    > And there it is. Volume 1, 3.4.1.1: 32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination GPR.
2023-07-23 02:16:01 <xelxebar    > Looks like the 8-bit operations don't touch the upper bits, unless it's intended to be used as a memory address, in which case it gets sign extended.
2023-07-23 02:19:49 <xelxebar    > And same for 16-bit operations like `mov ax, cx`, which need operand-size prefixes to override the default size.
2023-07-23 02:19:56 <xelxebar    > Okay. This is all starting to make sense now.
2023-07-23 02:59:02 <siesta      > hello guys
2023-07-23 02:59:38 <siesta      > does forth has a local variable? it looks like all is global?
2023-07-23 03:03:34 <siesta      > how about namespace?
2023-07-23 03:03:41 <siesta      > hmm
2023-07-23 03:07:26 <dave0       > there are local variables in the standard
2023-07-23 03:07:33 <dave0       > namespace is vocabularies
2023-07-23 03:17:11 <siesta      > what book can you refer?
2023-07-23 03:34:15 <dave0       > the classics seems to be "starting forth" and "thinking forth"
2023-07-23 03:35:22 <dave0       > https://www.forth.com/wp-content/uploads/2018/01/Starting-FORTH.pdf
2023-07-23 03:35:32 <dave0       > https://downloads.sourceforge.net/thinking-forth/thinking-forth-color.pdf
2023-07-23 03:39:55 <siesta      > thanks dave0
2023-07-23 03:43:07 <dave0       > no worries :-)
2023-07-23 03:58:30 <xelxebar    > Whoa. Local variables? Under what kind of scope?
2023-07-23 03:59:54 <siesta      > i think im not thinking in forth
2023-07-23 04:04:28 <xelxebar    > siesta: Have you looked at JonesForth? It's kind of mind blowing to see precisely how simple an implementation is.
2023-07-23 04:07:22 <siesta      > ive look at source of camel86
2023-07-23 04:07:50 <siesta      > its in DOS TASM
2023-07-23 04:08:11 <siesta      > i still use DOS
2023-07-23 04:08:56 <dave0       > i use DosBox on unix
2023-07-23 04:10:17 <siesta      > i use qemu on termux
2023-07-23 04:10:28 <dave0       > dos is quite nice if you want to write your forth in assembly
2023-07-23 04:11:13 <dave0       > assembler on, for example, linux is harder
2023-07-23 04:11:15 <siesta      > i want to add mode 13 graphics to camel86
2023-07-23 04:11:25 <dave0       > siesta: aaah! nice!
2023-07-23 04:14:00 <siesta      > but i guess i cant make turtle graphics using integer only
2023-07-23 04:14:46 <siesta      > i need float sin cos
2023-07-23 04:15:10 <dave0       > do you know of "fixed point" ?
2023-07-23 04:16:03 <siesta      > a little
2023-07-23 04:16:31 <dave0       > you can make a table of sin values
2023-07-23 04:17:25 <dave0       > forth can have floats but i've never tried that
2023-07-23 04:19:21 <xelxebar    > Wait. Really? What things make DOS assembler friendlier than Linux?
2023-07-23 04:19:54 <xelxebar    > I'm only familiar with the latter and would naively assume it's just a difference of syscall conventions.
2023-07-23 04:20:03 <dave0       > oh i mean it's easier to get a key on dos .. it's an interrupt
2023-07-23 04:20:09 <dave0       > yeah syscalls
2023-07-23 04:20:13 <dave0       > they are much easier on dos
2023-07-23 04:21:09 <xelxebar    > Ah, I see. Also everything runs in protected mode, right? No 64-bit DOSes?
2023-07-23 04:21:18 <dave0       > right
2023-07-23 04:21:29 <dave0       > graphics is so easy on dos
2023-07-23 04:21:35 <siesta      > got to go guys
2023-07-23 04:21:38 <siesta      > bye
2023-07-23 04:21:41 <dave0       > byes siesta
2023-07-23 04:21:49 <xelxebar    > 
ACTION waves

2023-07-23 04:22:16 <xelxebar    > Oh, I haven't even thought about graphics yet.
2023-07-23 04:24:38 <dave0       > to switch to graphics in dos it is      mov al,13h   int 10h     and then you can store bytes directly in ram   A0000h
2023-07-23 04:24:47 <dave0       > which is dead simple in forth
2023-07-23 04:25:00 <dave0       > hex FF A0000 c!
2023-07-23 04:25:17 <dave0       > to plot a pixel in graphics
2023-07-23 04:25:58 <dave0       > oh wait i think i got the command wrong...    mov ah,0   mov al,13h    int 10h
2023-07-23 04:26:19 <dave0       > if it was linux you'd have to go through x-windows
2023-07-23 04:26:30 <dave0       > of maybe use SDL
2023-07-23 04:32:41 <xelxebar    > That's cool. You literally just write bytes to memory.
2023-07-23 04:33:16 <dave0       > yup it couldn't be simpler
2023-07-23 06:47:28 <xelxebar    > dave0: By the way, what is c! ?
2023-07-23 07:23:44 <dave0       > store character
2023-07-23 07:23:58 <dave0       > character store
2023-07-23 07:24:14 <dave0       > ! writes a cell   c! writes a character
2023-07-23 07:24:30 <dave0       > on msdos a character is a byte, 8 bits
2023-07-23 07:24:55 <dave0       > depending on your forth, a cell in msdos could be 16 or 32 bits
2023-07-23 07:25:15 <dave0       > i'd be surprised if someone made a 64 bit forth for msdos but it might be possible!
2023-07-23 08:57:19 <KipIngram   > Isn't the processor in an entirely different "mode" while DOS is running?
2023-07-23 08:57:40 <KipIngram   > I'd think you'd have to change that, run your 64-bit code,  but then change it back before you went back to DOs.
2023-07-23 08:57:51 <KipIngram   > Chuck's OKAD system played some games along those lines.
2023-07-23 08:58:44 <KipIngram   > OKAD itself had no interface to the outside world - he had DOS programs that would load high RAM up with project content, and then save the results back off after he was done.
2023-07-23 09:04:40 <xelxebar    > Apparently the high half of register contents is guaranteed to be untouched when run in compatibility mode, so potentially you could run in real mode and run all the 32-bit DOS stuff in compatibility mode only.
2023-07-23 09:04:50 <KipIngram   > The main issue I'd have with a sub-64-bit x64 Forth would be the absence of an ample register supply.  I've wound up with enough things to do with registers that I'd find not having them painful.
2023-07-23 09:05:09 <KipIngram   > Yeah, that sounds reasonable.
2023-07-23 09:07:50 <xelxebar    > That said, if you're gonna run a forth, the going all-in and running something like DuskOS sounds way more fun.
2023-07-23 09:10:09 <xelxebar    > I'm somewhat bearish on how SmithForth goes with a maximally Spartan ELF format.
2023-07-23 09:10:36 <xelxebar    > Like, all the code and data sit together in the same block of pages with RWX enabled.
2023-07-23 09:12:02 <xelxebar    > And zero section headers makes the structure mostly invisible to things like objdump.
2023-07-23 09:49:18 <KipIngram   > I'm kind of jazzed about this little Maxim gadget I've ordered.  It looks like a very nice little "platform" that will offer all kinds of opportunities to play.  It's got all those built in things, all of which I'll eventually need to write code to support.
2023-07-23 09:49:44 <KipIngram   > And my goal is to write all of it - I don't want to use someone else's stuff to get at those functions.
2023-07-23 09:49:57 <KipIngram   > Including the Bluetooth stack.
2023-07-23 09:50:47 <KipIngram   > SD card interface, USB, etc.  But there's also stuff in there that I figure will be easier too - some low hanging fruit.  GPIO, analog to digital converters, etc.
2023-07-23 09:51:11 <Zarutian_iPad> what maxim thing?
2023-07-23 09:51:26 <KipIngram   > https://www.digikey.com/en/products/detail/analog-devices-inc-maxim-integrated/MAX32655FTHR/17885194
2023-07-23 09:51:35 <KipIngram   > https://www.analog.com/media/en/technical-documentation/data-sheets/MAX32655FTHR.pdf
2023-07-23 09:52:08 <KipIngram   > I need to look again, but I THINK I read something that implied it handles battery recharging whenever you've got it plugged into USB too.
2023-07-23 09:52:35 <KipIngram   > In addition to the opportunities for fun, it seems to have a collection of functionality that ought to cover controlling almost anything I might ever opt to build.
2023-07-23 09:53:06 <KipIngram   > And it's got two header rows on it, so it will be easy to mount it to a larger PCB or prototyping board that I use to make stuff.
2023-07-23 09:53:36 <KipIngram   > There was a Nordic part I kind of had my eye on, which is cheaper, but it is really small and is surface mount and would be a pain to get attached to larger systems.
2023-07-23 09:53:45 <KipIngram   > This thing just looks "drop right in."
2023-07-23 09:55:14 <KipIngram   > It's got the usual basic serial protocols, so I'll have a way of communicating with it even before I get the Bluetooth supported.
2023-07-23 09:55:38 <KipIngram   > Ultimately, though, I want a console app I can run on my notebook that will connect to it via Bluetooth.
2023-07-23 09:57:04 <KipIngram   > And if I have more than one of them sitting around doing various things, i want them to form up a mesh network with one another.
2023-07-23 10:02:13 <KipIngram   > Yes, there's a section in that last linked doc "PMIC and Battery Charger."  So it just seems to bring a whole wad of functionality to the table that would be useful in all kinds of projects.
2023-07-23 10:02:49 <KipIngram   > So, I want a Forth-based OS for it.
2023-07-23 10:03:42 <KipIngram   > And I guess I want that notebook app to be "the same" (as in compatible in some sense) Forth too.  I want to support having a distributed system of the things, all meshed together.
2023-07-23 10:04:04 <KipIngram   > Network up my whole "hobby space" that way.
2023-07-23 10:16:25 <xelxebar    > Dang. Thinking big!
2023-07-23 10:18:21 <xelxebar    > If you do happen to bring up an entire network and bluetooth stack, I know of some people that would love to see it.
2023-07-23 10:43:00 <KipIngram   > Well, it's a lot to do, but at least THINKING big is fun.  :-)
2023-07-23 10:46:39 <KipIngram   > First things first, though - just get code running on one of them talking to me over a serial link.
2023-07-23 10:47:12 <KipIngram   > I can pump source over that link every boot at first, while I work on bringing up the flash, SD card, and so on.
2023-07-23 10:48:00 <KipIngram   > The nice part of that, though, is that all of it will be sitting there exposed to me, without layers and layers of OS-ification in between.
2023-07-23 11:01:33 <veltas      > I will be more excited about code you're willing to share with us ;)
2023-07-23 11:04:56 <xelxebar    > KipIngram: You're aware of the DuskOS and CollapseOS projects, right?
2023-07-23 11:21:32 <MrMobius    > KipIngram: why that board and not raspberry pi pico for example?
2023-07-23 11:23:08 <MrMobius    > just curious
2023-07-23 11:24:20 <KipIngram   > xelxebar: Yes, I've seen those.
2023-07-23 11:24:43 <KipIngram   > MrMobius: Not sure - there was just something about this one I liked.
2023-07-23 11:25:04 <KipIngram   > Combination of functionality, form factor, price, and "I saw it."
2023-07-23 11:25:30 <xelxebar    > KipIngram: Have you looked into them much? I've got them cloned locally and pinned as something to look into. IIUC, they're spiritually in a similar direction that you're wanting to go.
2023-07-23 11:25:59 <KipIngram   > No, I've only read briefly about them.  I read about CollapseOS's editor and thought there were some interesting ideas there.
2023-07-23 11:26:16 <KipIngram   > But I haven't delved into their implementations.
2023-07-23 11:26:28 <KipIngram   > I usually don't - I usually concoct my own implementations these days.
2023-07-23 11:26:52 <KipIngram   > My "deep dive" into implementation was via the book "Forth Fundamentals v1" by McCabe.
2023-07-23 11:27:21 <KipIngram   > Reading that book for the first time blew my mind.
2023-07-23 11:27:47 <KipIngram   > I'd written a Forth at that point for 6809, and the book showed me how utterly I'd failed to come even close to how simple Forth can be.
2023-07-23 11:49:16 <xelxebar    > Haha. Now *that* does sound fun :D
2023-07-23 11:50:28 <thrig       > blah blah "nothing left to remove"
2023-07-23 11:51:55 <KipIngram   > Yes - that's what I'm chasing.  A system that does a certain amount of stuff, that's just as simple and minimal as I can make it.  Subject to it doing the necessary things, which does include some stuff that Forths don't usually do.
2023-07-23 11:53:01 <KipIngram   > But, most of that is basic OS stuff.  Memory management, process communication and so on.
2023-07-23 11:53:35 <KipIngram   > I want something that makes writing multi-thread apps "no muss, no fuss."
2023-07-23 11:54:20 <KipIngram   > veltas: I didn't miss your remark about sharing.  I don't mind sharing, but first I have to have something that meets my standards for being worth sharing.  "Half finished" doesn't.
2023-07-23 11:54:48 <KipIngram   > When I share I want to share a completed system.
2023-07-23 13:27:32 <veltas      > KipIngram: 50% > 0%
2023-07-23 13:28:19 <veltas      > That's my position. For instance zenv my ZX Spectrum Forth isn't 'done'. But it's usable for some things so it's out there, and if people care they can improve/fix it, and at least one person has done that
2023-07-23 13:42:42 <KipIngram   > Well, I've explained my reasons.  I don't work fast.  I think a lot before I implement things.  And if I post it half done and someone else runs out ahead of me with, that will annoy me.  I have to work the way others want me to at the office - this is mine to do exactly as I please.
2023-07-23 13:43:25 <KipIngram   > I know myself well enough to know that having someone else take what I've done and change wouldn't bug me, or at least not as much.
2023-07-23 13:56:42 <veltas      > Yeah we all want different things out of our leisure
2023-07-23 13:56:55 <veltas      > And out of our craft as well
2023-07-23 14:04:55 <MrMobius    > I think it's highly unlikely anyone would take what you make an extend it
2023-07-23 14:05:50 <MrMobius    > kind of the same thing when people come up with new app ideas and wont tell anyone their idea
2023-07-23 14:06:08 <MrMobius    > no one probably cares and if they do they arent going to dump the time into outdoing you
2023-07-23 14:06:54 <MrMobius    > ie, it's ok to relax and upload your stuff to github :P
2023-07-23 14:15:35 <DKordic     > : swap
2023-07-23 14:15:35 <DKordic     >   : A1  ToS ;
2023-07-23 14:18:28 <xelxebar    > DKordic: What's ToS?
2023-07-23 14:18:37 <DKordic     > I'm handvaweing...  It is flawed, sorry.
2023-07-23 14:18:54 <DKordic     > Top of Stack
2023-07-23 14:19:51 <xelxebar    > Oh, hah. I see. Assuming local scope exists, that's cute.
2023-07-23 14:20:53 <xelxebar    > I guess it'd work if ToS were immediate.
2023-07-23 14:20:56 <DKordic     > xelxebar: IMHO Forth is first of all a fine assembly.  Therefore, Frame Pointer should be an obvious option for Local Variables!  And as we know it could be optimized to 0 bits at runtime in common cases!
2023-07-23 14:23:21 <DKordic     > My idea is: First-Class Functions, therefore Higher-Order Functions, should be considered.
2023-07-23 14:26:00 <thrig       > I hear they are a Joy to use
2023-07-23 14:27:23 <DKordic     > I was disapointed in that ""Joy"".
2023-07-23 14:28:49 <DKordic     > ""dictionary"" can obviously be Forked.
2023-07-23 14:30:44 <DKordic     > siesta, xelxebar: ""Value""s in ""colon definition""s?  Shouldn't it be obvious?
2023-07-23 14:37:56 <DKordic     > siesta, xelxebar: Try this in Python: ""def swap(ret, a1, a2, *data, **context): return ret(a2, a1, *data, **context)""?!
2023-07-23 14:39:10 <DKordic     > Feels like assembly, doesn't it?!  ""R = [0] * 16""?!
2023-07-23 14:42:01 <DKordic     > I should create Py.PI.pointless.
2023-07-23 15:21:14 <xelxebar    > KipIngram: Speaking of simple. Register choice in SmithForth is really nice. It affords both compact instruction encoding as well as seamless syscall interop.
2023-07-23 16:32:36 <KipIngram   > What are the details there?  I know syscalls use a particular set of registers for their parameters.
2023-07-23 20:40:28 <xelxebar    > KipIngram: syscall(2) manpage, on x86-64 rax holds syscall number, then args go like rdi, rsi, rdx, r10, r8, r9.
2023-07-23 20:46:12 <xelxebar    > Input pointer sits in rsi, and output rdi, which allows for some fortunate overlap. stos lods using rax is an unavoidable impedance mismatch, though.
2023-07-23 20:48:30 <xelxebar    > So, naively, for like write(fd, buf, num), you'd expect to need to setup 4 registers before issuing syscall, but SmithForth gets away with just 2.
2023-07-23 20:49:02 <xelxebar    > Oh, and the syscall return value goes in rax.
2023-07-23 20:52:05 <thrig       > sysv abi, except where it isn't followed *cough* Apple *cough*
2023-07-23 20:52:18 <thrig       > though Apple is kinda getting out of AMD64istan
2023-07-23 23:46:34 <KipIngram   > I don't do very many syscalls, actually.  Not sure it happens frequently enough to worry too much about optimizing it.