Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.intel > #302 > unrolled thread

How many x86 instructions?

Back to article view | Back to comp.sys.intel

Contents

  How many x86 instructions? Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2014-02-20 18:26 -0500
    Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-20 17:19 -0800
      Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-20 17:26 -0800
        Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-20 17:29 -0800
      Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-20 17:35 -0800
      Re: How many x86 instructions? Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2014-02-20 21:33 -0500
        Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-20 19:46 -0800
        Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-20 20:02 -0800
        Re: How many x86 instructions? Paul <nospam@needed.com> - 2014-02-20 23:21 -0500
          Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-20 21:23 -0800
          Re: How many x86 instructions? Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2014-02-21 00:55 -0500
            Re: How many x86 instructions? "Stanley Daniel de Liver" <admin@127.0.0.1> - 2014-04-25 10:54 +0100
              Re: How many x86 instructions? Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2014-04-25 20:58 -0400
                Re: How many x86 instructions? "Stanley Daniel de Liver" <admin@127.0.0.1> - 2014-04-26 11:29 +0100
        Re: How many x86 instructions? Robert Redelmeier <redelm@ev1.net.invalid> - 2014-02-21 14:23 +0000
          Re: How many x86 instructions? Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2014-02-21 14:15 -0500
            Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-21 11:34 -0800
              Re: How many x86 instructions? charlie <cdknospam@msn.com> - 2014-02-23 10:14 -0500
                Re: How many x86 instructions? "J. P. Gilliver (John)" <G6JPG@soft255.demon.co.uk> - 2014-02-23 16:37 +0000
                  Re: How many x86 instructions? charlie <cdknospam@msn.com> - 2014-02-23 17:41 -0500
                    Re: How many x86 instructions? BillW50 <BillW50@aol.kom> - 2014-02-23 17:15 -0600
                      Re: How many x86 instructions? Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2014-02-23 19:30 -0500
                        Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-24 12:11 -0800
                          Re: How many x86 instructions? Jason <jason_warren@ieee.org> - 2014-02-24 18:41 -0500
                      Re: How many x86 instructions? krw@attt.bizz - 2014-02-23 19:34 -0500
                        Re: How many x86 instructions? charlie <cdknospam@msn.com> - 2014-02-24 04:42 -0500
                  Re: How many x86 instructions? Gene E. Bloch <blochxxxx@someplace.invalid> - 2014-02-23 15:45 -0800
                    Re: How many x86 instructions? BillW50 <BillW50@aol.kom> - 2014-02-23 17:49 -0600
            Re: How many x86 instructions? Char Jackson <none@none.invalid> - 2014-02-21 19:03 -0600
            Re: How many x86 instructions? Robert Redelmeier <redelm@ev1.net.invalid> - 2014-02-22 02:16 +0000
              Re: How many x86 instructions? Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2014-02-21 21:32 -0500
          Re: How many x86 instructions? Jason <jason_warren@ieee.org> - 2014-02-23 23:21 -0500
            Re: How many x86 instructions? krw@attt.bizz - 2014-02-24 13:02 -0500
              Re: How many x86 instructions? Jason <jason_warren@ieee.org> - 2014-02-24 13:38 -0500
                Re: How many x86 instructions? krw@attt.bizz - 2014-02-24 14:09 -0500
                  Re: How many x86 instructions? Jason <jason_warren@ieee.org> - 2014-02-24 16:35 -0500
              Re: How many x86 instructions? pedro1492@lycos.com - 2014-03-28 19:50 -0700
                Re: How many x86 instructions? Yousuf Khan <bbbl67@spammenot.yahoo.com> - 2014-04-02 09:47 -0400
            Re: How many x86 instructions? Robert Redelmeier <redelm@ev1.net.invalid> - 2014-02-25 00:35 +0000
              Re: How many x86 instructions? John Doe <jdoe@usenetlove.invalid> - 2014-04-25 03:33 +0000
    Re: How many x86 instructions? "Jim" <gtfo@stfu.invalid> - 2014-02-27 01:28 -0500

Page 1 of 3  [1] 2 3  Next page →

#302 — How many x86 instructions?

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

[toc] | [next] | [standalone]

#303

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)

[toc] | [prev] | [next] | [standalone]

#304

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)

[toc] | [prev] | [next] | [standalone]

#305

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)

[toc] | [prev] | [next] | [standalone]

#306

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)

[toc] | [prev] | [next] | [standalone]

#307

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

[toc] | [prev] | [next] | [standalone]

#308

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)

[toc] | [prev] | [next] | [standalone]

#309

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)

[toc] | [prev] | [next] | [standalone]

#310

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

[toc] | [prev] | [next] | [standalone]

#311

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)

[toc] | [prev] | [next] | [standalone]

#312

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

[toc] | [prev] | [next] | [standalone]

#344

On Fri, 21 Feb 2014 05:55:02 -0000, Yousuf Khan  
<bbbl67@spammenot.yahoo.com> wrote:

> 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
Did you cater for all the early cpus?

;This code assembles under nasm as 105 bytes of machine code, and will
;return the following values in ax:
;
;AX CPU
;0 8088 (NMOS)
;1 8086 (NMOS)
;2 8088 (CMOS)
;3 8086 (CMOS)
;4 NEC V20
;5 NEC V30
;6 80188
;7 80186
;8 286
;0Ah 386 and higher

