09:30:09
##forth
<veltas>
Start menu Windows 11 uses React Native? Honestly I'm more surprised the task bar isn't using it. I'm amazed there isn't a web browser instance per HWND.
14:36:02
##forth
<crc>
don't give them ideas...
15:24:07
##forth
<crc>
a small update on the ilo-amd64-uefi: I've implemented the multi session bits from the milo.c variation, so I can switch between 5 sessions (only the current is actually active, just as with milo.c), have fixed some bugs, improved detection of the blocks partition, and tested on a few more physical machines without any issues.
15:33:10
##forth
<veltas>
Awesome
15:33:24
##forth
<veltas>
What do you think of UEFI so far?
15:35:59
##forth
<veltas>
To me the whole thing feels like "please don't make me implement dynamic linking", if EFI had started a few years later I suspect they would have based it all on ELF and had dynamic linking
15:37:01
##forth
<veltas>
But in a weird way the structs-of-function-pointers inside structs-of-function-pointers approach seems to solve a lot of external namespace issues outright
15:37:50
##forth
<veltas>
And GUIDs galore
15:47:28
##forth
<vdupras>
I probably haven't gone as far as crc in my EFI Forth implementation (but still, I boot, I have storage, console, graphics, keyboard, mouse), but properly wrapped, UEFI is convenient to use. It's nice to have access to an API that covers such a wide range of hardware
15:48:18
##forth
<vdupras>
what I suspect is that UEFI implementations are nightmarish in complexity. I wouldn't want to see what's under that hood.
15:59:32
##forth
<KipIngram>
I'm looking really forward to getting mine far enough along to use, but that's a ways to go yet. I've barely started. I'm leaning really hard into the metacompile angle right from the start, so I'm moving slow and careful here.
16:13:40
##forth
<veltas>
vdupras: You might have gone further than crc already, if you've got graphics and mouse input
16:14:25
##forth
<veltas>
I think a lot of the UEFI firmware is based on open source stuff, the firmware writers just make essentially 'drivers' for that
16:14:44
##forth
<veltas>
I think a lot of the intel chipset 'drivers' are open source, you can see how they implement some of the core CPU features
16:15:15
##forth
<veltas>
UEFI isn't everything that your BIOS firmware does, and I suspect the UEFI drivers may be the better part of those codebases
16:16:13
##forth
<veltas>
As opposed to their ring -1 interrupts that run when the OS has booted doing only God knows what and try to hide their activity by rewriting the CPU timers
16:16:38
##forth
<crc>
I have limited graphics, but no mouse
16:16:56
##forth
<vdupras>
"already" happened a while ago, it's just that I stopped as soon as it was barely working
16:17:25
##forth
<vdupras>
it's not because it's open source that it can't have a nightmarish complexity :)
16:17:29
##forth
<veltas>
"I stopped as soon as it was barely working" story of all my projects :)
16:18:27
##forth
<vdupras>
"one day, I'll go back to it and polish it" is the lie we all tell ourselves
16:20:07
##forth
<crc>
I haven't ever tried to look at any uefi implementations
16:42:12
##forth
<
vdupras>
I hope it's not considered as spam, but I'd like to show off a 300 lines of code application designed to run on the TI-84+ today: https://git.sr.ht/~vdupras/hp16c-ti
16:45:14
##forth
<
vdupras>
When compared to something similar (but with a wider scope) like https://github.com/bxparks/rpn83p I think it shows well how Forth, doing its usual "cheating", can end up achieving a lot while taking a radically simpler path
17:05:01
##forth
<veltas>
That's on topic, no worries
17:08:01
##forth
<veltas>
Interesting code
17:47:57
##forth
<lmt>
changing the word size is like the main feature of hp16c
17:50:32
##forth
<lmt>
even rpn83p doesn't implement it, since it's not trying to emulate an hp16c. but the hp16c lets you set any word size from 1 to 64
17:54:05
##forth
<vdupras>
yeah, I agree that word size is important, but for the uses I have in mind for my own use, simply ignoring the left half (for 32-bit, for example) of the screen is sufficient
18:08:04
##forth
<vdupras>
lmt: I'm curious. Have you actually used a HP-16C? do you have a few examples of cases where usage of esoteric widths was important (as opposed, for example, to simply ignore the overflow shown on the screen)? Me, I can only think of rotation and conversion decimal representation.
18:53:16
##forth
<lmt>
I haven't used it, only read the manual
18:53:31
##forth
<lmt>
the intent is clearly to reproduce exactly what your hardware does which is why it also has three signedness modes
18:54:19
##forth
<lmt>
maybe you want the numbers to overflow. or are trying to reproduce something happening on the hardware
18:54:59
##forth
<lmt>
i agree it doesn't seem super useful but i'm not a hardware engineer circa 1982
18:57:04
##forth
<lmt>
there's probably some fancy code that does some operations quickly by relying on overflow
19:16:28
##forth
<KipIngram>
See the book "Hacker's Delight." It's just chock full of such interesting little tricks. One of my favorites is to divide (by a known fixed value) by multiplying instead, which is substantially faster.
20:50:56
##forth
<GreaseMonkey>
compilers usually optimise for that, except when it's GCC and you're compiling Thumb-1 code
20:51:37
##forth
<GreaseMonkey>
and when i say optimise i mean even with optimisations disabled
20:53:03
##forth
<GreaseMonkey>
but for Thumb-1 code, GCC would rather defer you to the software implementation of division, even though on every not-super-weird ARM CPU ever made that's actually slower than a multiply, even if you have the slow multiplier on a Cortex-M0/M0+
20:53:52
##forth
<GreaseMonkey>
thankfully a divide by a power of two gets optimised
22:01:42
##forth
<veltas>
GreaseMonkey: I've found on Z80 for instance it's faster to multiply with shifts than it is to do software divide for most fixed divisors
22:02:17
##forth
<veltas>
I'm guessing that's just lack of attention to the Thumb-1 code generation more than a conscious decision
22:07:42
##forth
<veltas>
I guess technically the fixed shift multiply method could be faster than a bad multiply