If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
How many x86 instructions?
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 |
#12
|
|||
|
|||
How many x86 instructions?
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 |
#13
|
|||
|
|||
How many x86 instructions?
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 |
#14
|
|||
|
|||
How many x86 instructions?
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... -- Gene E. Bloch (Stumbling Bloch) |
#15
|
|||
|
|||
How many x86 instructions?
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/Compari...nd_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...ife-1507264545 -- Char Jackson |
#16
|
|||
|
|||
How many x86 instructions?
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/Compari...nd_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 |
#17
|
|||
|
|||
How many x86 instructions?
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 |
#18
|
|||
|
|||
How many x86 instructions?
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)! |
#19
|
|||
|
|||
How many x86 instructions?
In message , 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). |
#20
|
|||
|
|||
How many x86 instructions?
On 2/23/2014 11:37 AM, J. P. Gilliver (John) wrote:
In message , 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. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
refill instructions for hp 4v | panxerox | Printers | 0 | February 18th 07 07:25 PM |
Instructions SSE | bruno | Overclocking AMD Processors | 1 | May 10th 06 05:10 AM |
Instructions - terrible | Travis King | AMD x86-64 Processors | 3 | January 8th 05 03:04 PM |
REP instructions and TLB caching | John Marcus | Intel | 1 | October 22nd 04 06:23 PM |