code segment
assume cs:code,ds:code
.radix 16
org 100

mov ax,1
mov cx,32
shl ax,cl
jnz x186

;pusha
   db '60'
stc
jc nec

mov ax,cs
add ax,01000h
mov es,ax
xor si,si
mov di,100h
mov cx,08000h
;rep es movsb
rep es:movsb
or cx,cx
jz cmos
nmos:
mov ax,0
jmp x8_16
cmos:
mov ax,2
jmp x8_16
nec:
mov ax,4
jmp x8_16
x186:
push sp
pop ax
cmp ax,sp
jz x286

mov ax,6
x8_16:
xor bx,bx
mov byte [a1],043h
a1 label byte
nop
or bx,bx
jnz t1
or bx,1
t1:
jmp cpuid_end
x286:
pushf
pop ax
or ah,070h
push ax
popf
pushf
pop ax
and ax,07000h
jnz x386

mov ax,8
jmp cpuid_end
x386:
mov ax,0Ah

cpuid_end:


code ends

end


-- 
It's a money /life balance.

[toc] | [prev] | [next] | [standalone]

#345

On 25/04/2014 5:54 AM, Stanley Daniel de Liver wrote:
> On Fri, 21 Feb 2014 05:55:02 -0000, Yousuf Khan
> <bbbl67@spammenot.yahoo.com> wrote:
>> 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
> Did you cater for all the early cpus?
>
> ;This code assembles under nasm as 105 bytes of machine code, and will
> ;return the following values in ax:
> ;
> ;AX CPU
> ;0 8088 (NMOS)
> ;1 8086 (NMOS)
> ;2 8088 (CMOS)
> ;3 8086 (CMOS)
> ;4 NEC V20
> ;5 NEC V30
> ;6 80188
> ;7 80186
> ;8 286
> ;0Ah 386 and higher

I don't know if I still have my old program anymore, but I do remember 
at that time it could distinguish 386SX from DX and 486SX from DX as well.

	Yousuf Khan

[toc] | [prev] | [next] | [standalone]

#346

On Sat, 26 Apr 2014 01:58:41 +0100, Yousuf Khan  
<bbbl67@spammenot.yahoo.com> wrote:

> On 25/04/2014 5:54 AM, Stanley Daniel de Liver wrote:
>> On Fri, 21 Feb 2014 05:55:02 -0000, Yousuf Khan
>> <bbbl67@spammenot.yahoo.com> wrote:
>>> 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. :)

I doubt the minimalism; a print rtn is 6 bytes, and the text "This  
processor is a:" is 20 on it's own!

>>>
>>> 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
>> Did you cater for all the early cpus?
>>
>> ;This code assembles under nasm as 105 bytes of machine code, and will
>> ;return the following values in ax:
>> ;
>> ;AX CPU
>> ;0 8088 (NMOS)
>> ;1 8086 (NMOS)
>> ;2 8088 (CMOS)
>> ;3 8086 (CMOS)
>> ;4 NEC V20
>> ;5 NEC V30
>> ;6 80188
>> ;7 80186
>> ;8 286
>> ;0Ah 386 and higher
>
(this wasn't my code, I probably had it from clax some years back)
> I don't know if I still have my old program anymore, but I do remember  
> at that time it could distinguish 386SX from DX and 486SX from DX as  
> well.
>
> 	Yousuf Khan

Here's the routine I boiled it down to:
test_cpu:
  ; mikes shorter test for processor
       mov     ax,07000h
       push    ax
       popf
       sti
       pushf
       pop     ax
       and     ah,0C0h  ; isolate top 2 bits
       shr     ah,1     ; avoid negative
       cmp     ah,020h
        ; anything greater means 8086 - but 80 =-1!
        ; anything less    means bit 4 off, i.e 286
        ; equal implies 386
       ret

of course when the CPUID instruction was introduced it made the later  
chips much easier to identify!
-- 
It's a money /life balance.

[toc] | [prev] | [next] | [standalone]

#313

In comp.sys.ibm.pc.hardware.chips Yousuf Khan <bbbl67@spammenot.yahoo.com> 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

[toc] | [prev] | [next] | [standalone]

#314

On 21/02/2014 9:23 AM, Robert Redelmeier wrote:
> In comp.sys.ibm.pc.hardware.chips Yousuf Khan <bbbl67@spammenot.yahoo.com> 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

[toc] | [prev] | [next] | [standalone]

#315

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 
>> <bbbl67@spammenot.yahoo.com> 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)

[toc] | [prev] | [next] | [standalone]

#320

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
>>> <bbbl67@spammenot.yahoo.com> 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)!

[toc] | [prev] | [next] | [standalone]

#321

In message <5foOu.2965$4U7.97@fx21.iad>, charlie <cdknospam@msn.com> 
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).

[toc] | [prev] | [next] | [standalone]

#322

On 2/23/2014 11:37 AM, J. P. Gilliver (John) wrote:
> In message <5foOu.2965$4U7.97@fx21.iad>, charlie <cdknospam@msn.com>
> 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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.sys.intel

csiph-web