flat assembler
Message board for the users of flat assembler.

Index > Heap > AMD64 screwed our future for next 20 years? Or the eternity

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
donkey7



Joined: 31 Jan 2005
Posts: 127
Location: Poland, Malopolska
donkey7
tomasz:
i didn't mean separate chips or one chip. you can eventually enclose entire motherboard in one chip Smile
i meant separate logical units, like in cell. there are eight separate specialized fpus, but everything is placed on a one common die.

revolution:
if big amount of registers caused itanium to fail, why modern x86 cpus have register renaming, out-of-order buffers, huge buffers for brach prediction, etc. itaniums are expensive due to large caches and some non-objective reasons.
Post 18 Nov 2006, 16:34
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: 17284
Location: In your JS exploiting you and your system
revolution
Quote:
if big amount of registers caused itanium to fail, why modern x86 cpus have register renaming ...
Because there is no automatic register renaming, the 128 registers have replaced such mechanisms. The programmer is completely responsible to allocate the registers in an efficient manner. So the code becomes very complex and difficult to write. Without the programmer "liking" to program the chip, there will be less sales and thus the chip is considered a failure. Note that my reasoning is not about technical measures, the Itanium (and other 64bit CPU's) might well be technically superb, but when less people buy them that will push up the price and make them undesirable in general.
Post 19 Nov 2006, 00:24
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
revolution: but compilers could finally generate better code than people Wink
Post 19 Nov 2006, 12:27
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17284
Location: In your JS exploiting you and your system
revolution
vid wrote:
but compilers could finally generate better code than people
Haha, maybe, but you can always find some improvement over a compiler because you know what you need to achieve. Compilers are limited by the structure of the language.
Post 19 Nov 2006, 12:58
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
Now, the non-preservation-of-high-32-bits thing was done for performance reasons (it is easier to keep the processor fast by updating all bits together. As we know, x86 users in general are performance sensitive, so AMD knew they had to keep performance high.

It's even more than this. For example, it already happened to me a few times to copy some bunch of 32-bit code and execute in long mode without changes - voila! It's working! I don't have to change ECX into RCX when setting up the LOOP or REP, I don't have to change ESI into RSI when setting up address for LODSB, as long as all my data fits into low 4 GB anyway... In fact large pieces of code will work flawlessly in long mode even unchanged on the binary mode! (As this time you need a prefix to change instruction into 64-bit, 32-bit is still default - this also makes previously mentioned changing ECX into RCX completely unprofitable.
When I was first reading the x86-64 manuals (that's how they were called these days), that was exactly my though - that many pieces of machine code would work without any modifications. Much later, when I got 64-bit machine, I tried it - and got confirmation. This is also "amortizating" many possible mistakes when moving some your 32-bit code into 64-bit world. I considered it a very wise design.
Post 19 Nov 2006, 12:59
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
revolution wrote:
vid wrote:
but compilers could finally generate better code than people
Haha, maybe, but you can always find some improvement over a compiler because you know what you need to achieve. Compilers are limited by the structure of the language.

sure, for small things. But i doubt that some large-scale maintainable assembly project could beat optimized C code Sad
Post 19 Nov 2006, 13:24
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17284
Location: In your JS exploiting you and your system
revolution
vid wrote:
... i doubt that some large-scale maintainable assembly project could beat optimized C code
But in the general case only a few percent of code can benefit from assembly optimisation. Most programmers don't want to spend extra time optimising 90%+ of code that is only executed a few times.
Post 19 Nov 2006, 13:56
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
But in the general case only a few percent of code can benefit from assembly optimisation

not really... unoptimized asm is still faster than unoptimized C. because you create program flow in way natural to processor, and because you don't have abstractions thathide complexity behind them.
Post 19 Nov 2006, 16:30
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17284
Location: In your JS exploiting you and your system
revolution
vid wrote:
unoptimized asm is still faster than unoptimized C
But you forgot to factor in the the extra time for the programmer. Overall it is less efficient to have the programmer spend a few weeks extra doing assembly only to save a few (milli)seconds during runtime. This is why is it good practice (in a commercial sense) to pick just the hot-spots to optimise to get the maximum benefit. For hobbyists, like many here, this is not an important consideration, but most processors are bought by companies therefore that is the main focus of how a processor is used.
Post 19 Nov 2006, 22:38
View user's profile Send private message Visit poster's website Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
You forget something Wink

That programming in ASM si actually much faster than programming in C/C++ or higher level languages...

The fact that it "is slow to develop" and it has to be done for saving some "extra milisecconds" is a myth promoted by HLL programmers and managers...

In fact it is much faster because of the simplicity of the concepts involved, faster learning curve, clear and simple syntax. If approached with honesty and nearby a menthor that is.

Only if you "think in HLL" you will consider such "slow assembly myths"... after all inorder to be fair to this language you must "think in ASM" an you can not do that when you are biased towards HLL.

As one that has huge professional experience in both HLL C/C++ and ASM with huge applications and projects --> I can swear on my soul that in similar situations ASM is 4 upto 10 times faster to develop than HLL.

Honestly there are other disadvantages to ASM... like portability... this portability issues is a true problem and it can not be considered a myth. But with an Intel like architecture instaled on majority of the systems it losses some strength for desktops. Then each assembler has a slightly different syntax, there is no standard library, no ANSI ASM standard... not many real proffessionals to choose from...

We have done HostileEncounter game in essentially 6 months in a team of 2 (sometimes 3) assembler programmers. Only I knew ASM at the time. None of us knew Windows or DirectX. We had no RadASM and code completion or syntax highlighting tools essentially using notepad like text editors.

On the other side it took Blizzard a team of 20+ experienced C/C++ programmers, a budget of millions of US$, and 3 full years to do the same... not to mention the management and other resources: at the time we have started we only had one pentium 2 PC...

So please give me a break with the speed of HLL development...

Of course that when it is the ONLY commercially and managerial and finnancially and suported type of professional development... yeah it is faster Razz than no other ... alone in the race ...sometimes it gets the first place Razz

Ah, and by the way... AMD did the right thing to do

_________________
"Any intelligent fool can make things bigger,
more complex, and more violent.
It takes a touch of genius -- and a lot of courage --
to move in the opposite direction."
Post 20 Nov 2006, 20:52
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
C is not assembly, but it uses assembly behind your back. How is that better? Maybe you don't want to know. But, it's still there being used whether you like it or not. C can't exist without assembly, but you (the programmer) can.

Of course, most of us wouldn't write quite everything in assembly (.BAT files, makefiles, Perl scripts, etc.). That's just normal behavior. Why climb the stairs when you can take the elevator? (exercise? elevator broken? to avoid the awkward stares from coworkers? Laughing)

(P.S. Octavio is another prolific/diligent programmer who is much better in assembly than C, and he gets more done by 9am than most C programmers do all day!).
Post 20 Nov 2006, 21:50
View user's profile Send private message Visit poster's website Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
amd long mode missed some of my favourite instructions : pusha popa
i know i can use macros, but the code size will increase.
x64 is a example of how natural evolution works with small changes.
But i would like a cpu with memory mapped registers (and many other changes),so more registers could be added transparently to software developpers.
About hll<->asm ,i started with basic,clipper,c anf finally select assembly
and don´t think is less productive at all,the main problem is the lack of libraries.Also is possible to do hll programing in assembly.
Post 21 Nov 2006, 12:50
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Ocatvio: you can neatly use libc in ASM
Post 21 Nov 2006, 13:09
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
vid wrote:
Ocatvio: you can neatly use libc in ASM

Yes assemblers can use code written in hll or libs but when you are a newbie and download some assembler package, it has no libraries and you don´t know how to link external libraries. Also many libraries are in a format that is not supported by the assembler or linker.
>rugxulo wrote:
>he gets more done by 9am
That´s because i program all night Smile
Post 21 Nov 2006, 13:34
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: 17284
Location: In your JS exploiting you and your system
revolution
bogdanontanu wrote:
That programming in ASM si actually much faster than programming in C/C++ or higher level languages...
Perhaps for you this is true, but for me, I find that a nicely crafted piece of asm code takes longer to write than a similar nicely crafted piece of HLL code[1]. For basic hacks though, for me, the development time is much the same for both.

For large projects it is very difficult to find enough good programmers all fluent in asm. C/C++ people are cheaper so I hire[2] the C/C++ people instead and do the so-called "dirty asm" myself. Works well for me 'cause I much prefer asm over HLL and from my perspective the "cheaper" staff can do the boring HLL stuff Smile

[1]However I realise that there may be some bias in that measurement, because I only focus on doing the "more important" parts of code in asm, so that may influence the extra time I spend to get it running well.

[2]No, sorry, I am not hiring just now, please don't PM me looking for a job.
Post 21 Nov 2006, 14:26
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Ocatvio: that's true... that's why i am working on FASMLIB right now Wink
Post 21 Nov 2006, 15:20
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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 can 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.