An End to High Memory? | Hacker News Reader

An End to High Memory?

lwn.net

150 pointsTomte35 comments

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.

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.

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)

Yes, Mac OS 9 and earlier (pre Mac OS X) and OS-9 (that's the RTOS, not the Mac operating system) both used CR for line endings.

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.

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

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.

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

Spooled output was pretty obscure, though. For most purposes the BBC Micro and Archimedes used CR as the newline character.

LF CR was always wrong. On a real TTY, it often takes longer than one character time for the CR to execute. CR has to accelerate and decelerate an actual physical mass.

LF CR did surface briefly in the early days of PC’s, I can’t remember where, but before the days of “glass teletypes” you learned very quickly not to do that. Adding a couple of NULs to let the print head settle down was sometimes necessary if you really wanted clean print.

Why does it matter? I'm writing node...

BBEdit could handle all the line ending styles.

I ran into this with a CSV exported from the macOS version of MS Office (which broke things when importing it into SQLite so I could run queries on it). This was in 2019. So much for OS X switching to Unix-style line endings...

Oh I swear when I see some ^M on a diff I sigh loudly and ask what's the problem with some people.

And I mean, why are any code editors on Windows saving with ^M endings?!

> And I mean, why are any code editors on Windows saving with ^M endings?!

Because otherwise, when you open the file on Notepad, it shows up as a single long line (other text editors tend to be smarter and understand both kinds of line endings).

Notepad supports CR, LF, and CRLF now!

https://devblogs.microsoft.com/commandline/extended-eol-in-n...

IIRC, MS recently updated notepad to understand Unix line endings, although I'm not sure if it's live for most people.

https://devblogs.microsoft.com/commandline/extended-eol-in-n...

Why is it that they haven't been exposed to CR/LF? Is it just that modern IDE/Editors detect this automatically? Windows still uses CR plus LF no?

I feel like every now again I still open some file with ^M characters in it.

Any sane software will handle any combination by default. The only notable exception was Windows notepad which did not allow to use UNIX line endings. But I think it was fixed recently.

They may have been exposed to the characters, but not a physical typewriter or line printer "carriage".

Oh interesting, now I understand. Indeed it's actually rare to see a typewriter now let alone experience these two mechanical movements(the return and the line feed.) Cheers.

I wonder if younger people understand "I pawned my Smith Corona" from Warren Zevon's "Carmelita." Or tubes glowing in the dark.

https://m.youtube.com/watch?v=xeb0OI8wXN4

I noticed that a lot of "younger" developers working on software for Windows are unaware of the fact that nearly "everything" in plain old Win32 gets created as a Window: Buttons, Comboboxes, ListViews, etc. - they all rely on "CreateWindow" / "CreateWindowEx".

That's also true in X11.

> 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.

Yep. Never owned a typewriter and I never understood why CR/LF was a "newline" until I saw a youtube video showing the "CR" and "LF" of a typewriter. Then it all made sense.

Also, the fact that unix uses LF and windows uses CR/LF added to the confusion as well.

> Also, the fact that unix uses LF and windows uses CR/LF added to the confusion as well.

And old Macs used CR. And some very rare old OSes used LF/CR!

And then there's the practice on Unix of treating page feed as a scroll pause in pagers — I don't believe that I've seen that elsewhere.

So much for a standard code for information interchange! Don't even get me started about the file, group, record & unit (i.e., field) separators …

Form feeds are commonly used in emacs source code (and elisp in general) to separate sections. They’re easy to type once you know what’s going on: C-q C-l

In Unix it’s the job of the teletypewriter driver to translate LF into CRLF. I don’t know why things were this way. Maybe to make it easier to write Unix utilities in assembler. Maybe because it doesn’t make much sense for a program like cut to see a lone CR or LF if it wants CRLF to separate lines, so the problem is avoided by not tearing CR in any special way.

I have no idea if overtyping (ie a CR without a LF) was ever used but surely the terminal line replacement use of CR didn’t exist when Unix was created

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*?

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?

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.

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.

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.

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).

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

Reply on news.ycombinator.com