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. 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, Feb 21, 2014
    #2
    1. Advertisements

  3. 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, Feb 21, 2014
    #3
  4. 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, Feb 21, 2014
    #4
  5. 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, Feb 21, 2014
    #5
  6. Yousuf Khan

    Yousuf Khan Guest

    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. 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, Feb 21, 2014
    #7
  8. 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, Feb 21, 2014
    #8
  9. Yousuf Khan

    Paul Guest

    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. And was somehow accessible to the mind of the programmer :)
    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, Feb 21, 2014
    #10
  11. Yousuf Khan

    Yousuf Khan Guest

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

    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. 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, Feb 21, 2014
    #14
  15. Yousuf Khan

    Char Jackson Guest

    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, Feb 22, 2014
    #15

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

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

    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

    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:
    []
    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

    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

Ask a Question

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.