10:36 <calle> I found some efforts of using picolisp on baremetal embeded system (cortex-m type) back from 2015, but the development seems to have stalled some time ago. Does anyone know the reason why?

10:38 <abu[m]> Hmm, not sure. Do you have any link on that?

10:45 <calle> https://picolisp.com/wiki/!getBlob?-A300 and https://picolisp.com/wiki/?embedded

10:51 <abu[m]> The MiniPicoLisp stuff is kind of finished, complete. And PilOS was a proof-of-concept, based on standard BIOS-calls which would require huge amounts of work to make it a full operartion system.

10:51 <abu[m]> Also, PilOS was based on the now obsolete pil64

10:52 <calle> BIOS calls, that is ancient!!

10:53 <calle> even for lisp time scales

10:53 <abu[m]> yeah :)

10:53 <abu[m]> But they still exist, though crippled on most hardware

10:53 <calle> yeah, that is okay

10:54 <calle> i would also expect a timing that emulates access to a 8bit wide and slow EPROM

10:55 <calle> non of that shadow-ram stuff ;-)

10:55 <abu[m]> You could try ;)

10:56 <calle> nah

10:56 <calle> i'd rather deal with uboot and the usual stack

10:56 <calle> maybe openfirmware

10:57 <abu[m]> More portable these days?

10:57 <calle> kinda, but is still almost always Soc or board-specific

10:58 <abu[m]> I would love to start something on mobile devices, but don't have any good docs

10:59 <abu[m]> BIOS was very well documented

10:59 <calle> you might look for chipsets with better documentation, maybe i.mx or zynq?

11:00 <abu[m]> Perhaps, but still very tedious

11:01 <abu[m]> It is easier to use PicoLisp in a more common environment like Linux or Android

11:01 <calle> the stuff targeted at industrial and small scale applications is usually way more open than mobile and high-end desktop and server SoCs

11:02 <calle> there are a lot of okay-ish RTOSes that take care of hardware-abstraction, scheduling, memory management and filesystems, but are still way less complex than linux and co.

11:03 <calle> e.g. RTEMS claims POSIX compatibility

11:04 <abu[m]> So why not use Linux directly?

11:04 <abu[m]> Or, as I do mostly, Android?

11:04 <calle> memory footprint and complexity

11:04 <abu[m]> true

11:05 <abu[m]> Depends on the purpose

11:05 <calle> android for embdded stuff? is that a real option? I would not have concidered it away from some human-machine interface

11:05 <abu[m]> ok, I was not thinking of embedded atm

11:06 <abu[m]> My main targets are business applications

11:07 <abu[m]> For real embedded miniPicoLisp is the only practical way currently, but I haven't looked it it since years

11:07 <calle> even a moderately minimal linux is about 10 MiB in 2022. the rtos fraction gets away with a few dozen to 500kiB

11:07 <abu[m]> MiniPil needs less

11:08 <abu[m]> 200 KiB ROM and 64 KiB RAM perhaps

11:08 <abu[m]> maybe ROM must be larger

11:08 <calle> sounds reasonable

11:09 <abu[m]> How is the state of Mizar? Haven't heard anything recently.

11:09 <calle> gone silent years ago

11:17 <calle> embedded feels stuck to me, c and c++ are still the way to go. which would be fine for low-level things, but not tha much for more abstrat things. there have been effort to use JS, pyhton, elang, forth, lisp/scheme, java and lua, but mostly nothing stuck. python seems to have won the popularity contest, but has no reasonable way to handle concurrency. So its c and c++ with some rtos or linux again, and maybe something ont

11:17 <calle> op of that (and of course just add enough silicon to run it).

11:18 <abu[m]> MiniPil also has no reasonable ways for concurrency

11:18 <calle> lambdaChip and the erlang approaches look like the most reasonalbe alternatives atm, but there is little to no community behind it.

11:21 <calle> I kinda like the way erlang went, it is good for multicore and distributed systems, and also provides the basis fo fault-tolerance and live-updates.

12:07 <calle> ahh, mizar32 was also an AVR32, that might have been one of the problems, that platform is not only dead but also forgotten now