Quote:
Originally Posted by Renate
In the last decade I have written numerical routines in assembler. Some things like 24 bit fixed point are not easily implemented in higher languages.
|
That's a good example, as is any fixed point arithmetic not using 8, 16, 32 or 64 bits on mainstream compilers/CPUs. I did a maths library for an NEC microcontroller that only had an add instruction. Complement to subtract, but division is to be avoided, so some constants stored a 1/x, But for 16F/18F PIC I used JAL to write my maths library as it was 8 & 16 bit.
Then used techniques from a PC graphics text book to turn floating point program to fixed point and use the Integer library I wrote with pretending it's fixed point. Look up tables for trig functions storing only 1/4 of 360 degrees. Log tables and interpolation can also be used on simple CPUS with only add but plenty of ROM/EPROM/Flash.
Yes, there are always specialist situations where a compiler doesn't support it, or a particular cpu architecture or instruction set is an issue. I can't think of a situation where an entire program needs to be in assembler. JAL allows inline assembler and most compilers will allow interface to a separately built function in assembler, or on Windows a DLL at run time, though using a DLL you wrote in C/Modula-2/C++ in VB6, is fraught. VB currency type allowed bigger integers and you had to assign a VB string to a constant (literal string) before passing as VB strings are dynamic.
It was enjoyable at the time but I don't miss it.
I've reverse engineered x86 binary to assembler to figure out what magic was being done to a VGA card by a DOS program.
Also if you are writing a compiler or new language at first stage you might do a pre-processor (translator) that emits C, then compile the compiler with that.
Then use that compiler to compile the compiler again to get a version without C idiosyncrasies. You might look at the assembler.
Then you might improve the compiler. Rinse and repeat.