09:57:27
##forth
<veltas>
I wouldn't necessarily expect sleep to be in the default main loop for a Forth, because obviously that would impact performance, so it needs to be something you explicitly integrate. I'd hope that the low power states would be exposed via a nice interface or at least easy to add, for when you do add it, as for most applications it makes sense to add.
09:58:13
##forth
<veltas>
Well I guess maybe it would be in the interpreter loop if waiting a while for input?
09:58:32
##forth
<veltas>
But that also makes assumptions about what kind of code is on there
10:05:43
##forth
<tpbsd>
veltas, the STM32 sleep states can be very complex, a lot of expertise is needed in my experience
10:06:29
##forth
<tpbsd>
veltas, but Im comparing it to the MSP430 sleep states which are well integrated and easy to use in comparison to STM32
10:07:28
##forth
<tpbsd>
veltas, STM seem to just throw in all the peripherals they can get and leave the designer to sort it out ... TI by comparison design all their peripherals to be part of a well integrated suite
10:09:53
##forth
<tpbsd>
veltas, for instance, my favorite STM32 is the STM32F051 (now obsolite), it's a cortex-m0 and Ive never mastered the sleep state in that the minimum sleep with a interrupt to run I can get (that doesnt require a restart) is 3ma at 3.3v, which is terrible
10:11:02
##forth
<tpbsd>
and the problem needing a restart is that it's slow, and the usart will miss data, unlike a MSP430 which only takes microseconds to restart
10:59:12
##forth
<veltas>
Well sounds like a good reason for the mecrisp not to do this by default then
10:59:24
##forth
<veltas>
But it's there if you want to figure it out
11:03:24
##forth
<tpbsd>
veltas, absolutely, and Im sure the sleep power with a STM32H7xx series will be very low, it will just take a while to get it right with any OS, even Mecrisp-Stellaris on that SWISS calculator model
17:17:19
##forth
<crc>
I have a working amd64 ilo-uefi now. It's slow for i/o, but is working under qemu.
17:23:07
##forth
<KipIngram>
Very nice.
17:24:31
##forth
<veltas>
I think generally the UEFI I/O stuff is slow, I would guess that's not your fault
17:24:41
##forth
<veltas>
Also nice
17:34:48
##forth
<KipIngram>
Yeah, I'd expect that stuff to be written to be "rabidly portable."
17:35:11
##forth
<KipIngram>
That is, that would be the highest priority, before all else.
17:35:31
##forth
<KipIngram>
And that seems appropriate, given that it's not really meant to be anything other than a bootstrap.
17:38:19
##forth
<crc>
I think it'll be a little better if I switch the disk code to use BlockIO instead of DiskIO and fix some alignment stuff
18:14:57
##forth
<crc>
Using UEFI's BlockIO is a little faster. Startup is slow because of this (the default startup reads through a lot of blocks), but it's not too bad once it's fully loaded
18:19:14
##forth
<KipIngram>
That's a shame - I was hoping that one payoff of tossing the OS would be a faster startup. I think the time it takes modern computers to start is practically criminal.
18:19:43
##forth
<KipIngram>
No real excuse for it, given how much faster the processors are compared to the old days.
18:55:48
##forth
<crc>
There's probably more I can do on the performance. I've really only just started on this (my prior os dev work was all 16 & 32 bit)
18:56:51
##forth
<crc>
Using BlockIO, it's very similar in startup time to the polling i/o ata driver I had with ilo-x86-native
19:01:47
##forth
<vdupras_>
Are you sure it's BlockIO? I also use BlockIO for Dusk's EFI port (both amd64 and i386) and use it in a very dumb one-at-a-time manner and boot is pretty much instant, even though I need to go through a few dozens blocks.
19:11:03
##forth
<crc>
yes. The DiskIO code was considerably slower
19:14:41
##forth
<crc>
I'm going to see if caching blocks in RAM during startup will help
19:15:24
##forth
<crc>
(my startup code reads through the blocks a few times, loading different things, which doesn't help)
20:07:32
##forth
<KipIngram>
I figure with all the RAM I have on notebooks these days (the one I have right now has 32 GB), most of what I want to do won't need much disk back and forth. Just pull stuff in once and use it in RAM for the most part.
20:07:52
##forth
<KipIngram>
32 GB is... a lot of storage.
20:16:50
##forth
<crc>
Caching my active block set (4,096 blocks, 16MiB of data) in RAM on startup makes it pretty comparable to running under a host OS now.