flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Will future v. of Fasm include Itanium instructions set ?

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



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
Will future versions of Fasm include Itanium instructions set ?
Post 07 Jan 2010, 15:32
View user's profile Send private message Visit poster's website Reply with quote
Fanael



Joined: 03 Jul 2009
Posts: 168
Fanael
I don't think so - Itanium is not a member of x86 family.
Post 07 Jan 2010, 18:18
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16861
Location: In your JS exploiting you and your system
revolution
Itanium is dead anyway so who cares? Razz
Post 10 Jan 2010, 14:45
View user's profile Send private message Visit poster's website Reply with quote
Fanael



Joined: 03 Jul 2009
Posts: 168
Fanael
revolution wrote:
Itanium is dead anyway so who cares? Razz
So why Intel is still producing these processors?
Post 10 Jan 2010, 18:07
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16861
Location: In your JS exploiting you and your system
revolution
Fanael wrote:
So why Intel is still producing these processors?
Because they are trying to save face after spending billions developing it and getting peanuts in return.
Post 10 Jan 2010, 18:20
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2796
Location: dank orb
bitRAKE
Image
...almost tells the whole story - Itanium has flat lined.

Ten years of hype which couldn't jump start this Frankenstein heart.
Quote:
Speculation, prediction, predication, and renaming are under control of the compiler: each instruction word includes extra bits for this. This approach is the distinguishing characteristic of the architecture.
Post 10 Jan 2010, 18:44
View user's profile Send private message Visit poster's website Reply with quote
Fanael



Joined: 03 Jul 2009
Posts: 168
Fanael
Quote:
Speculation, prediction, predication, and renaming are under control of the compiler: each instruction word includes extra bits for this.
Writing something for this architecture in assembly must be painful. Thankfully, we have our old & trustworthy ARM7TDMI.
Post 10 Jan 2010, 21:01
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
bitRAKE wrote:
Ten years of hype which couldn't jump start this Frankenstein heart.
And it didn't really help that it was priced & marketed for servers and high-end workstations... nor that the original x86 hardware emulation mode was painfully slow (software solutions being faster!)... nor that AMD introduces x86-64 Smile
Post 10 Jan 2010, 22:04
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2796
Location: dank orb
bitRAKE
The primary fact was that HP/Intel attempted to shift the problem of optimization almost completely to compile-time. Not that compiler development is dead, but it is a different aspect of the problem. Much can be done dynamically at run-time to improve the preformance - nullifying inefficiencies in representation (translation). Intel is reworking the complexity of the x86 pipeline into Itanium because the compile-time control isn't sufficient. Just like P4 branch hinting - useless - because hardware branch prediction is so effective.
Post 11 Jan 2010, 00:36
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16861
Location: In your JS exploiting you and your system
revolution
[Itanium bashing]

Indeed. Compile time predictions rarely match run time reality. So moving all the smart optimisations into the compiler was doomed to be a failure. You can't respond dynamically to actual run time conditions with fixed compile time parameters.

Even the 64 predicates (as a replacement for flags) is only useful in a few real life programming situations. I nice idea, but it uses up too much of the instruction space for very little benefit.

128 GPRs. Also a nice idea, but with so many hazards to avoid in coding them that it makes them almost pointless compared to 16 GPRs with hardware renaming.

[/Itanium bashing]
Post 11 Jan 2010, 04:51
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
I must admit that i should have rather posted the question in the heap section than here, because of its generality. OK,
But...,i have a vision...Very Happy
i cannot explain but concretely in few words:

they let you play on 64bits, while they gain time
to re-think how to run emulation.
because i think the future is in the cpu emulation

The future is that your system will be able to run
Apple/Amd/ARM and Intel code on the same (Intel) processor.
For it you need more than 64bits for encapsulation, considering 64bits enough
for the common goals of our days.

Ok, i would advance the question again, but it is to generic, and should go in the heap section:

Will future versions of Fasm implement that new emulation
set of instructions, that doesnt exist yet in the x86 family ?


Regards,
hopcode

btw: if i do not mistake, other assembler have already set the Itanium jmpe instruction.If yes, Why then Question
Post 14 Jan 2010, 16:43
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
hopcode wrote:
The future is that your system will be able to run
Apple/Amd/ARM and Intel code on the same (Intel) processor.
Why do you think this is going to be the future? Where's the demand for it?

Also, Intel==AMD==Apple, pretty much (excluding intel's Itaniums and Apple's old PPC CPUs). ARM is low-power enough that it can be software emulated without any issues.

hopcode wrote:
For it you need more than 64bits for encapsulation, considering 64bits enough
for the common goals of our days.
Why would you need more than 64bit for encapsulation? I assume you're talking address space. 64bit should be quite enough, especially with paging... and if the CPU was to do hardware emulation, there would probably be specific support for it (oh, heard of VMX?).

hopcode wrote:
Will future versions of Fasm implement that new emulation
set of instructions, that doesnt exist yet in the x86 family ?
A bit hard to say when no such plans have been even hinted at by Intel...
Post 14 Jan 2010, 20:12
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
f0dder wrote:
Where's the demand for it?

Frankly, i dont know. I do not claim it corresponds to reality. It is a vision.
f0dder wrote:
Also, Intel==AMD==Apple...
You are stating it, i didnt it in my post.

