4 ms·
I actually connected on LinkedIn last year with Darek Mihocka, a guy who I last knew of 30-odd years ago. He'd made a Atari ST extension called (I think) Quick
by sofaofthedamned 8y ago
I actually connected on LinkedIn last year with Darek Mihocka, a guy who I last knew of 30-odd years ago.
He'd made a Atari ST extension called (I think) Quick ST. The ST had awfully slow text output due to many things such as the interleaved bitmaps and lack of hardware assist. His made it much faster. I wrote a competitor that was faster than his. A couple of month later he wrote a new version that obliterated mine.
I literally spent weeks trying to work out how he'd done it, went through the 68k reference manual, nothing.
Then one day it came to me in an actual dream - 12 year old me actually woke up and started typing. It was the 'move.p' instruction. From memory this instruction split a 16 bit word into 2 bytes but aligned on a word (16 bit) boundary. I added this and my code then beat his.
Bear in mind this was before the internet, so no to-and-fro with conversation, all I saw was what he did. It absolutely stood me in good stead for the rest of my career, each time now I see a programmer who writes something completely sloppy I ask them how it will scale. I really miss those days and wish somebody could bring this back for newer people to learn the basics.
- puzzle 8y agoI'm still proud of my shell sort implementation in 10 or 12 68K instructions. I was young, so it felt like a huge achievement. :-) That and helping a couple of demo coders shave an instruction or two from core loops. These days I yell at people because they build Docker images that take up several Gigabytes...
- sofaofthedamned 8y agoYeah. I've yelled at frontend devs recently cos their node.js webserver with hardly anything on it took 1.2GB. For one thing they've got 300MB of Material Design icons there, wtf?! I love that I don't have to use the vertical blank interval to do processing, but fuck me if we've not gone the other way, programming is lazy nowadays.
- Teknoman117 8y agoI really wish it wasn't so lazy these days. Computers getting faster shouldn't excuse to use less and less performant programming practices. But then from my experience in the field thus far this opinion seems to be in the minority.
- eludwig 8y agoThere was also a great instuction called "movem.l" which moved multiple registers at once to almost anywhere (and vice-versa). It was used mainly to allocate stack frames, but could be creatively used to move stuff from place to place REAL fast.
- sofaofthedamned 8y agoYes! The worst thing about it is that it was at your fingertips the entire time - the reference manual was there and it was exact. The 68000 (not the 68020) didn't have cache so instruction timings were exact, so I had no excuse.
- Malic 8y agoJust to chime in with more 68k nostalgia and trivia: The 68000 didn't have cache - but 68010 did. Three whole instructions worth of cache. "Wha...?" you might say? Tha' heck good is that? The point was that the 3-instruction cache could cache tight loops, like the kind you would use for mem-to-mem copies, which is a terribly common thing to do. I put one in my Amiga 1000 (geez, did I hack that thing...) and got about a 10% overall system performance increase. It was neat! More lovely details here: http://www.memphisamigagroup.net/diskmags/198803/68010-kit/MC68010.ins?noconvert=1 http://www.memphisamigagroup.net/diskmags/198803/68010-kit/M...
- larsbrinkhoff 8y agoI remember it as just one instruction plus the jump. Checking up on this now, it looks like the "cache" (actually the IR register and the prefetch register) can only hold one 16-bit instruction and a DBxx instruction.
- Malic 8y agoOk, now that you mention it - that does sound correct. It was a long time ago... ;)
- kabdib 8y ago