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

31–40 of 119 posts

Re: ELKS: Linux for 16-bit Intel Processors

#31

Post by garaetjjte »

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.

>Unless you want to map more than 4 GB in a single process, you could very well stay 32-bit.

Provided you are not bothered by highmem. https://www.realworldtech.com/forum/?threadid=76912&curposti...

Re: ELKS: Linux for 16-bit Intel Processors

#32

Post by omeid2 »

nh2 wrote: post #28

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?

Supply-chains are more complicated than merely the unit price. Things like existing stock, talent, software, product design, certifications (both chip and products based on chip), and hundreds of other things play just as substantial role.

Re: ELKS: Linux for 16-bit Intel Processors

#33

Post by LeFantome »

nh2 wrote: post #28

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?

Probably more about ecosystem compatibility at this point. There are already RISC-V chips that sell for less than a 6502.

Re: ELKS: Linux for 16-bit Intel Processors

#34

Post by andix »

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…

I think it's either 8, 32 or 64 bit. Maybe 16 bit.

The size of memory space is not necessarily aligned with the bit width of the CPU. There are a lot of 32 bit systems that can use much more than 4 GB of RAM. And there are no 64 bit systems I know of, that are even theoretically able to use 16 exabytes (16 million TB) of RAM.

AFAIK ARM32 is still the norm for embedded systems. And there is still a place for 8-bit microcontrollers.

Re: ELKS: Linux for 16-bit Intel Processors

#35

Post by andix »

Dwedit wrote: post #9
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.

Some of the Tandy 1000 computers (such as the HX) had MS-DOS 2.11 in ROM. So it's not unheard of for an IBM-Compatible PC to have an operating system in ROM. Also the "Macintosh Classic" had System 6.0.3 in ROM as well, but you had to use a keyboard shortcut to boot from there. It did not run normally.

Are those real ROM-based-systems, that could execute code directly from ROM, without loading it to RAM first?

The only ROM-based-systems I worked with are the Atmel AVR microcontrollers. They don't need to load code into RAM for execution, they have the ROM memory mapped into the address space. I think they can't even run instructions from RAM, which makes remote code execution physically impossible.

Re: ELKS: Linux for 16-bit Intel Processors

#36

Post by p_l »

ChocolateGod wrote: post #22
mixmastamyk wrote: post #19

Earlier quoted context omitted.

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.

AMD64 mandates 48bit virtual addressing minimum, with the rest sign-extended unless certain optional features are enabled.

Re: ELKS: Linux for 16-bit Intel Processors

#37

Post by vkoskiv »

I recently added dual screen support to the ELKS console-direct driver, so if your system has both MDA and CGA cards, you enable CONFIG_CONSOLE_DUAL in your kernel config and select runlevel 5 in /bootopts, it will allocate 4 ttys, with one of them on the MDA display. You can see this setup running on my hardware in this pic in the README:

https://raw.githubusercontent.com/ghaerr/elks/refs/heads/mas...

I could use some help testing it on EGA and VGA hardware, as I don’t have any 8 bit cards for those in my collection.

Re: ELKS: Linux for 16-bit Intel Processors

#38

Post by Palomides »

nh2 wrote: post #28

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?

a cheap 32 bit RISC-V chip like the CH32V003 goes for about $0.10, and the cheapest MCU I've heard of (PMS150C, barely useful for anything) goes for around $0.03

there's little real point in 8 bit chips anymore

Re: ELKS: Linux for 16-bit Intel Processors

#40

Post by mepian »

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?

Linux started on the 386.

“It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.”

Post reply on HN