Index
> Compiler Internals > Will future v. of Fasm include Itanium instructions set ?Goto page 1, 2 Next |
| Author |
|
|
hopcode 07 Jan 2010, 15:32
Will future versions of Fasm include Itanium instructions set ?
|
|||
07 Jan 2010, 15:32 |
|
|
Fanael 07 Jan 2010, 18:18
I don't think so - Itanium is not a member of x86 family.
|
|||
|
07 Jan 2010, 18:18 |
|
|
revolution 10 Jan 2010, 14:45
Itanium is dead anyway so who cares?
 |
|||
|
10 Jan 2010, 14:45 |
|
|
Fanael 10 Jan 2010, 18:07
revolution wrote: Itanium is dead anyway so who cares? |
|||
|
10 Jan 2010, 18:07 |
|
|
bitRAKE 10 Jan 2010, 18:44
...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. |
|||
|
10 Jan 2010, 18:44 |
|
|
Fanael 10 Jan 2010, 21:01
Quote: Speculation, prediction, predication, and renaming are under control of the compiler: each instruction word includes extra bits for this. |
|||
|
10 Jan 2010, 21:01 |
|
|
f0dder 10 Jan 2010, 22:04
bitRAKE wrote: Ten years of hype which couldn't jump start this Frankenstein heart.  |
|||
|
10 Jan 2010, 22:04 |
|
|
bitRAKE 11 Jan 2010, 00:36
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.
|
|||
|
11 Jan 2010, 00:36 |
|
|
revolution 11 Jan 2010, 04:51
[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] |
|||
|
11 Jan 2010, 04:51 |
|
|
hopcode 14 Jan 2010, 16:43
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... 
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  |
|||
|
14 Jan 2010, 16:43 |
|
|
f0dder 14 Jan 2010, 20:12
hopcode wrote: The future is that your system will be able to run 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 hopcode wrote: Will future versions of Fasm implement that new emulation |
|||
|
14 Jan 2010, 20:12 |
|
|
hopcode 14 Jan 2010, 22:41
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... Quote: ...when no such plans... i proposed the heap section (to the moderators) Quote: ...have been even hinted at by Intel...  ...
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
Greetings, hopcode |
|||
|
14 Jan 2010, 22:41 |
|
|
revolution 19 Jan 2010, 12:02
f0dder wrote: ARM is low-power enough that it can be software emulated without any issues. Just look at bochs emulating x86 -- pitifully slow. And that is on the same processor where instructions can be directly executed once decoded. |
|||
|
19 Jan 2010, 12:02 |
|
|
f0dder 19 Jan 2010, 12:31
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. |
|||
|
19 Jan 2010, 12:31 |
|
|
revolution 19 Jan 2010, 12:42
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. |
|||
|
19 Jan 2010, 12:42 |
|
|
f0dder 19 Jan 2010, 14:14
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. While being the same instruction, "ADD REG, REG" differs a lot in generated code from "registers[reg1] += registers[reg2]" . 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. - 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? |
|||
|
19 Jan 2010, 14:14 |
|
|
revolution 19 Jan 2010, 14:34
f0dder wrote: What kind of speeds do you find in today's ARM-based products? |
|||
|
19 Jan 2010, 14:34 |
|
|
f0dder 19 Jan 2010, 14:45
revolution wrote:
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 _________________  - carpe noctem |
|||
|
19 Jan 2010, 14:45 |
|
|
revolution 19 Jan 2010, 14:48
hopcode wrote: Will future versions of Fasm include Itanium instructions set ? I would be interested to see how you handle the instruction bundling. |
|||
|
19 Jan 2010, 14:48 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|