On 2/21/2014 2:34 PM, Gene E. Bloch wrote:
On 2/21/2014, Yousuf Khan posted:
On 21/02/2014 9:23 AM, Robert Redelmeier wrote:
In comp.sys.ibm.pc.hardware.chips Yousuf Khan
wrote in part:
But it goes to show why the age of compilers is well and
truly upon us, there's no human way to keep track of these
machine language instructions. Compilers just use a subset,
and just repeat those instructions over and over again.

Hate to break it to you, but you are behind the times. Compilers
are passe' -- "modern" systems use interpreters like JIT Java.

How else you you think Android gets Apps to run on the dogs-breakfast
of ARM processors out there? It is [nearly] all interpreted Java.
So much so that Dell can get 'roid Apps to run on its x86 tablet!
(AFAIK, iOS still runs compiled Apps prob'cuz Apple _hatez_ Oracle)

Apparently, even Java byte code is compiled before it is run on a
different type of virtual machine than its own Java VM. Can't use Java
directly on Android:

"There is no Java Virtual Machine in the Android platform. Java
bytecode is not executed. Instead Java classes are compiled into a
proprietary bytecode format and run on Dalvik, a specialized virtual
machine (VM) designed specifically for Android. Unlike Java VMs, which
are stack machines, the Dalvik VM is a register-based architecture.

Because the bytecode loaded by the Dalvik virtual machine is not Java
bytecode, and of the specific way Dalvik load classes, it is not
possible to load Java libraries packages as jar files, and even a
specific logic must be used to load Android libraries (specifically
the content of the underlying dex file must be copied in the
application private internal storage area, before being able to be
loaded).[2]"

Comparison of Java and Android API - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Compari...nd_Android_API

IMO, that doesn't invalidate the point made by Robert Redelmeier; the
Java VM is one example of his point, but to me, the Dalvik VM is just
another (related) example.

BTW, I see lots of EXE files and very few JAR file in my program file
directories: I don't fully agree with Robert Redelmeier at all.

Of course, my opinion also doesn't invalidate his point - or yours :-)

Except in my opinion...


You old timers should love this one!

Back in the late 80's we got into a real time response situation that
was caused by code development using a then popular and "mil certified"
compiler. The resulting code was horrible in terms of speed. It was so
bad that the the military decided to fund a project to develop a "code
checker" that analyzed compiler output code for all kinds of issues.
One of the first results was that the compilers of the time did not
begin to utilize the processor's capabilities. Very limited percentages
of available instruction sets were used.

At the time, the only out we had in order to meet contract requirements
was to write a combination of assembly code, compiled code, and horrors,
machine code. If that wasn't bad enough, we then had to "disassemble"
the machine code to see if there was a way to duplicate it at the
highest level possible, without writing compiler extensions.

The whole thing happened because the end product had microprocessors
controlling various parts of a system, and they had to share resources,
common memory, have both a hierarchical and a random interrupt
capability, and be able to execute tasking in specific short time
frames. ECCH!

(When somebody shoots a missile at your rear, there isn't a lot of time
to go about doing something about it)!