Rendered at 04:28:46 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
aseipp 2 hours ago [-]
Embedded Swift is honestly very cool. I never really used Swift itself before, but I think it's a good niche since embedded dev could stand for another tool and the language is pretty nice. It also doesn't really suffer from most of the issues people have historically brought up with Swift (cross platform, slow compiles) etc as it is so small, at least to me. :)
If you're starting from scratch I've found you can actually write ~everything in Swift quite easily (reset vectors, compiler emitted intrinsics, etc). But beyond that I think the best feature is that the C/C++ interop works really well and comes out of the box. Makes two-way adoption easy. I wrote a small boot firmware for a simulator and for fun decided to add signatures to the boot process (mldsa44+jq255). You can just copy the .c and .h files and import them into a modulemap file and you're off to the races. You can just get simple .o files and pass them to the linker. There are only 4-5 "freestanding" functions you have to implement. You can turn off heap allocation. Etc.
It would probably be pretty cool and quite easy for instance to write Zephyr or U-Boot drivers, etc in Swift using these techniques.
mannyv 1 hours ago [-]
Just pound values into registers! I love it, so old school!
In fact, that's how i/o worked before DMA on many systems. Good times!
sitzkrieg 35 minutes ago [-]
everything still works like this
monocasa 21 minutes ago [-]
Eh, most device interactions are mostly "build a command list and shared memory buffers" rather than the classic touch a a bunch of registers to perform the data plane work. UARTs are one of the last bastion of the old style, mostly because of how you want them so early in the boot process for debug out, it's nice to not have a shared memory/command list access pattern.
That being said, I've even seen it for UARTs on microcontrollers where they're hoping to not have FIFO block RAMs taking up area dedicated to UARTs that might not even be enabled. There you have a absoute minimal staging buffers in the UART, and a fairly reconfigurable DMA controller to allow you to use sharable main RAM instead.
Narishma 2 hours ago [-]
More of a hello world than a kernel.
qubex 2 days ago [-]
“machine emulators for hackers”
“Hack the Planet!”? “Mess with the best die like the rest”? WTF?
topham 4 hours ago [-]
Those are references to "Hackers" the movie from 1995.
monocasa 3 hours ago [-]
Missed the chance for a "RISC architecture is going to change everything" reference given that it's targeting aarch64.
If you're starting from scratch I've found you can actually write ~everything in Swift quite easily (reset vectors, compiler emitted intrinsics, etc). But beyond that I think the best feature is that the C/C++ interop works really well and comes out of the box. Makes two-way adoption easy. I wrote a small boot firmware for a simulator and for fun decided to add signatures to the boot process (mldsa44+jq255). You can just copy the .c and .h files and import them into a modulemap file and you're off to the races. You can just get simple .o files and pass them to the linker. There are only 4-5 "freestanding" functions you have to implement. You can turn off heap allocation. Etc.
It would probably be pretty cool and quite easy for instance to write Zephyr or U-Boot drivers, etc in Swift using these techniques.
In fact, that's how i/o worked before DMA on many systems. Good times!
That being said, I've even seen it for UARTs on microcontrollers where they're hoping to not have FIFO block RAMs taking up area dedicated to UARTs that might not even be enabled. There you have a absoute minimal staging buffers in the UART, and a fairly reconfigurable DMA controller to allow you to use sharable main RAM instead.
“Hack the Planet!”? “Mess with the best die like the rest”? WTF?