take your code (or your .class file) and run it SLOWLY anywhere with a JVM ;->

Alot of code that called the BIOS still works, so to that level you got some basic platform compatibility, but then you end up thowing in code to use anything at the full hardware capacity. Then you could always include an assembler coded compiler and have most of the code in whatever compiler input you need. There really is no need to make entire programs in assembly. I did once, it was really small, and all it did was use the BIOS to print HEX from AX BX CX DX DS and ES. But a friend edited it to work with C++. I dont really know C that well myself so I am prolly gonna check out that area more.

Speak for yourself! For me, there is no need to program in any other language.

Antonis

I guess you make a very good point indeed. I am actually pretty sure that if I had some good tools to take out the tedious stuff, and a library of procedures to simplify calls to whatever platform I target.

im learning it at college and i hate it (although i do value its importance) - IMHO its great for speed/size critical things but for most applications it is not worth taking the time as Assembly is hard to maintain and could require many hundreds of lines to accomplish what 5 lines of a modern language could do.

There are plenty of tools and libraries (most of which, if not all, are free) available.

No hard at all. 32-bit windows MASM code, for example, looks almost like C (function declarations, modular design, if, else etc). Number of lines can still be equal to the lines of equivalent C code but this is not the point; How many characters on a line?

Antonis

What is my opinion of assembly language? Can you handle the truth?

I must say, assembly language is my favorite high-level language. Okay, arguably assembly language is actually a mid-level language, since it has close correspondence with much of the CPU hardware.

Assembly language is often the most satisfying way to program, and executes [much] faster - if you have even modest talent for ASM.

Why do I call assembly-language a mid-level language? Well, I designed several CPUs (and CPU-like controllers/devices), and can say from experience assembly-language is ~ the 3rd level language, above microcode which is above what I think of as "hardcode" or "directcode" (sorta spatial-programming vs temporal-programming).

An assembly language program is at just the perfect level to connect the "fixed" architecture and capabilities of the CPU hardware to the essential goals and requirements of my applications --- efficiently.

I need to multiply two 4-element f64 vectors by one 4x4 f64 matrix to transform the 3D coordinate of a point and its normal-vector into a new coordinate system in less than 40 nanoseconds - otherwise my simulation will not run at frame-rate. What do I do? Easy! I write inline SIMD/SSE2+ assembly language (with intelligent pre-fetches) and "job done", "works great", "piece of cake". Alternative? 120ns by the fastest, smartest SIMD-aware compiler I could find == 3x slower!

I write vision-system code to read every pixel from four 8-megapixel CCD chips at 10FPS (!!!at minimum!!!), save the images, inspect the images with software to find ~100 points on all four images that are "corresponding" (example: tip of index finger on right hand), and hand this information to robotics systems that react upon this "feedback". You want to program this in a high-level language? In 2026 maybe!!! Well I need to achieve this for a product that retails for $300~$600. To clarify what the above reduces to, each of the four CCDs outputs a 12-bit or 16-bit value every 10ns (at 10FPS = slowest feasible rate). And every pixel must be read, processed, stored - then all those image-processing processes must be performed on key parts of the image (which must be found/identified/isolated/correlated). Go do this with VisualBasic or Java or C# --- and your favorite "packages"!

These are 2 examples from my *recent* real-life work experience. But they are representative of many projects over many years. However, I cannot leave the impression that assembly language is good only when maximum speed is necessary. Perish the thought!

When I want collaborators on software projects - even ones without any serious need for blinding speed - who do I want to work with? Correct! I want programmers who love assembly-language! Why? Because ***vastly*** less often are they fools, suckers, talkers and self-promoting BS-artists than typical programmers/engineers/scientists. And I bet you know why - right? Because they prefer not to adopt the endless spew of popular fads that pollute all of modern life - most certainly including the monumental catastrophe the "modern" computer/software industry has become! Because assembly-language programmers usually care to understand "how things work" and feel *profoundly* uncomfortable "compounding the (unknown/invisible/hidden) errors/mistakes/disasters of others". These folks are not suckers for the totally-commonplace modern "ignorance = bliss" fantasy --- namely, "if you build your code on top of this [fancy/brilliant/superlative/state-of-the-art/super-dooper] language/library/controls/yadayadayada, you can slip into that warm fuzzy comfortable illusion that you can poke a few keys and click a few buttons and generate earth-shattering wonder-apps --- almost without effort. And most importantly, you need not do any difficult thinking or coding, and *especially* not understand how (or whether) the bulk of your program functions.

The fact is, though my programs usually contain more C code than assembly language, it is the assembly language that usually makes them great - and often makes them possible! As a [former] writer of compilers, code-generators and optimizers, you might think I should blush to admit that even the best super-duper-optimized wonder compiler runs 2x to 20x slower than the assembly language code my brain concocts.* Yes, this is usually because extensive thinking about how to write the crucial sections in assembly language leads me to concoct unconventional ways to configure, structure or orchestrate those parts of the program/problem that no compiler would or could ever "dream of". But hey, I am also happy to admit that if the crucial parts and inner-loops of an application is utterly, thoroughly and inherently matched to the structure of normal compiler output, then the compiler code will only take 1.3x ~ 2.0x as long to execute. The only problem is - I can't think of one case where this happened! Maybe I am just so horribly unlucky that I get only difficult problems (as in "interesting", "fascinating", "cool"). Who knows, that might be it? Willing to risk your career (or life) on it?

Frankly, the best part of assembly language is what I implied at first. Maybe programming and thinking-in assembly language will save a few minds from the mire, muck and lameness-sameness of the endless stream of fads, dreams, special-effects and mental sleeping pills. This assures assembly language will be more-and-more ignored by the US "education" system. Unfortunately, it is too obvious that few high-level language programmers ever emerge from the fad-and-PR-induced daze (and brain-damage?) to ask themselves this nasty question, "if all these super-languages and super-tools are the 'ultimate answers' they claim and achieve such 'infinite speed/quality/reliability/wonders', then why am I told I need never-ending-sets-of-super-whoopies every year (or month)?".

The dirty secret is (which is only a secret because those who know get tired of being laughed-at and spit-upon by crafty-or-mindless hordes of fad promoters-and-mindless-apologists), that I can write every last bit of my entire application without one single bit of supposed "help" from OPC (other peoples code). Even the OS is one big pain in the butt in many applications/devices and is better ejected than incorporated. Faced with large, impressive [often one-person] [nearly] self-contained projects/products written largely-to-100% in assembly-language, the hordes of mindless programmers (and talkers) simply ignore it, move on, and remain quiet (for once!). Which leaves the best gold mines in the hands of honest, straightforward, simpleminded "know-it-alls" --- who are usually happy to keep their traps shut and avoid ridicule.

Which reminds me (finally coming to my senses), which button must I click to delete this message? Definitely better that I not post it.

* I do not blush because I am a 100% pure unapologetic "honest simpleton" who always prefers to see/understand/convey the simple direct honest truth no matter what other consequences that implies.

** Fortunately, a few (mostly assembly-language or low-level C) code libraries do exist that are basically sensible and fairly reliable - and available in source code if you are smart enough to develop in Linux!
Just in case we need to see/learn/trace how various sections work.