Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ELKS: Linux for 16-bit Intel Processors

github.com

Post reply on HN
Print view View original

21–30 of 119 posts

Re: ELKS: Linux for 16-bit Intel Processors

#21

Post by seba_dos1 »

nijave wrote: post #11
forinti wrote: post #3

Wait, "ROM-based systems"? Were there such x86 micros and is this saying you could run Linux from ROM? That's super interesting.

Lots of embedded systems like routers run read only although maybe they're not technically ROM. Usually they mount the root filesystems read only and create some small ram disk/tempfs for logs. Persistent settings go to a small NVRAM area The root filesystem is only written to when you flash a new OS image

The context of ROM here is "can execute code without putting it in RAM" rather than "code is stored in a read-only memory".

Re: ELKS: Linux for 16-bit Intel Processors

#22

Post by ChocolateGod »

mixmastamyk wrote: post #19
IgorPartola wrote: post #17

I do wonder in today’s landscape of single board computers what the right bit width is. A 64-bit system with like 1-2GB or RAM doesn’t make a ton of sense since your program size and data structure size grows by quite a bit but you don’t need it to since you don’t get to have more than 4GB of RAM. On the other hand there you do have SBCs with 8-16GBs of RAM but that’s a far cry from needing full 64 bits. Would an opt…

Yes, this already happens. Address bus width is usually different from register width due to cost. I found this, old CPU's address bus only getting to 44 bits wide on Itanium. https://www.tech-faq.com/address-bus.html My newish AMD laptop: `grep 'address sizes' /proc/cpuinfo` address sizes : 48 bits physical, 48 bits virtual Looks like 36 bits wide is already plenty for anything typical, up to 68 GB: >>> f'{2**32:>30…

I guess no point wasting hardware supporting things that will never be possible for the lifetime of the processor.

Re: ELKS: Linux for 16-bit Intel Processors

#24

Post by vardump »

IgorPartola wrote: post #17

I do wonder in today’s landscape of single board computers what the right bit width is. A 64-bit system with like 1-2GB or RAM doesn’t make a ton of sense since your program size and data structure size grows by quite a bit but you don’t need it to since you don’t get to have more than 4GB of RAM. On the other hand there you do have SBCs with 8-16GBs of RAM but that’s a far cry from needing full 64 bits. Would an opt…

32-bit ARM-based systems supported up to 1 TB of RAM. 32-bit x86 only up to 64 GB. Unless you want to map more than 4 GB in a single process, you could very well stay 32-bit.

But AArch64 (or ARM64) and AMD64 did bring a lot more on the table than just larger address space. More registers, and a performance boost by just being better suited for the modern CPU core design.

Re: ELKS: Linux for 16-bit Intel Processors

#25

Post by jagged-chisel »

tmzt wrote: post #23

Does anybody have the archive of the original ELKS site with the quote from Linus that Linux is not suitable for anything but 486 or higher or something like that?

How recent was the quote? Anywhere near 486 through Pentium, and the quote makes absolute sense. He wouldn’t have been optimizing for smaller architectures.

Since then, some (many?) contributors have supplied support for smaller systems.

Re: ELKS: Linux for 16-bit Intel Processors

#27

Post by pm215 »

garaetjjte wrote: post #26

I'm confused what relation this has with Linux.

The "getting started" doc briefly mentions the history: it began in 1995 as a fork of the standard Linux kernel (initially named Linux-8086), by Linux kernel developers Alan Cox and Chad Page. So it does share both code roots and some initial community with the "real" mainline Linux.

Re: ELKS: Linux for 16-bit Intel Processors

#28

Post by nh2 »

Could somebody with a good understanding of microchip production economics explain what the price difference would be if all 8-bit chips (such as the Atmega328) were replaced by otherwise equivalent 32-bit or 64-bit chops tomorrow (that is, same production capacity and unit counts sold)?

How much would it cost, in cents, to just have those extra bits?

Re: ELKS: Linux for 16-bit Intel Processors

#29

Post by tengwar2 »

fidotron wrote: post #15
forinti wrote: post #3

Wait, "ROM-based systems"? Were there such x86 micros and is this saying you could run Linux from ROM? That's super interesting.

Less obvious than some of the embedded things: https://en.m.wikipedia.org/wiki/Atari_Portfolio x86 (and licensed derivatives) were a thing in more custom handhelds like the Psion Series 3, and games systems like the Wonderswan. The variants made by NEC alone were: https://en.m.wikipedia.org/wiki/NEC_V20#Variants_and_success...

The Psions could do execute-in-place, including for third party software on ROM SSD - i.e. they did not have any fundamental distinction between working memory and disk storage.

Re: ELKS: Linux for 16-bit Intel Processors

#30

Post by ploxiln »

vardump wrote: post #24
IgorPartola wrote: post #17

I do wonder in today’s landscape of single board computers what the right bit width is. A 64-bit system with like 1-2GB or RAM doesn’t make a ton of sense since your program size and data structure size grows by quite a bit but you don’t need it to since you don’t get to have more than 4GB of RAM. On the other hand there you do have SBCs with 8-16GBs of RAM but that’s a far cry from needing full 64 bits. Would an opt…

32-bit ARM-based systems supported up to 1 TB of RAM. 32-bit x86 only up to 64 GB. Unless you want to map more than 4 GB in a single process, you could very well stay 32-bit. But AArch64 (or ARM64) and AMD64 did bring a lot more on the table than just larger address space. More registers, and a performance boost by just being better suited for the modern CPU core design.

32-bit x86 linux will typically support 3GB per process, with 1GB kernel address area, I think? (Windows did 2GB / 2GB split by default, custom boot options can change it to 3GB / 1GB, but only some 32-bit apps fully supported it, like photoshop).

Also, FWIW, security people can get real bothered that ASLR doesn't do much in 32-bit systems.

So, I think starting around 2GB DRAM, it's probably a "big enough" system to justify a 64-bit OS.

Post reply on HN