Yes, me for one! I loved programming in x86 assembler in the good ol' days of DOS!
Seconded, although my programming tended to be COM, so I copied CS to the other segment registers and left 'em alone. But segments weren't that bad to deal with. I think the only major gotcha was if you tried to compare random address segment:offset pointers without normalizing them. But in ASM you had enough control to avoid such issues.
IMHO, As the x86 ISA expanded beyond the 8086 it got a whole lot harder to program directly. Page tables, multiple address & register modes, caches, pipelining and out-of-order instructions all made it much harder to both write ASM and actually get the performance benefit.
Well I did have a little fun programming in x86 asm when they finally got to 32 bits with the 386.
I was chuffed to find that even in 16 bit mode under DOS you could put a prefix in front of instructions to turn them from 16 bit ops to 32 bit ops (66H was it?)
From my perspective assembly language programming will never entirely disappear. There will always be instances where assembly is the only way to achieve the desired speed, size, control, timing, or access processor/hardware features which cannot be achieved via available high level languages. That being said, in almost all other cases programming in a high level language is preferred.
However, I do disagree with Robert Cravotta's hypothesis. Although vanilla C may lack the necessary means to control the cache hierarchy, that doesn't mean a compiler couldn't be extended to include such a feature. Similar to the "register" keyword, which hints to the compiler that the variable should be (in the programmer's opinion) stored in a register, you could define a "cache_L1" keyword which would designate a data structure as one which should be kept in the level 1 cache in preference to other data, or a "no_cache" keyword which would prevent a data structure from being stored in cache. (Heck, I wouldn't be surprised if the Intel compilers already have such features.)
I still use assembly language extensively for projects that need it. I even find ARM assembly both easy and fun (unlike others who have commented here), so I guess that makes me kind of weird.
My favorite small MCU to program in assembly is the MSP430 as its instruction set reminds me of the PDP-11 on which I first learned assembly programming back in the '70s.
Over the years I've programmed in assembly for the 8080, Z80, x86, 6502, 6809, PDP-11, VAX, 8x300, 68K, Z8000, ARM, MIPS, SH, MSP430, AVR, Propeller, and various custom bit-sliced architectures.
Over the years I've programmed in assembly for the 8080, Z80, x86, 6502, 6809, PDP-11, VAX, 8x300, 68K, Z8000, ARM, MIPS, SH, MSP430, AVR, Propeller, and various custom bit-sliced architectures.
Impressive list, but no 1802? You haven't lived yet!
Impressive list, but no 1802? You haven't lived yet!
Nope, no 1802. I still have a tube full of 1802's at home, but never got around to using them. I had a friend who had a full-blown rack mounted Cosmac development system, and he was a big fan, but never convinced me to give it a try.
Maybe if I ever design a control system for a satellite I'll dig them out of storage.
Well I did have a little fun programming in x86 asm when they finally got to 32 bits with the 386.
I disliked the 386/IA32. Suddenly segments got even more difficult, you had to use a prefix to directly handle 16 bit values if you were in 32-bit PMODE and the Page tables were worse than for any other PMMU I ever programmed for. Though once you got the segments all set up for 32-bit, with a 4GB limit and a base of 0, things were fairly smooth after ORing CR0 with 0x00000001 to enable PMODE (so long as you left Paging disabled and had working drivers for all the HW you need as well as ISR for every possible interrupt [or if you were a true masochist set up v86 mode for HW access]).
The 386 was a mess, but it was only partly Intel's fault. Between legacy software and IBM ignoring some of their "reserved" interrupts and the way the 286 had been abused to switch it in and out of protected mode on the fly, Intel had to create something that was part horse, part donkey, part ocelot, and part goldfish. The prefixing thing was a total mess, with the prefix having opposite meanings depending on the PMODE. I spent some time reverse engineering an embedded 386SX device and was totally flummoxed until I got the right mode settings for the disassembler. (And to riff on another thread: You might be an old geek if you've figured out something from x86 object code that the original programmer couldn't figure out from the source.) I didn't see any wisdom in that at all. And by the time of the Pentium it seemed they were just throwing Smile at the remaining unused opcodes and hoping something would stick.
I have a COSMAC Super Elf bequeathed to me by the slightly older geek who built it from the kit back around 1982. (The bequeathment, not the build; that was more like 1976. In 1982 the original owner was deep into XENIX.) It still works, and since the original owner used a memory expansion card and I didn't get the original board RAM chips at some point I installed a 6116 2Kx8 RAM chip on the back of the circuit board point-wired it so that it still works. Then I had it framed. The shadow box like frame opens to reveal a power jack so it can still be used, not that I ever do. I have the Programmer's Guide to the 1802 still today and have read it several times, though I've only written very small programs. It's probably the second most elegant chip I can think of after the Propeller. It's too bad it was really too obsolete for real work by the time I started doing real systems; the 8048 pretty much stole its lunch money.
Comments
Seconded, although my programming tended to be COM, so I copied CS to the other segment registers and left 'em alone. But segments weren't that bad to deal with. I think the only major gotcha was if you tried to compare random address segment:offset pointers without normalizing them. But in ASM you had enough control to avoid such issues.
IMHO, As the x86 ISA expanded beyond the 8086 it got a whole lot harder to program directly. Page tables, multiple address & register modes, caches, pipelining and out-of-order instructions all made it much harder to both write ASM and actually get the performance benefit.
I was chuffed to find that even in 16 bit mode under DOS you could put a prefix in front of instructions to turn them from 16 bit ops to 32 bit ops (66H was it?)
However, I do disagree with Robert Cravotta's hypothesis. Although vanilla C may lack the necessary means to control the cache hierarchy, that doesn't mean a compiler couldn't be extended to include such a feature. Similar to the "register" keyword, which hints to the compiler that the variable should be (in the programmer's opinion) stored in a register, you could define a "cache_L1" keyword which would designate a data structure as one which should be kept in the level 1 cache in preference to other data, or a "no_cache" keyword which would prevent a data structure from being stored in cache. (Heck, I wouldn't be surprised if the Intel compilers already have such features.)
My favorite small MCU to program in assembly is the MSP430 as its instruction set reminds me of the PDP-11 on which I first learned assembly programming back in the '70s.
Over the years I've programmed in assembly for the 8080, Z80, x86, 6502, 6809, PDP-11, VAX, 8x300, 68K, Z8000, ARM, MIPS, SH, MSP430, AVR, Propeller, and various custom bit-sliced architectures.
Impressive list, but no 1802? You haven't lived yet!
C.W.
Nope, no 1802. I still have a tube full of 1802's at home, but never got around to using them. I had a friend who had a full-blown rack mounted Cosmac development system, and he was a big fan, but never convinced me to give it a try.
Maybe if I ever design a control system for a satellite I'll dig them out of storage.