A computer components & hardware forum. HardwareBanter

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.

Go Back   Home » HardwareBanter forum » Processors » General
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

How many x86 instructions?



 
 
Thread Tools Display Modes
  #11  
Old February 21st 14, 06:55 AM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
Yousuf Khan[_2_]
external usenet poster
 
Posts: 1,296
Default 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  
Old February 21st 14, 03:23 PM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
Robert Redelmeier
external usenet poster
 
Posts: 316
Default 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  
Old February 21st 14, 08:15 PM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
Yousuf Khan[_2_]
external usenet poster
 
Posts: 1,296
Default 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  
Old February 21st 14, 08:34 PM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
Gene E. Bloch[_4_]
external usenet poster
 
Posts: 32
Default 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  
Old February 22nd 14, 02:03 AM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
Char Jackson
external usenet poster
 
Posts: 213
Default 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  
Old February 22nd 14, 03:16 AM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
Robert Redelmeier
external usenet poster
 
Posts: 316
Default 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  
Old February 22nd 14, 03:32 AM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
Yousuf Khan[_2_]
external usenet poster
 
Posts: 1,296
Default 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  
Old February 23rd 14, 04:14 PM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
charlie
external usenet poster
 
Posts: 20
Default 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  
Old February 23rd 14, 05:37 PM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
J. P. Gilliver (John)
external usenet poster
 
Posts: 115
Default 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)[email protected]+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  
Old February 23rd 14, 11:41 PM posted to comp.sys.intel,comp.sys.ibm.pc.hardware.chips,alt.windows7.general
charlie
external usenet poster
 
Posts: 20
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
refill instructions for hp 4v panxerox Printers 0 February 18th 07 08: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 04:04 PM
REP instructions and TLB caching John Marcus Intel 1 October 22nd 04 06:23 PM


All times are GMT +1. The time now is 03:05 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
Copyright 2004-2022 HardwareBanter.
The comments are property of their posters.