80's tech flashback

cguy

Executive Member
Joined
Jan 2, 2013
Messages
9,992
Reaction score
5,051
I spent the last two days writing x86 assembly code. Somewhere in the middle of this, I started to get this overwhelming feeling of deja vu - thinking back to writing optimized graphics code for my 80386 back in the 80's. I never would have imagined I would have been doing that in this day and age, so I embraced it, and coded to the beat of Kraftwerk and Joy Division. At the end I beat the compiler by ~2x. :). It was a good two days, but now I'm back in the real world.

What triggered your last flashback?
 
Last edited:
Heh. You are still spring chickens. I wrote assembly on a commodore VIC 20 first and then the C64 :-) (6502 / 6510)
Even wrote a couple of games and applications as well as a "pseudo basic" compiler. i've also written a full C64 Emulator and Disk Drive in Amiga Assembly :-)
 
hey be careful....i started programming on a 286!

Heh. You are still spring chickens. I wrote assembly on a commodore VIC 20 first and then the C64 :-) (6502 / 6510)
Even wrote a couple of games and applications as well as a "pseudo basic" compiler. i've also written a full C64 Emulator and Disk Drive in Amiga Assembly :-)

To give more colour on my timeline, I started writing assembler and C on the 386 around '88 or so, but I was writing Pascal code in '86 on an 8088, and Acorn Basic in '83 on an Acorn Electorn, and Logo in '81 on an Apple II.
 
What triggered your last flashback?

This thread triggered it. :)

To give more colour on my timeline, I started writing assembler and C on the 386 around '88 or so, but I was writing Pascal code in '86 on an 8088, and Acorn Basic in '83 on an Acorn Electorn, and Logo in '81 on an Apple II.

You are a bit older than I am, but I played around with assembler in the early 90s, because of graphics that needed to be faster on our 4.77MHz XT. mov ax,13h :) First inline assembly in Turbo Pascal, and a little masm. Never really went the route of full on asm coding. But it was fun spending days figuring out how demoscene guys made things so fast.
 
image.png
Ps for the millennials it's the era...before stackoverflow, ...before the Internet, ...
 
My flashbacks tends to always revolve around music more so than code; primarily because I'd prefer to burn the code I wrote in the 80s and 90s, in stark contrast with the music which I still love and still enjoy today.

My tastes even then were a little more eclectic than most (thanks to my parents), for example:

I even have fond memories whenever I hear this popular 70s track: https://www.youtube.com/watch?v=c3ouKAhxZbQ

As for coding; it was an interesting and challenging time; not having the Internet meant we tended to study manuals from cover to cover; whether that made us better programmers is open for debate.

We certainly could have progressed far faster with a little of stackoverflow and some Youtube videos; so count yourself lucky. Ps. if you were lucky you attended a few computer summer camps, and one or two computer science olympiads.
 
Last edited:
To give more colour on my timeline, I started writing assembler and C on the 386 around '88 or so, but I was writing Pascal code in '86 on an 8088, and Acorn Basic in '83 on an Acorn Electorn, and Logo in '81 on an Apple II.

I wasn't even born yet. :o

Also, racing compilers? NEERRRDD!!!!



:p :cool:
 
Last edited:
Did basic on a mates c64 followed by basic & assembler on apple, followed by assembler on amiga 680x0 with all it's custom chips. after school it was 8088, 8051 & PIC assembly, also some turbo pascal. Hated the Intel stuff and loved the 680x0 & pic stuff.
 
This thread triggered it. :)

You are a bit older than I am, but I played around with assembler in the early 90s, because of graphics that needed to be faster on our 4.77MHz XT. mov ax,13h :) First inline assembly in Turbo Pascal, and a little masm. Never really went the route of full on asm coding. But it was fun spending days figuring out how demoscene guys made things so fast.

You had VGA on a 4.77 ghz XT? I did too - one of the earliest ones. It took forever to just draw a frame over the 8 bit ISA bus.
 
I started with basic and soon after machine code on my C64 in the mid 1980's...still have the Commodore 64 Programmers Reference Guide somewhere!
 
Related question is what codebase can really justify maintaining these types of micro optimizations -- I read a lot of assembly code via the debugger and with work on LLDB, LLVM /& CLang, but I've never found a justifiable enough reason to resort to writing code directly in assembly; portability of code aside it's generally e.g, more valuable to just submit a bug report to the LLVM, ... teams re any compiler optimizations and other issues.
 
[)roi(];21672101 said:
Related question is what codebase can really justify maintaining these types of micro optimizations -- I read a lot of assembly code via the debugger and with work on LLDB, LLVM /& CLang, but I've never found a justifiable enough reason to resort to writing code directly in assembly; portability of code aside it's generally e.g, more valuable to just submit a bug report to the LLVM, ... teams re any compiler optimizations and other issues.

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.).
 
Last edited:
[)roi(];21672101 said:
Related question is what codebase can really justify maintaining these types of micro optimizations -- I read a lot of assembly code via the debugger and with work on LLDB, LLVM /& CLang, but I've never found a justifiable enough reason to resort to writing code directly in assembly; portability of code aside it's generally e.g, more valuable to just submit a bug report to the LLVM, ... teams re any compiler optimizations and other issues.

Anyone following webasm progress?
 
Top
Sign up to the MyBroadband newsletter
X