flat assembler
Message board for the users of flat assembler.

Index > Main > x64 is not truly a 64bit procesor

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
nop



Joined: 01 Sep 2008
Posts: 165
Location: right here left there
nop
x64 is not truly a 64bit procesor Sad
Post 13 Sep 2012, 02:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17475
Location: In your JS exploiting you and your system
revolution
nop wrote:
x64 is not truly a 64bit procesor Sad
orly Question
Post 13 Sep 2012, 04:54
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
nop,

I second revolution's opinion. Please elaborate.

As a side joke, once upon a time a friend of mine convinced customs that P55C is a 64-bit processor (because of its data bus width), that cut our clearance expenses a lot. Wink
Post 13 Sep 2012, 18:13
View user's profile Send private message Reply with quote
nop



Joined: 01 Sep 2008
Posts: 165
Location: right here left there
nop
revolution wrote:
The x86 encoding mechanism for immediate values only allows 32-bit signed values with ADD in 64-bit mode.
and and and other restictions Sad
Post 14 Sep 2012, 09:45
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17475
Location: In your JS exploiting you and your system
revolution
nop: x86 is quite rare for the fact that it supports 32-bit immediate values. Many other architectures can't do that. Would you consider IA-64 to be "truly a 64bit processor"?
Post 14 Sep 2012, 10:27
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 701
Location: Adelaide
sinsi
>x64 is not truly a 64bit procesor
Pentium MMX was the first 64-bit CPU.
Or maybe a 386, that could make 32*32 a 64-bit number.

Anyway, who really uses 64-bit integers?
Post 14 Sep 2012, 10:48
View user's profile Send private message Reply with quote
nop



Joined: 01 Sep 2008
Posts: 165
Location: right here left there
nop
what wud u think of a 8bit procesor which only allows 4bit immediates
what wud u think of a 16bit procesor which only allows 8bit immediates
what wud u think of a 32bit procesor which only allows 16bit immediates
so what do u think of a 64bit procesor which only allows 32bit immediates
Sad Sad Sad Sad
Post 14 Sep 2012, 18:33
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
nop
Quote:
what wud u think of a 8bit procesor which only allows 4bit immediates
what wud u think of a 16bit procesor which only allows 8bit immediates
what wud u think of a 32bit procesor which only allows 16bit immediates
so what do u think of a 64bit procesor which only allows 32bit immediates

I would think of it as of a completely normal situation. It's actually very uncommon, that an architecture allows immediates of a size equal to the architecture's word length. There're four different RISC-architectures I worked with, and only one (btw. officially undocumented) allowed such long immediates.

If you think, it's normal, then please name at least a couple architectures except x86, which allow such long immediates.
Post 14 Sep 2012, 21:21
View user's profile Send private message Reply with quote
nop



Joined: 01 Sep 2008
Posts: 165
Location: right here left there
nop
Quote:
There're four different RISC-architectures I worked with, and only one (btw. officially undocumented) allowed such long immediates.
fair enough for risc maybe but that is irelevent for cisc procesors of course
Post 15 Sep 2012, 04:04
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17475
Location: In your JS exploiting you and your system
revolution
nop wrote:
... but that is irelevent for cisc procesors of course
Why?
Post 15 Sep 2012, 04:20
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
nop
Quote:
fair enough for risc maybe but that is irelevent for cisc procesors of course

Firstly, if it's fair enough for RISC's, then it's fair enough for computer architectures in general, because there's a much larger variety of RISC's then CISC's on the markets.

Secondly, even if it's not that common, it's still normal for CISC's. What of those things do we still have on the markets except x86? May be Motorola 68000... well, it allows 32 bit immediates, but not for all instructions (as far as I understand from the short look into the reference manual). The IBM z/Architecture does not allow 64 bit immediates at all. And now Intel 64 on the desktops market does allow 64 bit immediates (mov r64,imm64), but not for all instructions.

The architecture's word length corresponds to the size of the applications addressing space (size of a pointer) and nothing else.
Post 15 Sep 2012, 13:05
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17475
Location: In your JS exploiting you and your system
revolution
l_inc wrote:
The architecture's word length corresponds to the size of the applications addressing space (size of a pointer) and nothing else.
Erm ...

