1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

How many x86 instructions?

Discussion in 'Intel' started by Yousuf Khan, Feb 20, 2014.

  1. Yousuf Khan

    Yousuf Khan Guest

    I was asked this question recently, and I just realized that I really
    don't know the answer to this. I may have known at one time, but I don't
    anymore, as things have moved on since I last used to do assembly
    programming. How many instructions are there in modern x86 processors?

    These days it seems more practical to just list the number of x86
    instruction set extensions than to count up just the individual
    instructions themselves. But even the number of x86 instruction set
    extensions are becoming unmanageable: x86-16, x86-32, x64, x87, MMX,
    SSE, 3DNow, VT-X, AMD-V, AVX, AES, etc., etc.

    I searched around just looking for a simple count of instructions, and I
    couldn't find them.

    Yousuf Khan
     
    Yousuf Khan, Feb 20, 2014
    #1
    1. Advertisements

  2. On 2/20/2014, Yousuf Khan posted:
    > I was asked this question recently, and I just realized that I really
    > don't know the answer to this. I may have known at one time, but I
    > don't anymore, as things have moved on since I last used to do
    > assembly programming. How many instructions are there in modern x86
    > processors?


    > These days it seems more practical to just list the number of x86
    > instruction set extensions than to count up just the individual
    > instructions themselves. But even the number of x86 instruction set
    > extensions are becoming unmanageable: x86-16, x86-32, x64, x87, MMX,
    > SSE, 3DNow, VT-X, AMD-V, AVX, AES, etc., etc.


    > I searched around just looking for a simple count of instructions,
    > and I couldn't find them.


    > Yousuf Khan


    Looking briefly at http://ref.x86asm.net/ and http://www.sandpile.org/
    gives me the impression that the *isn't* a simple count of
    instructions.

    The first was pretty confusing, but it offered a manual for $20
    involving a table in XML that might be a useful way to track it down.
    Or maybe nit...

    The second lists instructions in several subsets and I didn't see a way
    to find a combined list.

    I'd suggest making a spreadsheet, and using sandpile to fill some cells
    with numbers that you can then easily sum :)

    Suddenly I'm glad that I don't code in Intel asm any more ;-)

    To be honest, I vaguely recall that it was never easy, even well before
    the proliferation of instruction sets[1], to get such a count.

    [1] My Intel asm experience was a pretty long time ago!

    --
    Gene E. Bloch (Stumbling Bloch)
     
    Gene E. Bloch, Feb 21, 2014
    #2
    1. Advertisements

  3. On 2/20/2014, Gene E. Bloch posted:
    > Looking briefly at http://ref.x86asm.net/ and
    > http://www.sandpile.org/ gives me the impression that the *isn't* a

    ^^^
    there

    > simple count of instructions.


    > The first was pretty confusing, but it offered a manual for $20
    > involving a table in XML that might be a useful way to track it down.
    > Or maybe nit...


    Or maybe not.

    I am aware that my spell checker is sometimes quite generous in
    allowing semantic errors, so I have no excuse for letting those errors
    get away from me.

    But if they amused you, so much the better :)

    --
    Gene E. Bloch (Stumbling Bloch)
     
    Gene E. Bloch, Feb 21, 2014
    #3
  4. On 2/20/2014, Gene E. Bloch posted:
    > On 2/20/2014, Gene E. Bloch posted:
    >> Looking briefly at http://ref.x86asm.net/ and
    >> http://www.sandpile.org/ gives me the impression that the *isn't* a

    > ^^^
    > there


    >> simple count of instructions.


    >> The first was pretty confusing, but it offered a manual for $20
    >> involving a table in XML that might be a useful way to track it
    >> down. Or maybe nit...


    > Or maybe not.


    > I am aware that my spell checker is sometimes quite generous in
    > allowing semantic errors, so I have no excuse for letting those
    > errors get away from me.


    > But if they amused you, so much the better :)


    It's still pretty funny.

    So much for my skill at ASCII art, or ASCII errata corrections.

    "impression that *there* isn't a simple count ..."

    --
    Gene E. Bloch (Stumbling Bloch)
     
    Gene E. Bloch, Feb 21, 2014
    #4
  5. On 2/20/2014, Gene E. Bloch posted:
    > On 2/20/2014, Yousuf Khan posted:
    >> I was asked this question recently, and I just realized that I
    >> really don't know the answer to this. I may have known at one time,
    >> but I don't anymore, as things have moved on since I last used to
    >> do assembly programming. How many instructions are there in modern
    >> x86 processors?


    >> These days it seems more practical to just list the number of x86
    >> instruction set extensions than to count up just the individual
    >> instructions themselves. But even the number of x86 instruction set
    >> extensions are becoming unmanageable: x86-16, x86-32, x64, x87,
    >> MMX, SSE, 3DNow, VT-X, AMD-V, AVX, AES, etc., etc.


    >> I searched around just looking for a simple count of instructions,
    >> and I couldn't find them.


    >> Yousuf Khan


    > Looking briefly at http://ref.x86asm.net/ and
    > http://www.sandpile.org/ gives me the impression that the *isn't* a
    > simple count of instructions.


    > The first was pretty confusing, but it offered a manual for $20
    > involving a table in XML that might be a useful way to track it down.
    > Or maybe nit...


    > The second lists instructions in several subsets and I didn't see a
    > way to find a combined list.


    > I'd suggest making a spreadsheet, and using sandpile to fill some
    > cells with numbers that you can then easily sum :)


    > Suddenly I'm glad that I don't code in Intel asm any more ;-)


    > To be honest, I vaguely recall that it was never easy, even well
    > before the proliferation of instruction sets[1], to get such a count.


    > [1] My Intel asm experience was a pretty long time ago!


    There are a lot of manuals here[1]:

    http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html

    AKA http://tinyurl.com/3lh7em3

    They are downloadable PDFs in several configurations...but I bet they
    won't have a unified table either :-(

    [1] And you've probably already been there...

    --
    Gene E. Bloch (Stumbling Bloch)
     
    Gene E. Bloch, Feb 21, 2014
    #5
  6. Yousuf Khan

    Yousuf Khan Guest

    On 20/02/2014 8:19 PM, Gene E. Bloch wrote:
    > Looking briefly at http://ref.x86asm.net/ and http://www.sandpile.org/
    > gives me the impression that the *isn't* a simple count of instructions.


    Yeah, I looked at some of those sites already, and that was my
    impression too, that the instructions aren't easy to count. It doesn't
    help that Intel and AMD have their own extensions, either.

    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.

    Yousuf Khan
     
    Yousuf Khan, Feb 21, 2014
    #6
  7. On 2/20/2014, Yousuf Khan posted:
    > On 20/02/2014 8:19 PM, Gene E. Bloch wrote:
    >> Looking briefly at http://ref.x86asm.net/ and
    >> http://www.sandpile.org/
    >> gives me the impression that the *isn't* a simple count of
    >> instructions.


    > Yeah, I looked at some of those sites already, and that was my
    > impression too, that the instructions aren't easy to count. It
    > doesn't help that Intel and AMD have their own extensions, either.


    > 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.


    > Yousuf Khan


    Maybe there are too many instructions (seriously).

    But on the other hand, if I were writing video drivers (for moving
    video), I'd want a specialized compiler that uses one subset of
    instructions, and if I were writing heavy math software, I'd need
    another subset in another specialized compiler...and so on.

    None of the above is where I am these days :)

    --
    Gene E. Bloch (Stumbling Bloch)
     
    Gene E. Bloch, Feb 21, 2014
    #7
  8. On 2/20/2014, Yousuf Khan posted:
    > On 20/02/2014 8:19 PM, Gene E. Bloch wrote:
    >> Looking briefly at http://ref.x86asm.net/ and
    >> http://www.sandpile.org/
    >> gives me the impression that the *isn't* a simple count of
    >> instructions.


    > Yeah, I looked at some of those sites already, and that was my
    > impression too, that the instructions aren't easy to count. It
    > doesn't help that Intel and AMD have their own extensions, either.


    > 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.


    > Yousuf Khan


    Maybe there are too many instructions (seriously).

    But on the other hand, if I were writing video drivers (for moving
    video), I'd want a specialized compiler that uses one subset of
    instructions, and if I were writing heavy math software, I'd need
    another subset in another specialized compiler...and so on.

    None of the above is where I am these days :)

    <COMMENT>
    I am reposting this. I sent it about 15 min ago, and it is now shown as
    removed from the server. Perhaps I have offended the Usenet gods.
    </COMMENT>

    --
    Gene E. Bloch (Stumbling Bloch)
     
    Gene E. Bloch, Feb 21, 2014
    #8
  9. Yousuf Khan

    Paul Guest

    Yousuf Khan wrote:
    > On 20/02/2014 8:19 PM, Gene E. Bloch wrote:
    >> Looking briefly at http://ref.x86asm.net/ and http://www.sandpile.org/
    >> gives me the impression that the *isn't* a simple count of instructions.

    >
    > Yeah, I looked at some of those sites already, and that was my
    > impression too, that the instructions aren't easy to count. It doesn't
    > help that Intel and AMD have their own extensions, either.
    >
    > 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.
    >
    > Yousuf Khan


    Actually, even the compiler writers are getting
    tired of the expanding instruction set. (I read
    a rant on the topic.) Intel can make new instructions
    faster than those guys can find a use for them.

    At one time, a compiler would issue instructions
    from about 30% of the instruction set. It would mean
    a compiled program would never emit the other 70% of
    them. But a person writing assembler code, would
    have access to all of them, at least, as long as
    the mnemonic existed in the assembler.

    I worked on a couple of 8 bit micros, and at the
    time, you could get a fold-out card (about a foot long,
    double sided), with all the instructions on it. And
    that's what we'd use as a quick reference when picking
    instructions. You can't do that now, because the
    fold-out card would be a hundred feet long. It
    was a sign you were a "real programmer", when the
    local rep gave you your fold-out card :) LOL.

    Paul
     
    Paul, Feb 21, 2014
    #9
  10. On 2/20/2014, Paul posted:
    > Yousuf Khan wrote:
    >> On 20/02/2014 8:19 PM, Gene E. Bloch wrote:
    >>> Looking briefly at http://ref.x86asm.net/ and
    >>> http://www.sandpile.org/
    >>> gives me the impression that the *isn't* a simple count of
    >>> instructions.

    >>
    >> Yeah, I looked at some of those sites already, and that was my
    >> impression too, that the instructions aren't easy to count. It
    >> doesn't help that Intel and AMD have their own extensions, either.
    >>
    >> 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.
    >>
    >> Yousuf Khan


    > Actually, even the compiler writers are getting
    > tired of the expanding instruction set. (I read
    > a rant on the topic.) Intel can make new instructions
    > faster than those guys can find a use for them.


    > At one time, a compiler would issue instructions
    > from about 30% of the instruction set. It would mean
    > a compiled program would never emit the other 70% of
    > them. But a person writing assembler code, would
    > have access to all of them, at least, as long as
    > the mnemonic existed in the assembler.


    And was somehow accessible to the mind of the programmer :)

    > I worked on a couple of 8 bit micros, and at the
    > time, you could get a fold-out card (about a foot long,
    > double sided), with all the instructions on it. And
    > that's what we'd use as a quick reference when picking
    > instructions. You can't do that now, because the
    > fold-out card would be a hundred feet long. It
    > was a sign you were a "real programmer", when the
    > local rep gave you your fold-out card :) LOL.


    > Paul


    In my assembly language days, the fold-out card was pretty damn small
    :)

    I remember writing some code to move a block of memory in 286 (I think)
    days, and later I realized how badly I had set it up. I didn't take
    proper advantage of the way the 20-bit addressing worked[1], so I made
    the call unusual and the code klutzy. I required the caller to address
    memory to the byte level, i.e., all 20 bits, instead of to the
    high-order 16 bits. Flexible but silly.

    [1] Because I didn't fully understand the usage conventions yet.

    --
    Gene E. Bloch (Stumbling Bloch)
     
    Gene E. Bloch, Feb 21, 2014
    #10
  11. Yousuf Khan

    Yousuf Khan Guest

    On 20/02/2014 11:21 PM, Paul wrote:
    > At one time, a compiler would issue instructions
    > from about 30% of the instruction set. It would mean
    > a compiled program would never emit the other 70% of
    > them. But a person writing assembler code, would
    > have access to all of them, at least, as long as
    > the mnemonic existed in the assembler.


    I think the original idea of the x86's large instruction count was to
    make an assembly language as full-featured as a high-level language. x86
    even had string-handling instructions!

    I remember I designed an early version of the CPUID program that ran
    under DOS. The whole executable including its *.exe headers was
    something like 40 bytes! Got it down to under 20 bytes when I converted
    it to *.com (which had no headers)! Most of the space was used to store
    strings, like "This processor is a:" followed by generated strings like
    386SX or 486DX, etc. :)

    You could make some really tiny assembler programs on x86. Of course,
    compiled programs ignored most of these useful high-level instructions
    and stuck with simple instructions to do everything.

    Yousuf Khan
     
    Yousuf Khan, Feb 21, 2014
    #11
  12. 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)


    -- Robert
     
    Robert Redelmeier, Feb 21, 2014
    #12
  13. Yousuf Khan

    Yousuf Khan Guest

    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/Comparison_of_Java_and_Android_API
     
    Yousuf Khan, Feb 21, 2014
    #13
  14. 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/Comparison_of_Java_and_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...

    --
    Gene E. Bloch (Stumbling Bloch)
     
    Gene E. Bloch, Feb 21, 2014
    #14
  15. Yousuf Khan

    Char Jackson Guest

    On Fri, 21 Feb 2014 14:15:42 -0500, Yousuf Khan <>
    wrote:

    >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/Comparison_of_Java_and_Android_API


    There has been some buzz in recent months about Dalvik's replacement, ART.
    Art is apparently an "ahead of time" compiler, unlike Dalvik, which is "just
    in time". Art is supposed to improve app performance and battery life, at
    the expense of somewhat larger file sizes.

    Sample article
    http://lifehacker.com/android-art-vs-dalvik-runtimes-effect-on-battery-life-1507264545

    --

    Char Jackson
     
    Char Jackson, Feb 22, 2014
    #15
  16. In comp.sys.ibm.pc.hardware.chips Yousuf Khan <> wrote in part:
    > 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/Comparison_of_Java_and_Android_API



    Thanks you for the additional details. "precompiled" makes some sense
    -- why waste all that time parsing ASCII? Dalvik would of course
    have to be customized for the flavor of ARM it was installed on.

    Dalvik being a register-based VM also makes some sense for
    ARMs with more registers. x86 has a blazing fast data L1
    that reduces the stack penalty, often to zero. I wonder how
    Dell implemented Dalvik on the Venue?


    -- Robert
     
    Robert Redelmeier, Feb 22, 2014
    #16
  17. Yousuf Khan

    Yousuf Khan Guest

    On 21/02/2014 9:16 PM, Robert Redelmeier wrote:
    > Thanks you for the additional details. "precompiled" makes some sense
    > -- why waste all that time parsing ASCII? Dalvik would of course
    > have to be customized for the flavor of ARM it was installed on.


    It's interesting how Java has become just another compiled language in
    many cases these days.


    > Dalvik being a register-based VM also makes some sense for
    > ARMs with more registers. x86 has a blazing fast data L1
    > that reduces the stack penalty, often to zero. I wonder how
    > Dell implemented Dalvik on the Venue?


    X86 also has lots of registers to spare these days (thanks to x64), so a
    register based VM should be pretty blazing fast on one of those too.

    Yousuf Khan
     
    Yousuf Khan, Feb 22, 2014
    #17
  18. Yousuf Khan

    charlie Guest

    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/Comparison_of_Java_and_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)!
     
    charlie, Feb 23, 2014
    #18
  19. In message <5foOu.2965$>, charlie <>
    writes:
    []
    >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.


    What's machine code (as opposed to assembly code) in this context? How
    did you write it?
    --
    J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

    (If you are unlucky you may choose one of the old-fashioned ones [language
    schools] and be taught English as it should be, and not as it is, spoken.)
    George Mikes, "How to be Decadent" (1977).
     
    J. P. Gilliver (John), Feb 23, 2014
    #19
  20. Yousuf Khan

    charlie Guest

    On 2/23/2014 11:37 AM, J. P. Gilliver (John) wrote:
    > In message <5foOu.2965$>, charlie <>
    > writes:
    > []
    >> 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.

    >
    > What's machine code (as opposed to assembly code) in this context? How
    > did you write it?

    Assembly code (source) is just that, and compiled or changed to machine
    code at some point. "Dis-assembly" converts machine code back to
    Assembly code. (When the assembler understands the code, which may not
    always be the case)
    Machine code may be "relocatable", or be tied to memory locations.
    Machine code can be the output of the assembler or loader in some cases.

    A more complete explanation can be found at
    http://en.wikipedia.org/wiki/Machine_code

    The front panel on many of the old mainframes and minicomputers allowed
    direct entry of machine code, and was usually used to manually enter
    such things as a "bootstrap", or loader program.
     
    charlie, Feb 23, 2014
    #20
    1. Advertisements

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Similar Threads
  1. wheel
    Replies:
    6
    Views:
    516
    wheel
    Feb 21, 2004
  2. NBK
    Replies:
    5
    Views:
    354
    Barry Watzman
    Oct 6, 2004
  3. Go Tyler
    Replies:
    6
    Views:
    414
    Bob Willard
    Dec 13, 2005
  4. Darren
    Replies:
    6
    Views:
    691
    Bob Knowlden
    Feb 22, 2006
  5. Uncle Vinnie

    1.2 Tualitan- how many volts is too many?

    Uncle Vinnie, Jul 16, 2005, in forum: Overclocking
    Replies:
    21
    Views:
    1,153
    Fishface
    Jul 23, 2005
  6. AnotherAnonymous

    Many many errors...

    AnotherAnonymous, Mar 26, 2007, in forum: Gigabyte
    Replies:
    3
    Views:
    847
  7. Peter

    Many, many COM ports "in use"...

    Peter, Mar 16, 2005, in forum: Tablet PC
    Replies:
    5
    Views:
    547
    Chris H.
    Mar 21, 2005
  8. Albretch Mueller
    Replies:
    11
    Views:
    692
    vladitx
    Dec 16, 2009
Loading...