
An End to High Memory? - Tomte
https://lwn.net/SubscriberLink/813201/a3b544ee8d802880/
======
wpietri
What a good writeup. It's fascinating to me how much of modern software can
only be understood in historical context. Some years back I had to explain
CR/LF issues to a young programmer who had never seen a carriage returning or
a line being fed. I imagine that's the majority of programmers now.

~~~
cs02rm0
Lucky them. My latest gig is helping out a project where some fresh faced Mac
and Windows devs have been writing nodejs and every other file used different
line endings.

Somehow they had no idea, git certainly did though.

~~~
gizmo686
I was working on a project where we were consuming a text document that Mac
style line endings. Apparantly, old Mac systems used just carriage returns.

Every developer knew this though, as no editor handled this out of the box.
(Vim has a simple setting to enable this, but for some reason it is not on by
default)

~~~
zaarn
Basically any combination of linefeed and carriage return may denote a new
line.

I've encountered some very old files using LFCR instead of the more modern
CRLF.

~~~
virgilp
I was curious and looked it up - according to Wikipedia, that happens on Acorn
BBC and RISC OS. I never encountered it, guess they were not popular enough :)

[https://en.wikipedia.org/wiki/Newline](https://en.wikipedia.org/wiki/Newline)

~~~
zaarn
I think some other machines used it too; a LFCR prevents the printhead from
moving over the already printed areas, thusly it prevents smearing of ink on
some very cheap printers due to freshly printed ink.

~~~
bch
It makes sense if you think of it in terms of a manual typewriter - the
carriage-return lever winds the platen (the line feed), and if you keep
pushing the lever, you return the carriage to the beginning.

[https://en.wikipedia.org/wiki/Typewriter#Standardization](https://en.wikipedia.org/wiki/Typewriter#Standardization)

------
qlk1123
It's a shocking news to me because my team has just finished the High Memory
support in RISC-V 32bit.

Even for young architecture such as RISC-V, it is obvious that 64 bit
dominates. But rv64gc is much larger than rv32gc in terms of gate count. Maybe
it will be a battle between not-yet-exist rv64e and rv32*?

~~~
rwallace
I'm surprised RISC-V has significantly larger gate count for 64 than 32 bit; I
thought the extra gate count for 64 bits was negligible from around the time
when the Nintendo 64 used a 64-bit CPU because it was cheaper to keep it as it
was than redo the layout to cut it down to 32 bits. Why is it significant for
RISC-V? What numbers of gates are we talking about exactly?

~~~
brandmeyer
Amortized against L2 cache, MMU, SIMD floating-point units, and Out-of-Order
engines, 64-bit integer ALUs and data paths are not a big change.

Many or all of those features are not present in the published design wins for
RISC-V.

------
watersb
_We 'll start by noting, for the oldest among our readers, that it has nothing
to do with the "high memory" concept found on early personal computers. That,
of course, was memory above the hardware-implemented hole at 640KB — memory
that was, according to a famous quote often attributed to Bill Gates, surplus
to the requirements of any reasonable user. The kernel's notion of high
memory, instead, is a software construct, not directly driven by the
hardware._

This is indeed a great write-up. Some old lessons I had forgotten:

Physical memory needs to be mapped by a kernel data structure. As typical DRAM
configurations grew, this map itself necessarily became large enough to limit
the 1GB dedicated to kernel on 32-bit systems. So a subset was directly
mapped, and the rest -- the "high memory" \-- was mapped by a secondary
structure.

If I'm reading this right.

------
de_watcher
Thankfully Ubuntu/Debian projects have started to support Raspberry Pi
directly. We can actually have prebuilt images of a standard x64 OS that is as
close to mainline as possible and doesn't have special cruft around it.

~~~
cesarb
We already have 64-bit Fedora for it (though it does not yet support the RPi
4; AFAIK, they're waiting for upstream kernel support).

~~~
jsight
Yeah, Fedora doesn't have a Pi 4 build yet. The funny thing about that is that
Centos does have one.

