80's tech flashback

Also, where does Facebook's precompiled php for in with the works - anyone worked on a similar system?
 
I had a turbo switch that changed it from Mhz to Ghz... ;)

That was likely a 286 or above that had the turbo button. It was designed to allow it to run at 8086/8088 speeds for backward compatibility... it would have likely been one of the 6/8/12 Mhz varieties.
 
Last edited:
That was likely a 286 or above that had the turbo button. It was designed to allow it to run at 8086/8088 speeds.

That was a joke. :) I had a 4.77Mhz 8088, and then I later got one that had a turbo of up to 12Mhz. I missed the 286's completely, and went to 386 a bit later, then a 486DLC(40Mhz), then 486DX4 (100mhz), then a Pentium 2 (120mhz IIRC), then a bunch more where the details get fuzzy. It was amazing seeing how fast single threaded performance increased back then!
 
That was a joke. :) I had a 4.77Mhz 8088, and then I later got one that had a turbo of up to 12Mhz. I missed the 286's completely, and went to 386 a bit later, then a 486DLC(40Mhz), then 486DX4 (100mhz), then a Pentium 2 (120mhz IIRC), then a bunch more where the details get fuzzy. It was amazing seeing how fast single threaded performance increased back then!

At 12Mhz I doubt it was anything but the 286. I think the 8086 / 8088 went up to 10Mhz eventually... and the turbo button was on for default speed and off for compatibility mode.
 
Last edited:
At 12Mhz I doubt it was anything but the 286. I think the 8086 / 8088 went up to 10Mhz eventually... and the turbo button was on for default speed and off for compatibility mode.

It was definitely 12Mhz. I did some searching to see where these came from - apparently they are overclocked 10Mhz chips.

Quite an interesting read on this and other things:
https://sites.google.com/site/misterzeropage/
 
Last edited:
Interesting - was it bought like that / marketed like that? Seems it would have been a PITA for 2Mhz lol :D

That said, when 12Mhz is 20% more...

It was all about marketting. 286's and up were very expensive at the time, so that extra 2 MHz made it by far the best in the price range. That said, it did make the hardware somewhat unstable, which was a bit of a nerve - I had tons of issues with it (image corruption, peripherals not working, etc.)
 
It was all about marketting. 286's and up were very expensive at the time, so that extra 2 MHz made it by far the best in the price range. That said, it did make the hardware somewhat unstable, which was a bit of a nerve - I had tons of issues with it (image corruption, peripherals not working, etc.)

Had the same with my 286. Or rather I assume it was a 286 lol. My first machine had Hercules graphics though - crisper than CGA but horrible compatibility wise. We had to run phix to get most games to work.
 
Yeah, asm was pretty fun back in the day. I wrote a lot of line and other primitive renderers and tried to make them as fast as possible. I also studied the Intel hardware manuals quite a bit so I could get my bootloader to load up into 32bit protected mode.

They had a lot of little gems hidden in the docs.
 
Low latency networking, high throughput numerical code, key driver calls, etc. Usually when a compiler these days emits suboptimal code, it is not due to a bug, but because one has hit an edge case in the optimization heuristics, or the compiler does not have enough context (range of data, desired fast path, acceptability of side effects (speculatively changing memory), etc.). For the former, fixing the issue at hand in the compiler often results in a careful balancing act in order to not affect the performance of important benchmarks as a side effect of the fix - turnaround can take a long time, if ever (benchmarks are a priority to them, not my code). For the latter, it would be great if there were more ways to hint (strongly) to the compiler or constrain values, but it's not that effective yet (e.g., __builtin_expect() and pure/hot/cold attributes, etc.).
Sounds like edge cases; I certainly haven't experience many performance critical projects that hinge off asm code. An API search on GitHub also tends to supports this conclusion; hence my questioning of how many maintenance heavy codebases could really justify this; capable asm programmers are IMO few and far between.

As example; here are just two examples of a low latency high throughput networking projects:
Neither hinge anything on asm, and this certainly has never been AFAIK considered a performance bottleneck re they're key foundation of many of the highest performant / throughput server side frameworks. Another example is the Swift codebase: lexer, linter, semantic analysis, optimisation, stdlib, interops, ... nothing on which hinges off asm; and the same goes for Rust, and many others.

Naturally this of course doesn't discount in any way its value in some edge case applications (as you indicated).
 
Last edited:
Sigh 10mhz 286 and upgraded to a 386/33mhz and ran Dune2 and Doom....in mono vga.

Fooled around with basic/qbasic back then and learnt on turbo pascal/borland c later years. Also some PIC assembly late 90's.
 
[)roi(];21681771 said:
Sounds like edge cases; I certainly haven't experience many performance critical projects that hinge off asm code. An API search on GitHub also tends to supports this conclusion; hence my questioning of how many maintenance heavy codebases could really justify this; capable asm programmers are IMO few and far between.

As example; here are just two examples of a low latency high throughput networking projects:
Neither hinge anything on asm, and this certainly has never been AFAIK considered a performance bottleneck re they're key foundation of many of the highest performant / throughput server side frameworks. Another example is the Swift codebase: lexer, linter, semantic analysis, optimisation, stdlib, interops, ... nothing on which hinges off asm; and the same goes for Rust, and many others.

Naturally this of course doesn't discount in any way its value in some edge case applications (as you indicated).

For most users/applications it's not necessary to use ASM of course, hence this thread. For us, those networking libraries don't get close to what we need performance-wise. Even using something like Swift would be out of the question.
 
For most users/applications it's not necessary to use ASM of course, hence this thread. For us, those networking libraries don't get close to what we need performance-wise. Even using something like Swift would be out of the question.
Yeah I have my doubts on that; without specifics it's hard to imagine many scenarios that these non asm solutions are demonstratively inefficient to the extent that asm is the only solution.
 
[)roi(];21681771 said:
...capable asm programmers are IMO few and far between.

It's not hard but you need to know/understand the hardware. I don't think it's something that is taught much these days.


[)roi(];21682055 said:
Yeah I have my doubts on that; without specifics it's hard to imagine many scenarios that these non asm solutions are demonstratively inefficient to the extent that asm is the only solution.

In most scenarios you don't need it but it still has it's uses and it's fun!

https://en.wikipedia.org/wiki/Assembly_language#Current_usage
 
Last edited:
It's not hard but you need to know/understand the hardware. I don't think it's something that is taught much these days.
There's a reason for that, as you said in the majority of scenarios it's not only unnecessary, but also an inefficient mechanism for construction and maintenance.
Donald Knuth said:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

In most scenarios you don't need it but it still has it's uses and it's fun!

https://en.wikipedia.org/wiki/Assembly_language#Current_usage
The fun part I don't doubt; so too the edge cases where its justified, but day to day our time is better spent focusing on building code that is easy to test and maintain.
 
Top
Sign up to the MyBroadband newsletter
X