Why Some Old Computers Are Interesting(hccc.org.uk)
hccc.org.uk
Why Some Old Computers Are Interesting
http://hccc.org.uk/retro/retro.html
73 comments
> My understanding is that managing heat is >still< the ultimate factor limiting performance
It seems fitting that I'm hearing the fans spin up to full blast on my ThinkPad X1 Extreme laptop supercomputer as I compile some code in an Ubuntu VM while starting up a CPU-hungry Point Of Sale system in a Windows VM, and reading your comment on the Windows host OS.
It is nice that I can step away from the computer and just listen for the fans to quiet down again to tell when everything is ready to go.
It seems fitting that I'm hearing the fans spin up to full blast on my ThinkPad X1 Extreme laptop supercomputer as I compile some code in an Ubuntu VM while starting up a CPU-hungry Point Of Sale system in a Windows VM, and reading your comment on the Windows host OS.
It is nice that I can step away from the computer and just listen for the fans to quiet down again to tell when everything is ready to go.
Are you monitoring temperatures on it?
Not specifically, but the top of the keyboard does get warm when all this is going on. Do you or anyone have any recommendations for temperature monitoring software for a ThinkPad running Windows with various other OSes in VMs?
In any case I think the POS software may be the main culprit, as it normally runs on a standalone machine and wasn't designed for power savings. I did set the Windows VM it runs in to "Power saver" but it doesn't seem to have helped much.
(Sorry if this is off topic for the thread!)
In any case I think the POS software may be the main culprit, as it normally runs on a standalone machine and wasn't designed for power savings. I did set the Windows VM it runs in to "Power saver" but it doesn't seem to have helped much.
(Sorry if this is off topic for the thread!)
SpeedFan? https://almico.com/speedfan.php
Have you activated VT-x VT-d etc in the bios?
If not prepare for a performance boost, and a quiet Fan ;)
If not prepare for a performance boost, and a quiet Fan ;)
Thanks for the tip. Yeah, "Intel Virtualization Technology" and "Intel VT-d Feature" are both enabled by default in the BIOS (in fact it doesn't let you turn them off).
Ah ok, i have seen some bios's where both are deactivated plus hyper-threading too :)
NotebookFanControl is the only one that works on newer machines in my experience.
https://github.com/hirschmann/nbfc
I'm asking because I'm wondering how often it hits 99 degrees and throttles. And if it doesn't, I really need to take a closer look at it, because that would be incredible.
Dell and HP machines have this problem, 6 core Intel processors run slower than 4 core ones because the former always throttle (even though the TDP is supposedly the same).
If you want, you can use Throttlestop to set better controls/limits on clocks and power (and possibly undervolt it) for better performance, battery life and temperatures.
https://github.com/hirschmann/nbfc
I'm asking because I'm wondering how often it hits 99 degrees and throttles. And if it doesn't, I really need to take a closer look at it, because that would be incredible.
Dell and HP machines have this problem, 6 core Intel processors run slower than 4 core ones because the former always throttle (even though the TDP is supposedly the same).
If you want, you can use Throttlestop to set better controls/limits on clocks and power (and possibly undervolt it) for better performance, battery life and temperatures.
I'm using ArgusMonitor for this:
https://www.argusmonitor.com
I don't have a thinkpad, but I like OpenHardwareMonitor for my computers: https://openhardwaremonitor.org/
Well, at least it's Thinkpad X1E...
We had much less going on when we joked that you know who is compiling or running any sort of serious work in the office by hearing whose MBP was whining hard with its fans.
We had much less going on when we joked that you know who is compiling or running any sort of serious work in the office by hearing whose MBP was whining hard with its fans.
Ah yes, these fans may get loud, but they are nothing like an office back in the day full of hackers on ASR-33 Teletypes!
Each one had a noisy keyboard and a noisy printer. The keyboard didn't have a nice click like a modern keyboard, more of a loud scrunchy sound. The printer was even louder and rang a bell if you had a line too long.
You could always tell when the mainframe crashed. Everyone's Teletype printer stopped all at once, and everyone started mashing down every key on their keyboard out of frustration.
Each one had a noisy keyboard and a noisy printer. The keyboard didn't have a nice click like a modern keyboard, more of a loud scrunchy sound. The printer was even louder and rang a bell if you had a line too long.
You could always tell when the mainframe crashed. Everyone's Teletype printer stopped all at once, and everyone started mashing down every key on their keyboard out of frustration.
Everything that is thin and light is going suffer from heat earlier than a bigger laptop.
Game laptops or workstation laptops are better solution(s) but the best is getting a desktop. I'm not joking and I'm aware of taking a device with you everywhere.
Game laptops or workstation laptops are better solution(s) but the best is getting a desktop. I'm not joking and I'm aware of taking a device with you everywhere.
> hardware that we would probably now consider to be inadequate for running a disk controller.
Wasn't the disk controller chip in the BBC Micro significantly more powerful than the main CPU? I think some games used it as a coprocessor.
Wasn't the disk controller chip in the BBC Micro significantly more powerful than the main CPU? I think some games used it as a coprocessor.
That's ludicrous. The 6502 is the best 8-bit processor that ever existed ;-)
Now, on a more serious tone, any processor in the machine you could detect could be used to offload some processing from the CPU. I wonder if that wasn't done with 1541 or 1571 Commodore floppy drives. I know there was software that wrote new functionality onto the drive's memory to make disk IO faster.
With enough memory, you could sort a text file and write the output to a new file without ever bothering the CPU. I don't think that was ever actually done, but the drives also ran 6502 processors, and the 1571 ran at twice the main computer's clock.
Now, on a more serious tone, any processor in the machine you could detect could be used to offload some processing from the CPU. I wonder if that wasn't done with 1541 or 1571 Commodore floppy drives. I know there was software that wrote new functionality onto the drive's memory to make disk IO faster.
With enough memory, you could sort a text file and write the output to a new file without ever bothering the CPU. I don't think that was ever actually done, but the drives also ran 6502 processors, and the 1571 ran at twice the main computer's clock.
On the C64/1541 you could definitely upload code to one or more of the 256-byte 1541 disk buffers and make the drive execute it. The problem is you have 3 pins to transmit your data and those are not connected to any communication facility like an ACIA - you have no choice but to involve the CPU in some bit banging there.
The 1571 used the burst mode of the CIA IIRC (also IIRC it wasn't done in the 1541 to be compatible with the VIC20) so there were more possibilities there.
The 1571 used the burst mode of the CIA IIRC (also IIRC it wasn't done in the 1541 to be compatible with the VIC20) so there were more possibilities there.
> The problem is you have 3 pins to transmit your data (...) you have no choice but to involve the CPU in some bit banging there.
Well... As long as the code takes longer to compute than it takes to push/pull the data, it's still a win.
I really can't think of any practical usage, of course. Maybe transforming ASCII files to EBCDIC ones without involving the CPU, or generating CRC32 values for the files on disk.
Well... As long as the code takes longer to compute than it takes to push/pull the data, it's still a win.
I really can't think of any practical usage, of course. Maybe transforming ASCII files to EBCDIC ones without involving the CPU, or generating CRC32 values for the files on disk.
Did not fast loaders for the drive put a small program on the disk drive?
They did, but the CPU still has to manually manipulate the ATN, DATA, and CLK pins.
There's no I/O controller, just two "Complex Interface Adapter" which each have 8 I/O ports, readable/writeable by the CPU using standard LDA/STA, etc. instructions. (The CIAs also have a timer and can generate IRQs).
IIRC 3 bits from CIA #2 can set/read each pin state. The CIA won't do anything to those on its own at all.
I think there were plans to use something like IEEE-488 or GPIB but scrapped due to cost.
So you can definitely write a program to implement a faster protocol than the one in the Kernal/1541 ROM (e.g use DATA and CLK as data lines and use ATN to sync, doubling transfer rate), but the CPU will still need to be 100% utilized in the (shorter) transmission.
There's no I/O controller, just two "Complex Interface Adapter" which each have 8 I/O ports, readable/writeable by the CPU using standard LDA/STA, etc. instructions. (The CIAs also have a timer and can generate IRQs).
IIRC 3 bits from CIA #2 can set/read each pin state. The CIA won't do anything to those on its own at all.
I think there were plans to use something like IEEE-488 or GPIB but scrapped due to cost.
So you can definitely write a program to implement a faster protocol than the one in the Kernal/1541 ROM (e.g use DATA and CLK as data lines and use ATN to sync, doubling transfer rate), but the CPU will still need to be 100% utilized in the (shorter) transmission.
One thing you could setup on the Commodore drives is file copying from on drive to another without it going thru the computer, they just talked to each other. You could also do the same thing if you had a straight text file and sent it to the printer (I am not sure which printer models) with again not using the computer after the handshaking was set up.
There's every chance I'm remembering it wrong - the double the clock speed certainly rings a bell. Got a weekly video call with a friend who still regularly hacks on a Beeb, so will try and clarify and update my comment tomorrow :)
The Beeb and the Ataris ran at 2 MHz. Apple II, VIC-20, C64, and 1541 all ran at 1 MHz. The 1571 ran at 2 MHz, same as the C128 (except when pretending to be a 64)
The 1571 was the drive meant for the C-128, which could also run at double speed (2 megahertz!) with the C-64 video chip disabled and the 80-column video running.
Most things are interesting simply due to the fact that they were produced by and through the constraints of their time. Seeing how people solved these contextual problems very often is fascinating. And then there's the spirit/aesthetics/goals of the era.
its why the demoscene is not what it used to be :)
What has always fascinated me about old hardware/software is the "what if" aspect.
Up until mid-90s, there was a real diversity of ideas and architectures in computing. 68K, PPC, x86, RISC, ARM, MIPS, i860, and I'm forgetting a lot of others. There were a lot of interesting ideas, some of which did become standard, while others died either for technical reasons (lack of adequate 3D capability on the Amiga) or because of business deals that didn't pan out (such as BeOS on Macintosh being dumped in favor of buying out NeXT).
Of course x86 seems standard and humdrum today, but it wasn't necessarily meant to be that way.
We could have been running BeOS on i860-based hardware, with MiniDiscs for removable storage, if things had panned out differently. And I find that fascinating to consider, when examining old computers.
Up until mid-90s, there was a real diversity of ideas and architectures in computing. 68K, PPC, x86, RISC, ARM, MIPS, i860, and I'm forgetting a lot of others. There were a lot of interesting ideas, some of which did become standard, while others died either for technical reasons (lack of adequate 3D capability on the Amiga) or because of business deals that didn't pan out (such as BeOS on Macintosh being dumped in favor of buying out NeXT).
Of course x86 seems standard and humdrum today, but it wasn't necessarily meant to be that way.
We could have been running BeOS on i860-based hardware, with MiniDiscs for removable storage, if things had panned out differently. And I find that fascinating to consider, when examining old computers.
> with MiniDiscs for removable storage
I wonder why that never amounted to anything. If I recall a few drives was made, but the cost just meant they where out of reach. The disc was just so cool, like take out of a sci-fi.
I wonder why that never amounted to anything. If I recall a few drives was made, but the cost just meant they where out of reach. The disc was just so cool, like take out of a sci-fi.
They were pretty popular in the EU circa 2004ish. A lot of people used them for MP3 storage.
I think what killed them was ultimately the iPod.
I think what killed them was ultimately the iPod.
Also around that era a usb drive of comparable size was available and pretty much worked with all computers for similar price points.
I actually have one family member that uses mini-discs. Mostly to listen to older stuff that she only have on mini-disc, but that's also an indication of how durable those things are. Getting new mini-discs plays is however getting extremely difficult, and expensive.
Minidiscs for music were very popular before MP3 players had reasonable storage space, at least here in Denmark and AFAIK in most of Europe, and obviously in Japan.
If you had to pick between an MP3 player with 32MB or maybe 64MB of fixed internal memory, or a Minidisc player where each disc could hold a full CD album and you could swap them as easily as a CD or a floppy disk, the choice was pretty clear, especially when you looked at it as a logical progression from a discman. The ATRAC codec is a mostly-OK lossy codec. Not full CD quality, but it was comparable to MP3 at the time.
(Minidiscs never supported MP3 until right at the end of Hi-MD, otherwise they were ATRAC and eventually CD-quality PCM only.)
The final iteration (Hi-MD) could hold 1GB of data or 94 minutes of full CD-quality uncompressed PCM audio, but that was too little and too late when it came out in 2004.
As for using Minidisc for data, that was a slightly different kettle of fish. The format was absolutely capable of doing it and the original discs could hold 140MB (increasing with later format revisions), which would have been absolutely groundbreaking in the early 90s. All of the technology was mature and proven and fully capable of displacing both the floppy disc and the CD. This was before the Zip disk, with higher storage capacity and actually reliable. The magneto-optical Minidisc could theoretically be rewritten millions of times, and sure each disc was a bit expensive initially, but they were super durable with a tough plastic shell, and 140MB of storage was more than a lot of people's home computers had at the time.
Unfortunately the record label arm of Sony were terrified of organized illegal copying and distribution, and because everyone was generally stuck in a mindset of seeing Minidisc as a cassette tape replacement rather than a general data storage format, it was stuck with real-time dubbing only (some devices with integrated CD and MD players offered high-speed dubbing, but it was still just dubbing, not data transfer). It didn't get data storage capability until the Hi-MD in 2004, which again was too little too late.
Combined with Sony's general insistence on keeping their formats proprietary and locked down (see Memory Stick, UMD, Betamax, DAT and so on), everything just conspired to not let the technical capabilities of Minidisc come to fruition.
There was an MD Data format, but it never really got off the ground. It used special incompatible MD Data discs, which were rare and expensive, plus the drives themselves were big, clunky and expensive.
Minidisc was legitimately a big hit for a while, for portable music. But it never quite displaced the CD and it never became the data storage format it could have been. And now we've got cheap flash memory, so even the idea of a magneto-optical disc seems a bit quaint and antiquated.
If you had to pick between an MP3 player with 32MB or maybe 64MB of fixed internal memory, or a Minidisc player where each disc could hold a full CD album and you could swap them as easily as a CD or a floppy disk, the choice was pretty clear, especially when you looked at it as a logical progression from a discman. The ATRAC codec is a mostly-OK lossy codec. Not full CD quality, but it was comparable to MP3 at the time.
(Minidiscs never supported MP3 until right at the end of Hi-MD, otherwise they were ATRAC and eventually CD-quality PCM only.)
The final iteration (Hi-MD) could hold 1GB of data or 94 minutes of full CD-quality uncompressed PCM audio, but that was too little and too late when it came out in 2004.
As for using Minidisc for data, that was a slightly different kettle of fish. The format was absolutely capable of doing it and the original discs could hold 140MB (increasing with later format revisions), which would have been absolutely groundbreaking in the early 90s. All of the technology was mature and proven and fully capable of displacing both the floppy disc and the CD. This was before the Zip disk, with higher storage capacity and actually reliable. The magneto-optical Minidisc could theoretically be rewritten millions of times, and sure each disc was a bit expensive initially, but they were super durable with a tough plastic shell, and 140MB of storage was more than a lot of people's home computers had at the time.
Unfortunately the record label arm of Sony were terrified of organized illegal copying and distribution, and because everyone was generally stuck in a mindset of seeing Minidisc as a cassette tape replacement rather than a general data storage format, it was stuck with real-time dubbing only (some devices with integrated CD and MD players offered high-speed dubbing, but it was still just dubbing, not data transfer). It didn't get data storage capability until the Hi-MD in 2004, which again was too little too late.
Combined with Sony's general insistence on keeping their formats proprietary and locked down (see Memory Stick, UMD, Betamax, DAT and so on), everything just conspired to not let the technical capabilities of Minidisc come to fruition.
There was an MD Data format, but it never really got off the ground. It used special incompatible MD Data discs, which were rare and expensive, plus the drives themselves were big, clunky and expensive.
Minidisc was legitimately a big hit for a while, for portable music. But it never quite displaced the CD and it never became the data storage format it could have been. And now we've got cheap flash memory, so even the idea of a magneto-optical disc seems a bit quaint and antiquated.
Even further back and you find that so many things we take for granted were just one of many options. Things I can think of offhand:
1. 8-bit bytes (7,6,9 were common) 2. Byte-level addressing (word addressing was common) 3. One's complement
1. 8-bit bytes (7,6,9 were common) 2. Byte-level addressing (word addressing was common) 3. One's complement
My favorite old computer is the Mark I perceptron, which was a neural network hardware computer (single layer) with light-sensitive visual receptors, weights controlled by self-turning potentiometers, and maually wired full connectivity: https://en.wikipedia.org/wiki/File:Mark_I_perceptron.jpeg
The university I went to had used Xerox Sigma 6/7/9s. One of them is now in the living computer museum. Yeah! After programming 6502 assembler in high school, having multiple blocks of 16 32-bit registers was breath-taking. My brain was wired to the 6502 X/Y/A thing so I doubt I ever used more than 5-6 of them at a time. After doing a lot of 8-bit micro and X86 assembly, doing ARM assembly for the first time felt similarly freeing.
I'll throw out a reference to the Burroughs "large systems" line: https://en.wikipedia.org/wiki/Burroughs_large_systems
These are the lineage of machines Knuth implemented his famous ALGOL-60 compiler on. There's a nice video about the B6500 that was discussed on HN years ago: https://news.ycombinator.com/item?id=7880027
I did some work adjacent to a UNISYS ClearPath "A Series" machine and later a PC-based version back in the early 2000s. Watching the operators and field service technicians working on it I got a feeling of a very mature environment. (Not necessarily fun to use by the look of it.) I got a bit of an IBM AS/400 feeling watching users interact with it in terminal emulation. For somebody with a Unix and MS-DOS background it just seemed odd.
After that contract was up I mostly forgot about it. I heard a talk where Alan Kay referred to some old Burroughs system. I got to reading about Burroughs and learned UNISYS was a successor. That led down a rabbit hole that ended up at these B5000-descended machines.
It looks like it was a well thought-out architecture that persists today (albeit in software, rather than hardware). The operating system, MCP, is still under development.
These are the lineage of machines Knuth implemented his famous ALGOL-60 compiler on. There's a nice video about the B6500 that was discussed on HN years ago: https://news.ycombinator.com/item?id=7880027
I did some work adjacent to a UNISYS ClearPath "A Series" machine and later a PC-based version back in the early 2000s. Watching the operators and field service technicians working on it I got a feeling of a very mature environment. (Not necessarily fun to use by the look of it.) I got a bit of an IBM AS/400 feeling watching users interact with it in terminal emulation. For somebody with a Unix and MS-DOS background it just seemed odd.
After that contract was up I mostly forgot about it. I heard a talk where Alan Kay referred to some old Burroughs system. I got to reading about Burroughs and learned UNISYS was a successor. That led down a rabbit hole that ended up at these B5000-descended machines.
It looks like it was a well thought-out architecture that persists today (albeit in software, rather than hardware). The operating system, MCP, is still under development.
> The operating system, MCP, is still under development.
MCP is, by far, the most user hostile OS I've ever seen. It's no surprise Bonnie McBird, who wrote Tron's screenplay and is Kay's wife, used it as the name of the villain.
MCP is, by far, the most user hostile OS I've ever seen. It's no surprise Bonnie McBird, who wrote Tron's screenplay and is Kay's wife, used it as the name of the villain.
Holy crap, I had no idea that the screenwriter for Tron was connected to Alan Kay. Thanks for that tidbit. Sounds like she became romantically connected to him after meeting him while researching the movie. Neat.
I'd love to see her original script before it got ruined. Sounds like her and Kay were pretty bitter about it.
https://web.archive.org/web/20030109182549/http://www.tron-s...
I'd love to see her original script before it got ruined. Sounds like her and Kay were pretty bitter about it.
https://web.archive.org/web/20030109182549/http://www.tron-s...
I’m not sure I’d like her take. I don’t like too much the movie either. I’d like the programs to be more alien, more funhouse mirror images of their creators, and be portrayed as AÍ semi-autonomous agents.
But that’d be a lot to demand on that age. They already had artificial life for their credits and that’s impressively prescient.
But that’d be a lot to demand on that age. They already had artificial life for their credits and that’s impressively prescient.
... That is officially awesome. End of line.
There were a few other possible tie-ins. The word TRON itself was a command in several MSFT Basic interpreters of the 8 bit era. It was short for TRACE ON and its companion for TRACE Off was TROFF. They shortened strings because space was limited in the 8K ROM.
Good times...
Good times...
Spell create with an 'e'. - Ken Thompson (referring to design regrets on the UNIX creat(2) system call and the fallacy of premature optimization)
... with respect for constrained environments, by way of contrast, via https://github.com/globalcitizen/taoup
... with respect for constrained environments, by way of contrast, via https://github.com/globalcitizen/taoup
I someone wants to test MVS-TK4- or VM370 here some resources:
UpToDate MVS distribution: http://wotho.ethz.ch/tk4-/
UpToDate vm370 distribution: http://vm370.org/VM/V1R1.1
390 Emulator: https://github.com/SDL-Hercules-390/hyperion
Best 3270-Terminal for windows: http://www.tombrennansoftware.com/download.html
3270-Terminal for *nix or Win: http://x3270.bgp.nu/
UpToDate MVS distribution: http://wotho.ethz.ch/tk4-/
UpToDate vm370 distribution: http://vm370.org/VM/V1R1.1
390 Emulator: https://github.com/SDL-Hercules-390/hyperion
Best 3270-Terminal for windows: http://www.tombrennansoftware.com/download.html
3270-Terminal for *nix or Win: http://x3270.bgp.nu/
I need to put up a new Docker image for my VM/370 thing at https://hub.docker.com/r/rbanffy/vm370.
I wonder if my 3270 font would work with Vista tn3270... It doesn't with x3270 :-(
I wonder if my 3270 font would work with Vista tn3270... It doesn't with x3270 :-(
> In fact, the operating systems that run on "old computers" are surprisingly sophisticated and complex.
Are they? Or are we just slowly forgetting that everything in modern software is composed of concepts invented pre-1980 (and in fact pre-1970 for the most part)?
It's called "Turing's Curse" [0]
To clarify, it's the "surprisingly" part that is not true. Certainly the software is sophisticated. What is surprising is how often we think our modern software is "sophisticated".
[0] https://www.youtube.com/watch?v=hVZxkFAIziA
EDIT: but, I guess we have done some modern cool stuff with GPUs, consensus algorithms including PoW, and a few cool ML model architectures and training techniques.
Are they? Or are we just slowly forgetting that everything in modern software is composed of concepts invented pre-1980 (and in fact pre-1970 for the most part)?
It's called "Turing's Curse" [0]
To clarify, it's the "surprisingly" part that is not true. Certainly the software is sophisticated. What is surprising is how often we think our modern software is "sophisticated".
[0] https://www.youtube.com/watch?v=hVZxkFAIziA
EDIT: but, I guess we have done some modern cool stuff with GPUs, consensus algorithms including PoW, and a few cool ML model architectures and training techniques.
I think there was a certian degree of bravery (or foolishness really) that authors of older software had WRT their willingness to couple with certain things (poking registers/DMA with specialized hardware, monkey patching OS components etc.)
We have a lot more layers of abstraction, in the name of productivity. That's certainly more complex, and from a certain point of view, more sophisticated.
Meanwhile (I can't be the only one who's noticed this?) it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent.
I'm not sure what to make of that.
Meanwhile (I can't be the only one who's noticed this?) it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent.
I'm not sure what to make of that.
> it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent.
While I can't attest to team performance, I wrote a toy compiler over the long weekend here just now. There were wizards who could do that 30 years ago in a weekend, of course.
But I'm not one of them. It occurred to me that if I hadn't used Haskell and some great libraries, built with a compiler that takes hundreds of MB of RAM to run, and was instead using C or assembly even, I'd probably still be trying to get integers parsing correctly.
The productivity increase of modern development tools seems real enough to me.
While I can't attest to team performance, I wrote a toy compiler over the long weekend here just now. There were wizards who could do that 30 years ago in a weekend, of course.
But I'm not one of them. It occurred to me that if I hadn't used Haskell and some great libraries, built with a compiler that takes hundreds of MB of RAM to run, and was instead using C or assembly even, I'd probably still be trying to get integers parsing correctly.
The productivity increase of modern development tools seems real enough to me.
I've written parsers in C, you get used to it. It would probably take you as long to write an integer parser in C as it would take me in Haskell.
It's literally two lines, yet it handles hexadecimal and octal too. :) Of course, if you set up some parser combinators with a nice library in C, it could be a one liner in C too.
I figure it's not the language, so much as the libraries and tooling around the language. Back in the day, one couldn't stick a term in the project definition, have the compiler automatically download and assemble a library, then invoke it with one line in the program code, all within 10 seconds. You'd have to start with "is this a digit?" and build up from there, like I did back in my CS courses with Pascal, once upon a time.
I figure it's not the language, so much as the libraries and tooling around the language. Back in the day, one couldn't stick a term in the project definition, have the compiler automatically download and assemble a library, then invoke it with one line in the program code, all within 10 seconds. You'd have to start with "is this a digit?" and build up from there, like I did back in my CS courses with Pascal, once upon a time.
What I like about old computers: creative solutions. These machines were severely limited by today standards, so to do anything useful, interesting workarounds had to be developed.
In the home-computer field, for example, using off-the-shelf cassette tape as storage, compiling code in multiple passes with persistence, simpler byte-code interpreting to increase code density, memory bank switching and other techniques are part of the charm of using that hardware.
Also, it is usually impressive to watch anything useful and quickly being done by constrained hardware.
In the home-computer field, for example, using off-the-shelf cassette tape as storage, compiling code in multiple passes with persistence, simpler byte-code interpreting to increase code density, memory bank switching and other techniques are part of the charm of using that hardware.
Also, it is usually impressive to watch anything useful and quickly being done by constrained hardware.
> But the PP concept and the offloading of the OS from the main CPU is still a very interesting idea - and one which is unlikely to be explored in foreseeable future machines.
Interestingly, a lot of the system services on macOS run on the power efficient but slow cores on the M1, keeping the beefy cores to user applications. I wonder if Linux can have an attribute for executables that indicate a preference of which kind or processor it should be preferably scheduled to.
Interestingly, a lot of the system services on macOS run on the power efficient but slow cores on the M1, keeping the beefy cores to user applications. I wonder if Linux can have an attribute for executables that indicate a preference of which kind or processor it should be preferably scheduled to.
Could always just sort processes to cores by nice value.
Can the kernel do it transparently on asymmetric core machines? Intel did show one some time ago and you can kind of manufacture cores with bigger caches and more execution ports by turning off SMT for them, turning an 8-core x86 into 8 "cores" with smaller cache and another 4 with twices as much L1.
I don't think you can be totally transparent; [1] if the cores are really asymmetric, there will likely be timing differences. But, you could certainly do things like if only the big cores support AVX, indicate AVX support to the program, and if it's running on the little core when it hits an AVX instruction, the kernel handles the invalid operation fault by rescheduling it to run on the large core.
If the program does a bunch of AVX once in a while, that can work well. If it's mostly AVX, and multithreaded, then you might likely spawn too many threads. If it's like one AVX instruction in each loop, that would also tend to be bad.
Balancing load would probably be a lot trickier than with SMP, but today's SMP is already tricky because frequency changes with the number of cores in use; it's not always optimum to run N threads on N cores anyway.
[1] and really, I think this meaning of transparent is really opaque; you don't want the program to know what core type it's running on.
If the program does a bunch of AVX once in a while, that can work well. If it's mostly AVX, and multithreaded, then you might likely spawn too many threads. If it's like one AVX instruction in each loop, that would also tend to be bad.
Balancing load would probably be a lot trickier than with SMP, but today's SMP is already tricky because frequency changes with the number of cores in use; it's not always optimum to run N threads on N cores anyway.
[1] and really, I think this meaning of transparent is really opaque; you don't want the program to know what core type it's running on.
I think the best way would be two different approaches. One, perhaps based on nice values or other priorities, that would push scheduling to the smaller cores and one, one-way, where some form of program metadata indicates which kind of core would be optimally suited to run it without the program having any awareness of it.
One thing I always notice on the CDC 6x00 family is that the vectors on screen are drawn so fast (to fit enough text on the high persistence phosphor before needing to redraw) that analog artifacts appear on the fonts themselves, giving them a whimsical, almost Comic Sans, look.
Funny to see the analog side isn't able to keep up with the digital hardware. That's peak Seymour Cray.
Funny to see the analog side isn't able to keep up with the digital hardware. That's peak Seymour Cray.
Ah IBM Stretch - first (only?) computer fixed by giving it an oil change .....
http://www.chilton-computing.org.uk/acl/literature/reports/p...
http://www.chilton-computing.org.uk/acl/literature/reports/p...
The college I went to had air cooled tape drives. For some reason one unit would get too hot and stop working.
Solution: Go behind it and flap the large access door a couple of times, and then it would start up and finish a compile. As you were waiting for the printouts it would keep cooling down and do the next job if it was not too long.
Solution: Go behind it and flap the large access door a couple of times, and then it would start up and finish a compile. As you were waiting for the printouts it would keep cooling down and do the next job if it was not too long.
Because the SGI cases or SUN pizza boxes are unforgettable. Now computer cases are just disgusting.
True. One of my favorites was the Cobalt Qube: https://en.wikipedia.org/wiki/Cobalt_Qube
I disagree with the following claim:
“With the exception of the Intel Itanium family, all of the architectural features that contribute to the performance of today's microprocessors first appeared (and were pretty fully explored) in a series of "mainframe" computers designed between the late 1950's and 1975.”
Here are just a few innovations hugely important to performance that came later: general out of order execution with precise exceptions, shared memory multiprocessor, memory disambiguation prediction, memory renaming.
Some of the innovations introduced during the described era were by no means “fully explored” either. For example, branch prediction advanced rapidly through the 80s and 90s, and the best branch prediction algorithm known today (TAGE) was developed in 2000s.
And, of course, architectural innovation continues to this day.
“With the exception of the Intel Itanium family, all of the architectural features that contribute to the performance of today's microprocessors first appeared (and were pretty fully explored) in a series of "mainframe" computers designed between the late 1950's and 1975.”
Here are just a few innovations hugely important to performance that came later: general out of order execution with precise exceptions, shared memory multiprocessor, memory disambiguation prediction, memory renaming.
Some of the innovations introduced during the described era were by no means “fully explored” either. For example, branch prediction advanced rapidly through the 80s and 90s, and the best branch prediction algorithm known today (TAGE) was developed in 2000s.
And, of course, architectural innovation continues to this day.
370 assembly language was interesting in so many ways. Applications were responsible for maintaining their own call stack and there were processor-level instructions for converting a number encoded in EBCDIC and converting it to a machine level int.
This is only just slightly related, but I am working on a project based on Algorand, and one of the interesting things about it is that the smart contracts are written in something somewhat like an assembly language. It actually is deliberately not Turing complete because it does not allow looping or recursion, but has a few interesting features and constraints.
For example, it has built-in cryptography instructions.
The need to execute as many "programs" as possible to have a high transaction rate has pushed the design towards these intriguing constraints.
For example, it has built-in cryptography instructions.
The need to execute as many "programs" as possible to have a high transaction rate has pushed the design towards these intriguing constraints.
So, I guess video and network cards are the two most common remaining components that could be called "peripheral processors"?
My interpretation of the ( frustratingly sparse ) documentation for the AWS Nitro hardware support seems to imply that it's pushed a bit more of the processing back out to the peripherals - which seems to buck the trend, but also seems highly effective.
For example, so far as I can tell, AWS's NVME drives have a lower latency from within a Nitro EC2 vm than a 905P Optane accessed from a KVM VM with PCIE passthrough on my play machine at home - although it's possible I've done something wrong with the setup!
My interpretation of the ( frustratingly sparse ) documentation for the AWS Nitro hardware support seems to imply that it's pushed a bit more of the processing back out to the peripherals - which seems to buck the trend, but also seems highly effective.
For example, so far as I can tell, AWS's NVME drives have a lower latency from within a Nitro EC2 vm than a 905P Optane accessed from a KVM VM with PCIE passthrough on my play machine at home - although it's possible I've done something wrong with the setup!
What is "interesting" obviously depends on the person. I always liked playing with old *nix workstations from the 90's. Something about tinkering on a box that would have cost over $50,000 new is interesting to me.
It's normally worth reviewing original work in a field for understanding and lessons.
Some current work inspired by the 6600 from all those decades ago is https://www.crowdsupply.com/libre-risc-v/m-class/updates/mod...
There were 4 of the then state-of-the-art, fastest in the world, CDC-7600 and CDC-6600 computers installed at Lawrence Livermore Lab (LLL, now LLNL, Lawrence Livermore National Lab) when I worked there during the summer of 1972.
Whenever people talk about old computers I need to mention the C64 that really laid the foundation for PCs today, new releases are coming every day: http://csdb.dk
In addition, visiting these old devices IRL is pretty instructive: one thing that always strikes me when I visit the Computer Sheds in Yorkshire (http://www.computermuseum.org.uk/ - an absolute gem BTW) is the enduring problem of thermal management. Up close, those old mainframes are basically huge air conditioning systems with some chips attached. My understanding is that managing heat is >still< the ultimate factor limiting performance (otherwise we could just stack up silicon in 3D)...