OT - assembler versus C for Amiga development

[Franko]

OT discussion continued from here: http://www.amiga.org/forums/showthread.php?t=58923

@ Jose @ Golem

Afraid C is not the programming language for me for the simple reason that Golem said the generated code is waaay bigger (normally increasing the size by a third at least) and it's a lot slower and highly inefficient...

I know a lot of folk back in the day who tried C and it's variants but they could never produce the results they wanted with it, especially when working with fast moving gfx and most of them ended up coming back to assembler...

Assembler to me personally is very easy and simple to understand and use and much easier to follow when writing large pieces of code but best of all you get the absolute best speed and efficiency from you code at the end of the day on the Amiga that's what's important...

[Franko]

That's not a problem with the language, that is a problem with the compiler.  If Sidewinder and I can get Clang to work on AROS 68k, we'll have a bit newer compiler technology and maybe we'll get closer to parity with Assembly developers.

One example is that sometimes assembly programmers could pack 2 words in a long variable to get better register loading.  Clang does this if you use the PBQP register allocator.  I don't know of any existing Amiga compilers that do this.

Whether it's the language itself or the compiler, it make no difference...

C and it's derivatives will always produce larger code and will never be as efficient in terms of speed as something written in pure assember...

Way, way back we used to have this argument all the time especially with mates who went to Uni and for whatever reason they had to learn C. They would produce a bit of code in C on the Amiga claiming it was every bit as efficient as Assembler but ALWAYS those of us who coded in Assembler would prove this wrong by producing the same routine in Assembler smaller & faster...

The thing was back then most folk were using an unexpanded A500 (as it cost about 250 quid for a 512Mb ram board) so with just the chipmem available coding had to be as efficient and fast as possible for such machines...

It taught us to be very proficient and not to be lazy when coding something so that we could get the very best out of such small resources and to this day that has always been to me the way to do things on the Amiga, small, efficient and speedy...

[Franko]

Personally, I go for C(++) first, then anything that still isn't fast enough after reviewing algorithm changes and profiling I will look at writing assembler replacements for.

Some stuff just doesn't need optimizing. Basic IO, for example, is almost always going to be limited by the speed of the device being communicated with. Event handling is another example. No amount of assembler will basically speed up having to wait for an asynchronous event to happen.

The problem with assembly coding is that unless you keep absolutely up-to-date with each revision of your target architecture, you will always fall foul of bad assumptions in the end.

There are many clock cycle optimisations for the basic 68000 that are slower on the 68020. Likewise, once you master the 020's behaviour, a lot of it ends up being counter-productive on the 68040.

Then there are general changes in system architecture. On the cacheless 68000, precomputed lookup tables were king to speed up various complex operations. As processors have gotten faster in relation to memory, it often ends up quicker to evaluate the expression than it does to precompute it and perform memory lookups, unless you can arrange your precomputed data in a very cache friendly way.

Anyhow, this is somewhat off-topic.

While I see the points your making they are not exactly correct however...

Take for example something written for doing IO like an HD DOS driver or device. If you wrote that entirely in C it would be highly inefficient in comparison to coding it in assembler...

Sure not matter which method you choose to write your code in they both are restricted by hardware & the hardware bus and physical speeds of IO lines...

BUT that's not where it ends, as the actual code for shifting all this data back and forth is in the driver you write and if you write it in C and not in highly optimised assembler you lose speed overall as your routine performs it's code x amount of time per second...

No matter what you write and which version of the OS or processor you write it for at the end of day C will never outperform Assembler, proven fact and easy to prove...