z80 (8-bit CPU) has 16-bit addressing
8086 (16-bit CPU) has 20-bit addressing
Many x86 (64-bit CPUs) have 40-bit addressing
Post 15 Sep 2012, 14:06
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
Well. This statement was probably a little inconsiderate, but please, reread it. What you specify for x86 and x64 is a physical address bus width. The applications work however explicitly with pointers of size 32 bit's and 64 bit's accordingly. Regarding Z80, I'm not familiar with it.
Post 15 Sep 2012, 14:50
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17475
Location: In your JS exploiting you and your system
revolution
For 8086 we have a 20-bit pointer (ES:BX generates a 20-bit address) to match the 20-bit bus. Anyhow I was merely pointing out that using pointer size is not the way to measure the bit-ness of a CPU. There are architectures that have different sized pointers, registers and buses. I would expect that in general most people would consider the ALU width to be the measure of bit-ness (old bit-slice CPUs are a prime example).
Post 15 Sep 2012, 15:04
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
Quote:
I would expect that in general most people would consider the ALU width to be the measure of bit-ness.

A 32-bit Pentium 4 is able to add 64-bit integer values due to SSE2. A 16-bit dsPIC33F is able to multiply two 16-bit integer values and add the 32-bit result to a 40-bit accumulator with the instruction MAC. The 32-bit MIPS32 has a similar instruction MADD able to multiply 32-bit values and add the result to a 64-bit value.
Post 15 Sep 2012, 16:04
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17475
Location: In your JS exploiting you and your system
revolution
l_inc wrote:
A 32-bit Pentium 4 is able to add 64-bit integer values due to SSE2. A 16-bit dsPIC33F is able to multiply two 16-bit integer values and add the 32-bit result to a 40-bit accumulator with the instruction MAC. The 32-bit MIPS32 has a similar instruction MADD able to multiply 32-bit values and add the result to a 64-bit value.
Perhaps you would like to review the meaning of ALU? Wink
Post 15 Sep 2012, 21:45
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
Perhaps. Am I wrong assuming, that a 64-bit adder means at least a 64-bit ALU? Or how do you define an ALU width?
Post 15 Sep 2012, 23:03
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17475
Location: In your JS exploiting you and your system
revolution
A MAC unit is not a CPU ALU. A coprocessor accumulator is not a CPU ALU.

If it is not the ALU size then why else is a Z80 8-bit? Why is an 8086 16-bit? Why is a Core-i7 64-bit when it can multiply to 64-bit numbers and get a 128-bit result? I don't think there is any other definition that matches except to consider the ALU of the CPU.
Post 15 Sep 2012, 23:24
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
Quote:
A MAC unit is not a CPU ALU.

The MAC instruction is executed by the DSP engine, which is a part of the CPU.
Quote:
A coprocessor accumulator is not a CPU ALU.

Not sure, what you mean here. If you mean the SSE/MMX ALU in x86, then it's still a part of the CPU. Btw. the coprocessor is not a separate hardware part of the x86 for almost 15 years. It's referred to as FPU ALU, which is a part of the CPU.
And the register's HI and LO on MIPS32 are definitely not a coprocessor accumulator.
Quote:
If it is not the ALU size then why else is a Z80 8-bit?

No idea. Smile
Quote:
Why is an 8086 16-bit?

My phlogiston theory was based on the pointers (which I'm ready to give up on). Probably a little far fetched argumentation regarding 8086 is that 8086 still has 16 bits effective addresses explicitly specified by the instructions and segment selectors are a kind of an implicit address part.
Quote:
Why is a Core-i7 64-bit when it can multiply to 64-bit numbers and get a 128-bit result?

Ehm... Aren't you sawing the bough you're sitting on? Smile This should be rather my argumentation, but I wouldn't use it anyway, cause multiplication and division are (almost?) always naturally made to be able to work with the double of the native width.
Post 16 Sep 2012, 14:45
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
Well, my definition: The bit-ness of the CPU is equal to the maximal bit-ness of the source data for "and" instruction. (available on all known CPUs). Very Happy
Post 16 Sep 2012, 14:59
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.