Quote:
...when no such plans...

i proposed the heap section (to the moderators)

Quote:
...have been even hinted at by Intel...
bah..f0dder.. Wink Very Happy ...
They will never tell us what they plan to do, just like what they have done till now... and a lot of what they did results as infringiments:

they have stolen ideas from other not INTEL-igent developers...
...like me...
...for example

Very Happy

Greetings,
hopcode
Post 14 Jan 2010, 22:41
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16861
Location: In your JS exploiting you and your system
revolution
f0dder wrote:
ARM is low-power enough that it can be software emulated without any issues.
Hmmm, clearly you have never programmed for ARM. They may be low power (as in watts consumed) but they can't be emulated at anything even remotely near realtime by any x86 CPU. Best you could hope for might be 0.1%, to perhaps 0.5% in the best case.

Just look at bochs emulating x86 -- pitifully slow. And that is on the same processor where instructions can be directly executed once decoded.
Post 19 Jan 2010, 12:02
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
revolution: I thought the arm core itself could be reasonably well emulated - of course depending on desired target clockspeed (and generally low-ish clockspeed of ARM CPUs being primary reason why it works OK). Emulating a full ARM-using system is more work though, it's my impression you often have a couple of custom chips beside the ARM core.

revolution wrote:
Just look at bochs emulating x86 -- pitifully slow. And that is on the same processor where instructions can be directly executed once decoded.
bochs doesn't do that afaik, you'll need QEMU with special driver. Full emulation, rather than translation, is pretty slow, especially with the ├╝ber-complex x86 architecture Smile
Post 19 Jan 2010, 12:31
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16861
Location: In your JS exploiting you and your system
revolution
Best case was for a very high speed x86 and a very low speed ARM.

And bochs is a pure emulator. It decodes and executes all instructions with software before finally executing it with the appropriate handler code which, unsurprisingly, is just the same instruction with the operands coming from the virtual register set. This is how ARM is emulated on x86, except that the ARM instructions are not directly translatable to x86 and need a further layer to convert to a sequence of x86 instructions. In short, very slow. And definitely not possible to do are any decent execution rate. I have all the ARM emulators and they all completely suck compared to a real CPU.
Post 19 Jan 2010, 12:42
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
revolution wrote:
And bochs is a pure emulator. It decodes and executes all instructions with software before finally executing it with the appropriate handler code which, unsurprisingly, is just the same instruction with the operands coming from the virtual register set.
Ah yes, but what I meant is that it doesn't "execute code directly" aka doing translation... been a while since I dug into bochs source,s but you're still stuck in a big handler-loop doing an instruction at a time...

While being the same instruction, "ADD REG, REG" differs a lot in generated code from "registers[reg1] += registers[reg2]" Smile. IMHO it's quite useful that bochs is pure emulation though, and they should stick to that since other emulators do translation. Emulation is obviously a lot slower than translation, but it allows you much more complete control of the emulated machine, especially breakpoint-wise; with translation, you'd have to either do very complicated code, or translate+run a single instruction at a time (which is almost pointless) to achieve the same level of control.

Shouldn't be impossible to do translation of ARM code on x86, but obviously it takes some work - a lot of the instructions support conditional values, right? This would require either lots of CMP/Jcc in the translated code, or always running the computation and storing the destination with a CMOVcc. Obviously a fair amount of overhead, but should speed stuff up compared to pure emulation.

revolution wrote:
In short, very slow. And definitely not possible to do are any decent execution rate.
Well, depends on what you're trying to emulate Smile - I recall GameBoyAdvance emulators running fairly well (iirc that was when I had an Athlon700), even though the device includes some custom chips. But the GBA didn't use a very high-clockspeed ARM. What kind of speeds do you find in today's ARM-based products?
Post 19 Jan 2010, 14:14
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16861
Location: In your JS exploiting you and your system
revolution
f0dder wrote:
What kind of speeds do you find in today's ARM-based products?
1GHz+
Post 19 Jan 2010, 14:34
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
revolution wrote:
f0dder wrote:
What kind of speeds do you find in today's ARM-based products?
1GHz+
Ouch - definitely faster than the ~17MHz ARM7 in the GBA Smile

Even with advanced translation, you're probably not going to realtime that anytime soon... and that's just for the core cpu, ignoring the other aspects of emulating a full system.

Ignoring the process of translation and "CALL translated buffer and RET", I wonder what kind of instruction count and execution speed ratio you could achieve... a smart translator would obviously translate chunks at a time, and would try to keep virtual registers in x86 registers instead of continuous load->instruction->store to the virtualized register set... and with heavy analysis (too much to be worthwhile, and possibly requiring a dynamic JITer?) some conditional operations could probably be made unconditional.

Ah, this is drifting off-topic, but it's an interesting subject IMHO Smile

_________________
Image - carpe noctem
Post 19 Jan 2010, 14:45
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16861
Location: In your JS exploiting you and your system
revolution
hopcode wrote:
Will future versions of Fasm include Itanium instructions set ?
Actually hopcode, you could write an Itanium version of fasm, fasmitanium. Nothing to stop you doing that.

I would be interested to see how you handle the instruction bundling. Wink
Post 19 Jan 2010, 14:48
View user's profile Send private message Visit poster's website 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-2019, Tomasz Grysztar.

Powered by rwasa.