4 ms·

Seeing that their L4/Alpha implementation was written in PAL and C, it seems that they made L4 run as the Alpha firmware. For those not familiar with the DEC A

by KMag 11y ago

Seeing that their L4/Alpha implementation was written in PAL and C, it seems that they made L4 run as the Alpha firmware. For those not familiar with the DEC Alpha, it always ran what was basically a hypervisor/microkernel in firmware (called PAL code). The OS kernel would actually run in normal user mode and make upcalls to the PAL code, and the PAL code could emulate an arbitrary number of protection rings (two for Ultrix, several for VMS). VMS and Ultrix required different versions of the PAL code to be loaded, and Linux on Alpha used the Ultrix version of the firmware. It seems to me a shame that the DEC Alpha PAL code isn't the standard way firmware is done... ship a nanokernel/hypervisor and some basic drivers in ROM, and have some upcalls to replace drivers (or even the nanokernel/hypervisor). The DEC Alpha was a powerhouse in its day, and seems to have suffered very little from the PAL code abstraction.

gnufx 11y ago
> For those not familiar with the DEC Alpha, it always ran what was basically a hypervisor/microkernel in firmware (called PAL code). Gosh, I never realized, as a former Keeper of Alphas for scientific work, previously dependent on the GEC 4000 series <https://en.wikipedia.org/wiki/GEC_4000> https://en.wikipedia.org/wiki/GEC_4000> for physics. I wonder how it compared with OS4000 Nucleus. The 4000s made competing VAXen look a bit silly for our sort of data acquisition and analysis. Since they were pretty important for my publication record, it always amuses me to see microkernel-ish systems rejected out of hand. A colleague disproved the conventional wisdom that you needed a "spectrum database" to manage the data by just trusting the filesystem to manage directories. More recently I recall userspace filesystems being called generally toys (?), notwhithstanding huge, high performance PVFS2 installations, for instance. > The DEC Alpha was a powerhouse in its day Yes, and tragically under-appreciated in my sphere. I tried in vain to get the maintainer of the principal data reduction program in a different field to replace the bottleneck of the disk-based sort (written for a PDP-11). Each image would normally fit in cache and the whole dataset largely in memory, but that somehow wasn't relevant, contributing to "the computer is slow". (I think the sizes were 10MB and 1GB.)

by KMag 11y ago

gnufx 11y ago

> For those not familiar with the DEC Alpha, it always ran what was basically a hypervisor/microkernel in firmware (called PAL code). Gosh, I never realized, as a former Keeper of Alphas for scientific work, previously dependent on the GEC 4000 series <https://en.wikipedia.org/wiki/GEC_4000> https://en.wikipedia.org/wiki/GEC_4000> for physics. I wonder how it compared with OS4000 Nucleus. The 4000s made competing VAXen look a bit silly for our sort of data acquisition and analysis. Since they were pretty important for my publication record, it always amuses me to see microkernel-ish systems rejected out of hand. A colleague disproved the conventional wisdom that you needed a "spectrum database" to manage the data by just trusting the filesystem to manage directories. More recently I recall userspace filesystems being called generally toys (?), notwhithstanding huge, high performance PVFS2 installations, for instance. > The DEC Alpha was a powerhouse in its day Yes, and tragically under-appreciated in my sphere. I tried in vain to get the maintainer of the principal data reduction program in a different field to replace the bottleneck of the disk-based sort (written for a PDP-11). Each image would normally fit in cache and the whole dataset largely in memory, but that somehow wasn't relevant, contributing to "the computer is slow". (I think the sizes were 10MB and 1GB.)