Apollo Maggie 3D Chip - Preview Demo

[BeamCoder]

About compiler vs hand-code assembly in x86, this might be interesting to some of you http://www.codersnotes.com/notes/beating-the-compiler/

[Mathesar]

of course, we are talking about optimizing code for a 060 or 080 chip here. But these are all "microcontroller" class cpu's in today's world.

Does anyone know Lofar? operated by Astron in the Netherlands? LOFAR is basically a very big phased array radio telescope. At the core is an IBM Blue Gene/P supercomputer. And the core functions in this machine are programmed in assembler : (see last 2 paragraphs of section 2: https://www.astron.nl/~romein/papers...S-11/lofar.pdf
They claim their assembly code is often an order of magnitude faster than C++ code.

[meynaf]

Originally Posted by mschulz

That depends. Consider a case combining modern CPU (say some aarch64) and compiler. Now, I am pretty sure you can write good code by hand for it, but you need to study the architecture of the model you are exactly using. Worth reading are also optimization guides. Then you write a code which is, let's say, optimal for the cortex-a53 you had. But, once someone will change it to cortex-a76 you would need to re-write your code considering the optimization guide for this very model. Not because the cortex-a53 code will be bad, but rather because a76 offers new/better/more efficient optimizations.

Once when I was working on PowerPC AROS I had to dive deeply into PPC assembly. I wrote nice looking code which was easy to understand and to follow. Then I took the optimization guides for PPC and improved performance of the code. It did work better yet was harder to read, harder to follow and not so nicely written, anymore.

Oh, so you're using the old classical "compilers know more about the cpu than asm programmers".
But alas for you, this is irrelevant.
Your code after compilation will have to run on a variety of devices, not all having same cpu model of course. So compiled code is hardly ever targeted at anything but "generic" model ; in addition compilers can't support all of them due they are just too numerous (guess what, VS2015 does not list my Intel Core i7 4710Hq in available targets).

Originally Posted by mschulz

What helps you while writing in m68k assembly is the (rather sad) fact that the architecture is already very archaic and, until vampire came out, not updated. Had it evolved as any other CPU architecture, then you would have hardly chance to write as effective code as compiler can do for you.

Well, not really. Powerful OoO cpus are not that much dependent on instruction ordering anymore, if at all. Optimizing for them isn't as complicated as it looks, just don't do stupid things.
You also missed that an important point for a new cpu to have success in the market is its ability to faster run existing code.

Originally Posted by mschulz

you remember wrong. 32-bit arm as well as 16 bit thumb can read/write 16 bit data as well as 8 bit data.

LDR/STR instructions don't appear to be able to do that.
What is exact syntax ? Any online doc i can check for this ?

Originally Posted by mschulz

I bet compiler would copy them to some callee saved registers and later on performed the multiplication there.

And generate both a save and a copy that an asm programmer wouldn't have needed to do...

Originally Posted by mschulz

This already shows how biased your opinion on compilers is...

It is not bias, it is experience.
Of course by studying very small code you're doing cherry picking - and it's not as if i hadn't already written that the bigger the program is, the worse it becomes.

Originally Posted by BeamCoder

About compiler vs hand-code assembly in x86, this might be interesting to some of you http://www.codersnotes.com/notes/beating-the-compiler/

So x86 code that's small (i repeat myself here !) and written without much care is still significantly faster than compiled code. What a discovery.

[Promilus]

@Mathesar - ARM Cortex M processors go up to several hundred of MHz so even if they didn't have as good execution stage (which I believe newest Cortex M do) they would obviously outperform AC68080 due to sheer frequency difference. And yes. Those do have FPU and SIMD as well.
And be mindful of what article presented by BeamCoder had in a summary

So while you might be able to squeeze a little more speed out, it's probably not worth the maintenance hassle

While there might be niches where it does much better but overall in consumer software it just isn't true and it wasn't for more than 2 decades now. It just isn't the way you approach any big project. Even LOFAR does use asm only at compute intensive kernels. Software supervising whole effort is written in high level language. And this isn't any new approach. ASM has it's uses but it's rather silly to assume you can't do this or that on x86 because it's ASM sucks but you should do everything in asm on 68k because their compilers sux and asm is so developer friendly.

[Bruce Abbott]

Originally Posted by Mathesar

Meynaf is right in some cases, but it is more of a processor problem than a compiler problem. I am a hardware developer and most of my coding is in ANSI C for embedded processor which nowaday means ARM.

Even more off-topic. I could talk about all the contortions needed to avoid using asm on microcontrollers, but what would be the point?

When programming for the Amiga we need to produce 68k code one way or another. Some of us are so fluent in 68k assembler that we find it easier and more enjoyable than C for the stuff we are doing. "Oh, but it's not serious stuff", you say. The computer gaming industry was worth over $200 billion last year, which is pretty serious money. But people aren't playing computer games to be serious - we do it for fun, which is what makes our lives worth living. My neighbor spends most of her time watching sport on TV, while I spend my time programming my Amiga in assembler. Try to dismiss either of our choices and you will get the same response - you will not tell us how we should be enjoying life.

Any talk about what MCU or PC architecture is 'it' today is irrelevant, as is how efficient the compilers made for them might be. Those of us who program in assembler for the Amiga need a CPU that runs 68k code. Apollo accelerators give us that. Of course we want them to be nice and fast, and we may indulge in comparisons with other CPUs like x86 and ARM for laughs, but in the end it is writing beautiful 68k code that makes us happy. Telling us that ARM or x86 systems are much more powerful etc. is pointless. We know that, and we don't care - just like I don't care that my neighbor 'wastes' the remaining days of her life watching golf on TV. If that's what makes her happy then it's perfectly valid. If I want to 'waste' my time programming in 68k assembler for a 25 year old home computer, that's equally valid.

We came here to discuss exciting new Amiga developments, not get into yet another stupid debate about how it stacks up against modern systems. If that's what we were interested in we wouldn't be here.

[meynaf]

Originally Posted by Promilus

Software supervising whole effort is written in high level language.

Perhaps this is why there are so many security holes...

Originally Posted by Promilus

ASM has it's uses but it's rather silly to assume you can't do this or that on x86 because it's ASM sucks but you should do everything in asm on 68k because their compilers sux and asm is so developer friendly.

I only assumed it's not worth the effort on x86 and perfectly doable on 68k.

[Bruce Abbott]

Originally Posted by Promilus

It depends heavily on which optimization is chosen and how exactly code is written. If I use int8_t or char it WILL work with byte operations should optimization be none or size only. Weird things start to happen when -O2 or O3 is chosen.

This is what I love about C compilers - not.

[tygre]

Originally Posted by Bruce Abbott

Even more off-topic. I could talk about all the contortions needed to avoid using asm on microcontrollers, but what would be the point?

When programming for the Amiga we need to produce 68k code one way or another. Some of us are so fluent in 68k assembler that we find it easier and more enjoyable than C for the stuff we are doing. "Oh, but it's not serious stuff", you say. The computer gaming industry was worth over $200 billion last year, which is pretty serious money. But people aren't playing computer games to be serious - we do it for fun, which is what makes our lives worth living. My neighbor spends most of her time watching sport on TV, while I spend my time programming my Amiga in assembler. Try to dismiss either of our choices and you will get the same response - you will not tell us how we should be enjoying life.

Any talk about what MCU or PC architecture is 'it' today is irrelevant, as is how efficient the compilers made for them might be. Those of us who program in assembler for the Amiga need a CPU that runs 68k code. Apollo accelerators give us that. Of course we want them to be nice and fast, and we may indulge in comparisons with other CPUs like x86 and ARM for laughs, but in the end it is writing beautiful 68k code that makes us happy. Telling us that ARM or x86 systems are much more powerful etc. is pointless. We know that, and we don't care - just like I don't care that my neighbor 'wastes' the remaining days of her life watching golf on TV. If that's what makes her happy then it's perfectly valid. If I want to 'waste' my time programming in 68k assembler for a 25 year old home computer, that's equally valid.

We came here to discuss exciting new Amiga developments, not get into yet another stupid debate about how it stacks up against modern systems. If that's what we were interested in we wouldn't be here.

Well said, +1

[Bruce Abbott]

Originally Posted by mschulz

What helps you while writing in m68k assembly is the (rather sad) fact that the architecture is already very archaic and, until vampire came out, not updated.

What's 'sad' about it?

Had it evolved as any other CPU architecture, then you would have hardly chance to write as effective code as compiler can do for you.

Lucky for us that didn't happen. Or actually it did, but we lost interest when the 'evolution' made later 68k processors incompatible.

[Mathesar]

Originally Posted by Promilus

@Mathesar - ARM Cortex M processors go up to several hundred of MHz so even if they didn't have as good execution stage (which I believe newest Cortex M do) they would obviously outperform AC68080 due to sheer frequency difference. And yes. Those do have FPU and SIMD as well.
And be mindful of what article presented by BeamCoder had in a summary
While there might be niches where it does much better but overall in consumer software it just isn't true and it wasn't for more than 2 decades now. It just isn't the way you approach any big project. Even LOFAR does use asm only at compute intensive kernels. Software supervising whole effort is written in high level language. And this isn't any new approach. ASM has it's uses but it's rather silly to assume you can't do this or that on x86 because it's ASM sucks but you should do everything in asm on 68k because their compilers sux and asm is so developer friendly.

I hear what you are saying. I'm in the same boat. I don't do ANY assembly code anymore nowadays. The compiler is doing a good enough job in 99.9% of the cases. It's just that, on occasion, I do had to tune my C-code a bit to massage the compiler in producing efficient code or use special, optimal instructions like ARM's SMLAL.
I am sure LOFAR's efforts had to do with SIMD instruction to get the most out of the FPU. And that is one niche where assembler might be beneficial.

[mschulz]

Originally Posted by meynaf

Oh, so you're using the old classical "compilers know more about the cpu than asm programmers".

Far from it. I've been coding in assembly for half of my life (m68k, x86, x86_64, ppc, arm, aarch64) and I loved it. Even now I still enjoy it. What I was trying to say is not that compiler knows more, but rather that for a human being the amount of information increases and, at some point, the speed increase is not worth the effort. Unless you do that for pleasure, then, there you go!

Originally Posted by meynaf

Your code after compilation will have to run on a variety of devices, not all having same cpu model of course. So compiled code is hardly ever targeted at anything but "generic" model ;

Sure, but if you need more targeted optimizations in case of C it's a matter of change in compilation flags, only.

Originally Posted by meynaf

You also missed that an important point for a new cpu to have success in the market is its ability to faster run existing code.

They usually do run existing code faster but, when you read optimization guides, they offer you ways of doing things even faster.

Originally Posted by meynaf

LDR/STR instructions don't appear to be able to do that.
What is exact syntax ? Any online doc i can check for this ?

Because LDR/STR is per definition for loading/storing a 32bit word. The instructions you are looking for are LDRH/STRH/LDRB/STRB.

Originally Posted by meynaf

And generate both a save and a copy that an asm programmer wouldn't have needed to do...

And you wrote few lines below about cherrypicking and small code portions. Well, in bigger projects you have to have a common procedure calling convention, no matter if using high level languages or not. In that case you will get to a point where you need scratch register and need to store/restore them.

Originally Posted by meynaf

Of course by studying very small code you're doing cherry picking - and it's not as if i hadn't already written that the bigger the program is, the worse it becomes.

[phx]

Originally Posted by Bruce Abbott

We came here to discuss exciting new Amiga developments, not get into yet another stupid debate about how it stacks up against modern systems. If that's what we were interested in we wouldn't be here.

Thanks!

I already wanted to write something similar. Most of the discussion here is absolutely pointless and I wonder what your intentions are, being registered to an Amiga forum?

Amiga developers have fun working with the limitations of their hardware. And for that the code size, CPU and assembly-level optimizations are certainly a part of it.

BTW, I cannot believe that anybody who is objective enough (so neither nonarkitten, nor meynaf, nor me), would think the x86 ISA is better than m68k.

[meynaf]

Originally Posted by mschulz

Far from it. I've been coding in assembly for half of my life (m68k, x86, x86_64, ppc, arm, aarch64) and I loved it. Even now I still enjoy it. What I was trying to say is not that compiler knows more, but rather that for a human being the amount of information increases and, at some point, the speed increase is not worth the effort. Unless you do that for pleasure, then, there you go!

Well, correct code optimization isn't about micro-optimization targeting a specific cpu. It starts by writing nice code that will run well on all the cpu range the program must work on. So i favor short code, and the fact it runs blazingly fast is a nice side-effect. The coding pleasure is another. At least it's short on every cpu it has to run on, and, yes, probably, it could be made slightly faster by adapting on some specific cpu model but this is usually not worth.
Besides, writing cpu specific code makes implementation visible in the programming model - which is something i don't want to do.

Originally Posted by mschulz

Sure, but if you need more targeted optimizations in case of C it's a matter of change in compilation flags, only.

If you need, but the problem is precisely that you actually don't.

Originally Posted by mschulz

They usually do run existing code faster but, when you read optimization guides, they offer you ways of doing things even faster.

Ways that you can't really use because your code will still need to run well enough on older machines.

Originally Posted by mschulz

Because LDR/STR is per definition for loading/storing a 32bit word. The instructions you are looking for are LDRH/STRH/LDRB/STRB.

Ok, so it seems i missed them because they appeared in ARMv4 and weren't originally there. That doesn't make the point less OT, though

Originally Posted by mschulz

And you wrote few lines below about cherrypicking and small code portions.

Well, it's not me who originally gave the example.

Originally Posted by mschulz

Well, in bigger projects you have to have a common procedure calling convention, no matter if using high level languages or not. In that case you will get to a point where you need scratch register and need to store/restore them.

Some coders do that, but not me. I prefer being modular and use adaptative register allocation.

[meynaf]

Originally Posted by phx

BTW, I cannot believe that anybody who is objective enough (so neither nonarkitten, nor meynaf, nor me), would think the x86 ISA is better than m68k.

Well, i even once found a guy who defended the idea that ARM (32-bit) ISA was better than m68k

[Thomas Richter]

Originally Posted by meynaf

You sure do, but it is OT not only on this thread but also on this whole site.

No, why. Software development is not OT. You may not care about how to do it, though, but that doesn't make it irrelevant. Nobody is wasting time with assembler today. Rarely ever.

Originally Posted by meynaf

If you don't care about the details, you also can't read it fine (you can read it, but not fine).

Actually, you don't know what I know - I know the instructions, I know what they do. I just don't write code in assembly, it doesn't make sense.

Originally Posted by meynaf

You could benchmark my flac decoder and my picture viewer, for example.
Good luck with your compiled code to even approach their performance.

Not good luck - the problem is that you don't know your way on modern machines. You could also benchmark my JPEG XS, good luck with that with your assembler on 68K.

Originally Posted by meynaf

I don't have this approach for business software, obviously, as such software won't use 68k at all and i clearly don't want to mess with x86 or whatever asm.

But that's a quite limited view, actually. You're telling me "assembler is fine", yet you care only about an outdated architecture rarely anyone else cares about.

Originally Posted by meynaf

With me in the team, the project won't go overly large.

How large a project goes is not on you. It is on the requirements of the product owner what the project should do. Is AmigaOs large, for example? Probably not by today's standards, but it is large enough for not wasting everybodies time with assembler.

Originally Posted by meynaf

What you are creating with your "large" projects is actually just waste, aka bloatware.

Yet, you are writing this very post on bloatware, using bloatware, depending on bloatware. This is probably some html engine, with some javascript client side, plus PHP serverside underneath (I don't know), so there is a lot of code already. And, guess what, my bet is that nothing of that was written in assembler, probably with the exception of some of the very low level parts of the Os you're using, and the server is using providing the page.


If that's all such a waste, why are you wasting your time with the waste?

Originally Posted by meynaf

But even. Complexity of a project shouldn't raise much with its size, there is something called modularity to cope with that.

TADA! And for modularity, you need tools to organize the code, and that's why we have compilers and linkers. Modularity is the key, organization is the key. Not code size. Size is irrelevant, structure is relevant.

Originally Posted by meynaf

Actually, a good asm program has more structure than with your average compiled code, simply because it's less tolerant to bad programming.

Tells me the guy who refuses to use includes and labels. Yeah, right...

Originally Posted by meynaf

No. Totally wrong. In asm the code indicates the signedness and is unambiguous.

Nope:

move.l d0,d2

Is d0 signed or unsigned? It could be an implicit type conversion, or a pointer to int conversion, or whatever. There is nothing to see here, and nothing to warn.

Originally Posted by meynaf

While the C compiler doesn't say a thing if you keep the default signed data type on something that should obviously be unsigned.

That's an implicit type conversion, and yes, C is prone to them. Other languages not. It will fortunately tell you many, though not all cases. Signed to unsigned comparisons compilers will be typically able to identify and warn you about.


In assembler: Nobody warns you whatsoever for the above code if d0 can be negative, but d2 is a count can must be non-negative. Nothing happens. Either you know, or you shoot yourself in the foot. In which way this is any better I do not know.

Originally Posted by meynaf

I'm not watching recent developments for x86 or whatever, if it's what you meant.

But you should. Or arm, or whatever. This is where development happens. Not here in 68K land, that's just toy code.

Originally Posted by meynaf

Nope. Cache friendly code uses as small data as possible, and only asm does this fine.

Cache friendly means small data, yes, but good data organization. If you want to get such things fast, you're not writing assembly today. It's all about vector instructions, compiler intrinsics. The code the compiler generates from that is usually better than what you write by hand. Of course, you need to tell the compiler in the right way, and use the right data types for it. I''m not suggesting using "unsigned char" just because its small. But the appropriate vector of N unsigned characters which you can pipe through in parallel SIMD way.

Originally Posted by meynaf

Having the right architecture is of course mandatory but you won't see if your architecture is right or not by just trusting what the compiler does.

That's why I'm reading the code the compiler generates for me, and then potentially tune it. I'm not writing this stuff by hand anymore. Compilers today can do auto-vectorization, loop unrolling, flow analysis and other neat tricks, and there have been cases where hand-optimizing the code went nowhere because the compiler just knew better what's fast and what isn't.

[meynaf]

Originally Posted by Thomas Richter

No, why. Software development is not OT. You may not care about how to do it, though, but that doesn't make it irrelevant. Nobody is wasting time with assembler today. Rarely ever.

May i recall you on which site you are ?

Originally Posted by Thomas Richter

Actually, you don't know what I know - I know the instructions, I know what they do. I just don't write code in assembly, it doesn't make sense.

Knowing the instructions is not enough to be able to properly read code.

Originally Posted by Thomas Richter

Not good luck - the problem is that you don't know your way on modern machines. You could also benchmark my JPEG XS, good luck with that with your assembler on 68K.

"modern machines" are completely OT here.
As i suppose there is no 68k version of your JPEG XS, you're comparing apples and oranges.

Originally Posted by Thomas Richter

But that's a quite limited view, actually. You're telling me "assembler is fine", yet you care only about an outdated architecture rarely anyone else cares about.

This whole site is about said outdated architecture...

Originally Posted by Thomas Richter

How large a project goes is not on you. It is on the requirements of the product owner what the project should do.

If you're the project manager, it is.

Originally Posted by Thomas Richter

Is AmigaOs large, for example? Probably not by today's standards, but it is large enough for not wasting everybodies time with assembler.

AmigaOs is large but it consists of many independent modules, some of which are in asm. Taken individually, these modules aren't however very big. I could perfectly have rewritten them in asm if i wanted to.

Originally Posted by Thomas Richter

Yet, you are writing this very post on bloatware, using bloatware, depending on bloatware. This is probably some html engine, with some javascript client side, plus PHP serverside underneath (I don't know), so there is a lot of code already. And, guess what, my bet is that nothing of that was written in assembler, probably with the exception of some of the very low level parts of the Os you're using, and the server is using providing the page.

Sure, but it does not work very well overall if you look at details and compare with what the machine is supposed to be able to do on paper.
Yeah, that very same "sane" software that adds bogus newlines in your posts here (and you don't appear to care about).

Originally Posted by Thomas Richter

If that's all such a waste, why are you wasting your time with the waste?

Because there is nothing else available on the market.

Originally Posted by Thomas Richter

TADA! And for modularity, you need tools to organize the code, and that's why we have compilers and linkers. Modularity is the key, organization is the key. Not code size. Size is irrelevant, structure is relevant.

Tools won't organize the code at your place.

Originally Posted by Thomas Richter

Tells me the guy who refuses to use includes and labels. Yeah, right...

Correction : the guy who refuses to misuse includes and labels. There are labels and include directives in my code - just not the ones that i regard as inadequate.

Originally Posted by Thomas Richter

Nope:

move.l d0,d2

Is d0 signed or unsigned? It could be an implicit type conversion, or a pointer to int conversion, or whatever. There is nothing to see here, and nothing to warn.

If this is a joke it's a very poor one. It's quite obvious that this instruction can not cause a bug - it will work just fine regardless of signedness.
And no, it's not a type conversion. It's a longword and remains a longword.

Originally Posted by Thomas Richter

That's an implicit type conversion, and yes, C is prone to them. Other languages not. It will fortunately tell you many, though not all cases. Signed to unsigned comparisons compilers will be typically able to identify and warn you about.

A compiler will warn you if you mismatch signed and unsigned, but it can't do this with a constant (unless you explicitly ask for it).
In asm, otoh, you write different instruction.
You write blo for unsigned, blt for signed. Mere "<" is misleading.

Originally Posted by Thomas Richter

In assembler: Nobody warns you whatsoever for the above code if d0 can be negative, but d2 is a count can must be non-negative. Nothing happens. Either you know, or you shoot yourself in the foot. In which way this is any better I do not know.

A compiler won't warn you either if a values goes out of range during execution.
Worse, C codes declares signed overflow as undefined !

Originally Posted by Thomas Richter

But you should. Or arm, or whatever. This is where development happens.

Why would i care ? Compilers are here to hide these details. If i wanted to see x86 code, i would write x86 code.

Originally Posted by Thomas Richter

Not here in 68K land, that's just toy code.

Yeah, toy code. This has become your motto here.
But toy code is at least nice and enjoyable.

Originally Posted by Thomas Richter

Cache friendly means small data, yes, but good data organization. If you want to get such things fast, you're not writing assembly today. It's all about vector instructions, compiler intrinsics. The code the compiler generates from that is usually better than what you write by hand. Of course, you need to tell the compiler in the right way, and use the right data types for it. I''m not suggesting using "unsigned char" just because its small. But the appropriate vector of N unsigned characters which you can pipe through in parallel SIMD way.

Again, i'm not writing x86 asm (or arm asm), only good old 68k - so no vector instructions.

Originally Posted by Thomas Richter

That's why I'm reading the code the compiler generates for me, and then potentially tune it. I'm not writing this stuff by hand anymore. Compilers today can do auto-vectorization, loop unrolling, flow analysis and other neat tricks, and there have been cases where hand-optimizing the code went nowhere because the compiler just knew better what's fast and what isn't.

Then you are missing the point about what a compiler is for. It is an abstraction around the cpu, allowing to write portable code.

[dreadnought]

Alright guys, if I have to hit PageDown 3 times to get through just one reply it's probably time to let go.

[Gorf]

Originally Posted by meynaf

May i recall you on which site you are ?

A site that discusses not only hobby projects, but also e.g. new releases of the operating system and commercial releases of games.
This site is clearly not opposed to larger more professional projects, even if these are rare now.

"modern machines" are completely OT here.

Why?
There is AROS and UAE on very modern machines and there is AmigaOS4 and MorphOS on middle-aged machines.

As i suppose there is no 68k version of your JPEG XS, you're comparing apples and oranges.

Amiga is not only 68K but also PPC, x86 and ARM now

This whole site is about said outdated architecture...

Is it?

The Retrogaming section is about
"retro-gaming world in general."
And games for all kinds of platforms are discussed there.

And there is a "Coders. Nextgen" section for "Develop for the sequels: PowerPC Amigas, AROS, Amithlon..."

The only thing that is probably really OT is a discussion High Language vs. Assembly in an announcement about a new 3D-FPGA-unit in the News section

[meynaf]

Originally Posted by Gorf

A site that discusses not only hobby projects, but also e.g. new releases of the operating system and commercial releases of games.
This site is clearly not opposed to larger more professional projects, even if these are rare now.

Business projects on Amiga hardware today, stay serious.

Originally Posted by Gorf

Why?
There is AROS and UAE on very modern machines and there is AmigaOS4 and MorphOS on middle-aged machines.

Running emulators on a machine and coding on it, are two different things.

Originally Posted by Gorf

Amiga is not only 68K but also PPC, x86 and ARM now

This has nothing to do with the point in question.

Originally Posted by Gorf

Is it?

The Retrogaming section is about
"retro-gaming world in general."
And games for all kinds of platforms are discussed there.

And there is a "Coders. Nextgen" section for "Develop for the sequels: PowerPC Amigas, AROS, Amithlon..."

Those all kinds of platforms are still outdated. Anyway, Thomas's point isn't about gaming...

Originally Posted by Gorf

The only thing that is probably really OT is a discussion High Language vs. Assembly in an announcement about a new 3D-FPGA-unit in the News section

Tell that to the other guy, not me.

[Promilus]

@meynaf

I could perfectly have rewritten them in asm if i wanted to

And that kind of attitude (along with who actually hold rights for it) was an obstacle to use fairly cheap and powerful back then V4e Coldfire processor in Amiga or move on with PPC.

It's a longword and remains a longword

Exactly, you have to know (& remember) what it represents. For all you care it can be fixed point (which doesn't have native implementation in 68k and any other processor I know except some TI DSP) and you have to know it.

Then you are missing the point about what a compiler is for. It is an abstraction around the cpu, allowing to write portable code

No, compiler is just to translate from high level language (which holds that portability and abstraction) to machine language and while doing so optimize some things. And it increasingly does exactly that. Once good AI will be implemented to compilers you can say bye bye to even hand tuning. And there's already work on that.
And HLL isn't only about abstraction layer and portability. It's also about efficiency, convenience etc.