Assembly is still the only true low-level language. C++ is hardly low-level; when companies write a game in C++, they use OpenGL and DirectX and Boost and who knows what other libraries. They don't write their own 3-D rendering code that directly programs VGA registers to switch to the undocumented higher resolution 256 color modes, and they certainly don't directly program video card registers for the myriad of available architectures.
With DOS, this was the standard- that is, it was more low level. if you wanted to deal with video, you grabbed a book like Michael Abrash's "Graphics Programming Black book" and learned how to directly program the VGA registers and got to understand how the four bit planes were used. Back then even drawing a Line would require you learn a rather sophisticated algorithm (Bresenham was the standard).
The change was more because of the switch over to protected mode Operating Systems, and with the increasing networking, it just didn't make sense to trust a program to deal with absolutely every detail of the system. Besides, it got pretty silly, what with all the different programs needing their own special drivers for different graphics cards.
Now you essentially say "hey, OS, draw a line from here to here, and use this pen information" and the OS delegates that to the driver, which does it. THe driver is low level- they are usually programmed in Assembly or at least C, and they implement things like the Bresenham algorithm with line-balancing as well as a myriad of other things.
A C++ program draws a circle with OpenGL something like this:
void Circle( Float x, Float y, Float r)
{
glBegin( GL_TRIANGLE_FAN );
glVertex2f( x, y );
for( Float i = 0; i <= 2 * PI + 0.1; i += 0.1 )
{
glVertex2f( x + sin( i ) * r, y + cos( i ) * r );
}
glEnd();
}
The equivalent code in Java:
void Circle( Float x, Float y, Float r)
{
int NUM_ITERATIONS=64;
GL11.glPushMatrix();
GL11.glTranslatef(x, y, 0);
GL11.glScalef(radius, radius, 1);
GL11.glBegin(GL11.GL_TRIANGLE_FAN);
GL11.glVertex2f(0, 0);
for(int i = 0; i <= NUM_ITERATIONS; i++){
double angle = Math.PI * 2 * i / NUM_ITERATIONS;
GL11.glVertex2f((float)Math.cos(angle), (float)Math.sin(angle));
}
GL11.glEnd();
GL11.glPopMatrix();
}
The C++ version doesn't look any "lower level" to me! Now, on the other hand, if you want to draw a line in Assembly by programming a VGA directly, that's nearly 10 pages of Assembly code. THAT is low-level; setting resetting bit mask registers, setting up pixel masks with in-byte pixel addresses, all that fun stuff.
Low-level programming is now pretty much confined to embedded systems where, like the 8088, 286, 386, and other early CPUs, optimization made huge impacts on performance. Today, with multiple cores, and all sorts of different instructions, multiple instruction pipes that have rules about what instructions can go in them, as well as a myriad other issues and gotcha's related to instruction branching and pre-fetching, optimization to the level of assembly is no longer something that is a sane practice on modern desktop machines; compilers can produce far better code, or, to be more precise, the amount of time it would take an expert assembly programmer to do better than the compiler is no longer cost effective. Back in the day it might take 2-3 times longer to re-implement a complex algorithm in assembly and then work to eliminate as many jumps and cycle eaters as possible, but the gain would often make the result at least twice as fast. Of course even then the most important thing was to use the right algorithm first; trying to squeeze speed out of bubble-sort using assembly would be pretty stupid. On any modern machine (P2 or newer) I've yet to notice any appreciable difference in speed based on what language a program is written in.
Embedded systems, on the other hand, which don't have a bajillion megabytes of memory or display adapters that can push out 5 trillion triangles a second or whatever is the norm on desktops today, can and <do> benefit from that sort of tweaking. But they don't get quite as much benefit from C++, unless you take a lot of precautions such not using new/delete, avoiding exceptions, avoiding virtual classes with inheritance (and maybe inheritance altogether) be very careful with templates (or ideally don't use them at all as they bloat the code size, which is pretty important when we're talking about 8K of RAM), etc. with Embedded systems, cycle eaters and knowing exactly what is going to run- which means knowing exactly what will be emitted for any given higher level language is critical. C is pretty easy to "mind translate" into assembly for a learned C programmer; C++ not so much.
