Any reason to use assembly on the Amiga rather than C?

[jotd]

I enjoy coding games in asm on the amiga, my C++ attempt resulted in a slow game that I now have to rewrite. And I have some routines that I reuse, low level debugging shows exactly your code, high level debugging is pretty difficult with WinUAE.

I saw Bartman C/C++ env. it's impressive but anyone besides the original team use it ? It's good I mean they make great games/demos out of it, but on the miggy at least for games, I feel that asm is the natural way, specially if you're not intending to port anything to non-68k targets (which is my case). On the other hand, an asm toolchain is primitive but simple: vasm+notepad++ => done.

On the other hand, I wouldn't touch asm at work with a barge pole. Only C++, Ada and python there. And runs on Windows/Linux/ARM linux without a change and without UB either.

[Karlos]

Code written for Amiga in C, or even C++ doesn't have to be slow. It depends on how you write it. If you are making frequent allocations and deallocations and/or relying on a lot of runtime abstraction, you're making a conscious trade off. Usually the trade off is the flexibility and extensibility of your code versus the performance.

If you want to write games for 68K, I'd generally suggest doing it in C first and foremost and then profiling to see what needs optimising at a lower level. Optimisation should be algorithmic first. There's no point doing a suave assembler optimisation of a terrible algorithm that doesn't scale unless you know for a fact it doesn't need to and that a simple linear speedup is adequate. It's a lot easier to do algorithm optimisations in C and once you've got the best reimplement as assembler.

The alternative, doing everything in assembler, is something you do because you enjoy it. There aren't any really sensible arguments for it otherwise.

[jotd]

There is one actually: porting Z80 code to 68000 is way easier than porting to C.

I ported Bagman (C++/SDL) to amiga (keeping SDL interface but using only blitter & native modplayer/soundplayer internally) using Bebbos gcc and it was darn slow. I didn't try to optimize. Maybe I restored the background too much, maybe I checked too much things like bounds, etc... but it was slow. Now I only use Bebbos port of asm (gas).

[malko]

Originally Posted by Steam Ranger

It seems that with modern optimising compilers and cross-compilation tools noone could write code for the Amiga better than gcc can, is there any reason to use assembly over C in 2023 for the Amiga (beyond novelty)?

Considering your main question : Low level language assembled code will always be beyound the performances of high level compiled code. In this sole thread, all C defenders have admitted inside their posts that one have to switch to asm for critical part of applications. It therefore proves that C can not write better code than asm.

That they considerthe resulting compiled C code acceptable in term of speed and time spent in writing the code are aside the scope of your question.

At the end you have to choose and use the language you feel the best with and leave aside all others reasons.

[phx]

A good Amiga developer has to be fluent in both languages.

Without knowing C you will have a hard time to finish and maintain bigger projects, or write portable tools.

Without knowing 68k assembler your performance-critical code will never be as fast as it should be.

[Thorham]

Originally Posted by Thomas Richter

software engineer (as opposed to "coder")

Coder is just slang for programmer, and programmer is just the simple word for software engineer.

[Tigerskunk]

I am using ASM because that's what my coder heroes in the 80ies did...

Probably using C is a clever thing these days and highly recommended.

[meynaf]

Originally Posted by Thomas Richter

That's simply not the case with living software. You seem to (falsely) assume that a program is at a point "finished", and then you do not touch it anymore. That is rarely the case in practical applications. Customers come, have feature requests, want changes, report issues. Even on the Amiga.

If your program is never finished, your fault.

Originally Posted by Thomas Richter

Now, try to maintain an assembly program.

I've done it. Even ones i didn't have the original sources.

Originally Posted by Thomas Richter

No, that's neither true. The difference is that a high level syntax helps you to formulate design decisions (or encode them) such that the compiler can help you to verify that the interfaces in your code are used correctly. That is incredibly helpful on large programs.

Ah, large programs again. But we're on the Amiga, remember, where a good program shouldn't be "large".

Originally Posted by Thomas Richter

Nope. The first step of "debugging" higher level language code is to have the compiler check it for you. If it compiles, you already have a part of the deal. In assembler, nobody tells you whether whether you put the right arguments into the right registers.

Frankly, if you can't put the right arguments into the right registers, stop programming. This is really the easy part.
Now indeed if your program compiles, you have a big part of the deal - as changing something often leads to a heap of compilation errors.
Where in asm you can rewrite your code part by part and test them easily even if the rest of the code is wrong, try to do that in C (or worse, C++ with all those classes around).

Originally Posted by Thomas Richter

The point in "declarations" is to help you, not to struggle you. It provides a first level barrier for code checking.

Yes it is supposed to help me. But sometimes it just comes in the way.

Originally Posted by Thomas Richter

Then don't make them ints. There are reasons for data structures to express your intent. In assembler, a pointer is a pointer. In C, that is not the case. For reasons.

Replacing a simple int by a data structure sounds just crazy.
Yes in asm a pointer is a pointer, hopefully - and it allows using the pointed data the way you want. There can be reasons why in C that's not the case, but i can't see a good one.

Originally Posted by Thomas Richter

I don't know which kind of C or C++ you write...

This is reciprocal.

Originally Posted by Thomas Richter

That is the stupid way.

No. The stupid way is trusting the compiler too much.

Originally Posted by Thomas Richter

Why do you bother? I know what I know, and I do not run into problems with UB. Actually, my compiler warns me if the code depends on UB. Assembler does not. If I put a pointer of one data structure into a function argument for another data structure, nothing stops the assembler.

Putting a pointer of one data structure into a function argument for another data structure isn't UB in asm.
Again you must know what you are doing. Both structures may have a lot in common, and using same code for handling this common part is nice (C++ can do this to some extent, but not C).
Do this by mistake, and you don't need a compiler to warn you - the code will simply not work.
The problem in C is that just too many things are UB, and the compiler will not warn you for most of them : signed integer overflow, division by zero, out of array bounds access, null pointer dereference, modification of string literal. If you pass in several parameters to a function, you don't even know in which order they will be evaluated ! There is nothing like that in asm.

Originally Posted by Thomas Richter

War time story, from another thread just in this forum: Do you know why the CON: handler only hides its window instead of closing it when pressing the iconification button? Because nobody understands how the console.device operates. It is opaque assembly code. If that would have been C code with proper data structures, it would be relatively straight foreward to update the code such that the console character map can exist without its window, but the way how the code operates (in assembler) is just opaque, and it is somewhat documented. In the assembler programming style.

If you don't understand some code, ask for help.

Originally Posted by Thomas Richter

In other words: You have not yet had in contact to reality if you make such nonsense claims. Assembler code is to a good degree write-only code, probably understandable for its author. The expressiveness of the language (if you call it so) is not sufficient to document intentions of the author and encode it in the syntax. C is not perfect, but better. C++ is even better to formulate designs, but it already has "too many" features that can be easily misused to make thinks less readable rather than more readable.

You are asking the language to do things it's not its job to do.
You must document your intents with comments in your source. Code itself is poor documentation - always have, always will.
In many projects i've seen see whole sources without a hint on what they are for, the only comment in said sources being the license !

[saimo]

@Steam Ranger

Originally Posted by Steam Ranger

It seems that with modern optimising compilers and cross-compilation tools noone could write code for the Amiga better than gcc can, is there any reason to use assembly over C in 2023 for the Amiga (beyond novelty)?

"It seems": generic, impersonal and factless - whence did you get the notion of gcc beating any human mind in this specific case?

In relation to what others said, here are my experiences/thoughts.

To make the most of the limited resources of Amiga machines (especially the stock ones), assembly is required - for example, for SkillGrid I needed every byte and every CPU cycle, so I wrote it entirely in assembly.
When the constraints are not too tight, C and other languages can of course be used and, when needed, assembly can be used only for the most critical parts - for example, Ring around the World is mostly written in AMOS Professional (which is quite inefficient), but I wrote some graphics/calculations-heavy routines in assembly.
Also, assembly can used just for fun - for example, MeMO is written in 100% assembly, despite not requiring it at all, because I simply felt like so.

[Thomas Richter]

Originally Posted by meynaf

If your program is never finished, your fault.

Lack of professional experience, I call it. Face reality, this is the life of a software engineer (compared to a "coder").

Originally Posted by meynaf

Ah, large programs again. But we're on the Amiga, remember, where a good program shouldn't be "large".

The console.device is large enough to be incomprehensible.

Originally Posted by meynaf

Where in asm you can rewrite your code part by part and test them easily even if the rest of the code is wrong, try to do that in C (or worse, C++ with all those classes around).

I do that every day. Rewriting parts of the code, test them easily.

Originally Posted by meynaf

Replacing a simple int by a data structure sounds just crazy.

No, but replacing a couple of arguments to a function by a member function of some data structure is not, provided you organized your code logically.

Originally Posted by meynaf

Yes in asm a pointer is a pointer, hopefully - and it allows using the pointed data the way you want. There can be reasons why in C that's not the case, but i can't see a good one.

It's called "syntax checking" by the compiler. Again, lack of personal experience.

Originally Posted by meynaf

Putting a pointer of one data structure into a function argument for another data structure isn't UB in asm.

Unless you call "it does whatever it does" "defined behaivour. In C, it is "as defined as it is assembly". If you pass a pointer to the wrong structure, about everything can happen. That is called "UB".

Originally Posted by meynaf

The problem in C is that just too many things are UB, and the compiler will not warn you for most of them : signed integer overflow, division by zero, out of array bounds access, null pointer dereference, modification of string literal. If you pass in several parameters to a function, you don't even know in which order they will be evaluated ! There is nothing like that in asm.

Oh, a "division by zero" in C does exactly the same as in assembly. UB means: "the compiler does not define it". The environment does, probably, and the result is in both cases pretty much the same (surprise, surprise).


Same goes for "out of bounds accesses". The "same thing" happens in assembly and C. You trash memory. Oh, what a fun! Whereas, if you had used C++ and vector, you would have had the chance to detect the issue. Or if you had used proper abstractions in C such as "an array is not quite the right abstraction". Even in C you can write accessor functions, and do bounds checking there.


Well, yes, I understand, for assembly language authors the array is the only data structure, but there is really more to discover. (-;



Actually, these arguments are pretty silly - you complain that C does not react properly for errors you can do even easier in assembly. Of course, there are better languages than C. C++ is one I use on a daily basis.

Originally Posted by meynaf

If you don't understand some code, ask for help.

Whom? The authors of the console.device are missing, long retired, out of reach. There is "nobody to ask".

Originally Posted by meynaf

You are asking the language to do things it's not its job to do.

Helping you to write programs *is* the job of the language, and helping you to detect problems in the code is exactly the reason for languages and why we have them. Despite abstracting from the actual machine, of course.

Originally Posted by meynaf

You must document your intents with comments in your source. Code itself is poor documentation - always have, always will.

That depends. A well structured code requires less comments than an assembly language source.

Originally Posted by meynaf

In many projects i've seen see whole sources without a hint on what they are for, the only comment in said sources being the license !

Well, all I can say from your comments I can only judge that you haven't seen sufficiently many. I'm talking about "real life projects", not the average toy code.

[jotd]

did someone mention flame wars before?

[TCD]

Originally Posted by jotd

did someone mention flame wars before?

You know a simple 'each to their own' never works in this forum

[AestheticDebris]

Originally Posted by malko

Considering your main question : Low level language assembled code will always be beyound the performances of high level compiled code. In this sole thread, all C defenders have admitted inside their posts that one have to switch to asm for critical part of applications. It therefore proves that C can not write better code than asm.

That they considerthe resulting compiled C code acceptable in term of speed and time spent in writing the code are aside the scope of your question.

At the end you have to choose and use the language you feel the best with and leave aside all others reasons.

Optimal assembly will always beat or match everything else for pure performance. But not every developer is necessarily capable of writing optimal assembly and even those who can may find it takes longer to write/debug than writing the equivalent in a higher level language like C. Most of the time therefore, it is better to write in C and only worry about assembly for bits of code that turn out to be speed critical, not well optimized by the compiler and unsuitable for intrinsics.

Of course if you want to write assembly because you enjoy it, well then that's a whole other story.

[meynaf]

Originally Posted by Thomas Richter

Lack of professional experience, I call it. Face reality, this is the life of a software engineer (compared to a "coder").

Again we are talking about Amiga programming here. It has nothing to do with professional experience.
And i see you go into ad hominem once again.

Originally Posted by Thomas Richter

The console.device is large enough to be incomprehensible.

It shouldn't be real big. It fits in a small rom with lots of other things.

Originally Posted by Thomas Richter

I do that every day. Rewriting parts of the code, test them easily.

Yeah, sure.

Originally Posted by Thomas Richter

No, but replacing a couple of arguments to a function by a member function of some data structure is not, provided you organized your code logically.

And ?
This can be done in asm as well.

Originally Posted by Thomas Richter

It's called "syntax checking" by the compiler. Again, lack of personal experience.

Syntax checking is done by assemblers too. Now, type checking is something else.
And again, personal attack.

Originally Posted by Thomas Richter

Unless you call "it does whatever it does" "defined behaivour. In C, it is "as defined as it is assembly". If you pass a pointer to the wrong structure, about everything can happen. That is called "UB".

No it is not "UB". You will only access other data than what you expected to.

Originally Posted by Thomas Richter

Oh, a "division by zero" in C does exactly the same as in assembly. UB means: "the compiler does not define it". The environment does, probably, and the result is in both cases pretty much the same (surprise, surprise).

But if you rely on this, you lose portability - and thus the only advantage C might have on asm.

Originally Posted by Thomas Richter

Same goes for "out of bounds accesses". The "same thing" happens in assembly and C. You trash memory. Oh, what a fun! Whereas, if you had used C++ and vector, you would have had the chance to detect the issue. Or if you had used proper abstractions in C such as "an array is not quite the right abstraction". Even in C you can write accessor functions, and do bounds checking there.

Again what happens depends on the actual implementation, which shouldn't matter when writing HLL code.
And, even in asm you can write accessor functions and do bounds checking. My dynamic array functions do this.

Originally Posted by Thomas Richter

Well, yes, I understand, for assembly language authors the array is the only data structure, but there is really more to discover. (-;

I suggest you read about the RS directive.

Originally Posted by Thomas Richter

Actually, these arguments are pretty silly - you complain that C does not react properly for errors you can do even easier in assembly. Of course, there are better languages than C. C++ is one I use on a daily basis.

No way. It's very different. Some UB in C is perfectly defined in Asm and can even be useful.
Signed arithmetic overflow isn't "error" if you know what you're doing.
Out of bounds access can be shortcut to access nearby memory.
Altering string constant defined with DC directive is perfectly permitted and works just fine.
And so on.
UB in case of an error is something. UB in case of something that's actually useful is something else.

Consider using function call return values as parameters of another function call. In asm you perfectly know in which order these functions will be called.
Same if you read from a data stream with postfix operator.

Originally Posted by Thomas Richter

Whom? The authors of the console.device are missing, long retired, out of reach. There is "nobody to ask".

There are skilled coders here on the eab.

Originally Posted by Thomas Richter

Helping you to write programs *is* the job of the language, and helping you to detect problems in the code is exactly the reason for languages and why we have them. Despite abstracting from the actual machine, of course.

The job can be to ease coding, but not to do your work at your place.

Originally Posted by Thomas Richter

That depends. A well structured code requires less comments than an assembly language source.

Well structured code, in real life, does not exist.
Oh you will find programmers who pretend their code is. But it isn't.

Originally Posted by Thomas Richter

Well, all I can say from your comments I can only judge that you haven't seen sufficiently many. I'm talking about "real life projects", not the average toy code.

Nah, sorry, i've seen enough "real life projects" to know how they're made.
They're actually much worse than toy code.

And always remember this thread is about assembler on Amiga. Not about professionnal programming.

[Thomas Richter]

Originally Posted by meynaf

Again we are talking about Amiga programming here. It has nothing to do with professional experience.

Not? If only "coders" are left, it's indeed dead.

Originally Posted by meynaf

Syntax checking is done by assemblers too. Now, type checking is something else.

Not quite. If I use a data type incorrectly, the compiler will call that a syntax array, such as attempting to index a non-array data structure. It is still a logical error the compiler protects you from, though the assembler will say nothing if you got a pointer to a data structure and add an offset.


That is, higher languages offer expressiveness by syntax elements - they allow you to declare what you want, and then later on offer the service of testing your code against your declaration. That is quite some help.

Originally Posted by meynaf

And again, personal attack.

Sure, by the amount of nonsense you have stated.... What else to say?

Originally Posted by meynaf

But if you rely on this, you lose portability - and thus the only advantage C might have on asm.

Now again, tell me why assembler is any better? An exception is something every operating system will use to terminate your program, unless (in POSIX) you have a signal handler installed to capture it. There is your abstraction - some other layer that defines what C left undefined. How else should it work?

Originally Posted by meynaf

And, even in asm you can write accessor functions and do bounds checking. My dynamic array functions do this.

And yet, you have to remember in which register gets which argument. If I use C++, I can use operator[] for that and do not even need to care about how things happen, whether I have bounds checking or not.

Originally Posted by meynaf

No way. It's very different. Some UB in C is perfectly defined in Asm and can even be useful.

No, it is not "defined by asm", it is defined by "something around", for example your operating system. Assembler does not define anything (except the opcodes). If you make an out-of-bounds access to an array, neither asm nor C "define anything". Every sane operating system will define this as "terminate your process", but that is not a language thing. It is an environment, Os thing.

Originally Posted by meynaf

Signed arithmetic overflow isn't "error" if you know what you're doing.

It is left undefined by C because what happends depends on something else beyond C. Your compiler can define it (or rather, the CPU underneath can).

Originally Posted by meynaf

Out of bounds access can be shortcut to access nearby memory.

At which point you shoot yourself into the foot because 3 years later you forgot your dirty trick. In C, you can have a pointer *behind* the last element of an array, and that is all that is ensured because on some architectures, everything else causes already a violation.

Originally Posted by meynaf

Altering string constant defined with DC directive is perfectly permitted and works just fine.

Unless your code is in ROM. Ooops, AmigaOs is in ROM. So no, it is not "permitted" and neither "works fine". There are reasons for such conventions, so why there is something like a "const char *" and a "char *". It is a reminder to the programmer as in "I should not alter this array, compiler please remind me if I do".


That is actually *quite* helpful if you want to write code that should run fine from the kickstart ROM. Just to mention one very obvious usage.

Originally Posted by meynaf

Consider using function call return values as parameters of another function call. In asm you perfectly know in which order these functions will be called.

The inner function is called first, how else could it work...

Originally Posted by meynaf

There are skilled coders here on the eab.

Fine, except that this is a job for a software engineer. "Coders" we have, indeed, more than enough...

Originally Posted by meynaf

Well structured code, in real life, does not exist.

In *your* life maybe...

[meynaf]

Originally Posted by Thomas Richter

Not? If only "coders" are left, it's indeed dead.

At least it is enjoyable rather than boring.

Originally Posted by Thomas Richter

Not quite. If I use a data type incorrectly, the compiler will call that a syntax array, such as attempting to index a non-array data structure. It is still a logical error the compiler protects you from, though the assembler will say nothing if you got a pointer to a data structure and add an offset.

Wrong. It is not a syntax problem, simply because the syntax is itself correct. Using [] on non-array type is syntaxically correct, it's just that the underlying data type isn't an array.
It really is type checking, not syntax checking.

Originally Posted by Thomas Richter

That is, higher languages offer expressiveness by syntax elements - they allow you to declare what you want, and then later on offer the service of testing your code against your declaration. That is quite some help.

This expressiveness is extremely limited and not very helpful.
In asm when you add two things you know what they are because the instruction isn't exactly the same. In C when we have "+" we don't know what we're adding - in C++, worse, it could even be totally unrelated to an addition.
In C when you see a closing curly brace you never know immediately what kind of structure it is (Basic is much better in that aspect). In asm you directly see your loop or branch instruction.
If a is signed and b is unsigned (or vice versa), C will not tell you what it chooses to do when you write if (a < b).
So much for C's expressiveness.

Originally Posted by Thomas Richter

Sure, by the amount of nonsense you have stated.... What else to say?

If you have nothing interesting to say, just keep quiet. It will be better for everyone, including yourself as i may eventually call in the moderation.

Originally Posted by Thomas Richter

Now again, tell me why assembler is any better?

Assembler does not pretend to be portable.

Originally Posted by Thomas Richter

An exception is something every operating system will use to terminate your program, unless (in POSIX) you have a signal handler installed to capture it. There is your abstraction - some other layer that defines what C left undefined. How else should it work?

Perhaps C should define a few extra things. Other languages do.

Originally Posted by Thomas Richter

And yet, you have to remember in which register gets which argument.

I don't need to remember in which registers are arguments. It's written explicitly and easy to find back - and always the same.

Originally Posted by Thomas Richter

If I use C++, I can use operator[] for that and do not even need to care about how things happen, whether I have bounds checking or not.

And now you will end up with bounds checking in places it's not useful and eats time for nothing.

Originally Posted by Thomas Richter

No, it is not "defined by asm", it is defined by "something around", for example your operating system. Assembler does not define anything (except the opcodes). If you make an out-of-bounds access to an array, neither asm nor C "define anything". Every sane operating system will define this as "terminate your process", but that is not a language thing. It is an environment, Os thing.

Where it is defined does not change anything. In asm you know on which machine your code will run on. In C you don't (or at least shouldn't).

Originally Posted by Thomas Richter

It is left undefined by C because what happends depends on something else beyond C. Your compiler can define it (or rather, the CPU underneath can).

Yes, the CPU underneath can define it and not C. Therefore Asm defines more things than C, thanks for proving my point.

Originally Posted by Thomas Richter

At which point you shoot yourself into the foot because 3 years later you forgot your dirty trick. In C, you can have a pointer *behind* the last element of an array, and that is all that is ensured because on some architectures, everything else causes already a violation.

When using a trick, of course i always write it down in some comment.

Originally Posted by Thomas Richter

Unless your code is in ROM. Ooops, AmigaOs is in ROM. So no, it is not "permitted" and neither "works fine". There are reasons for such conventions, so why there is something like a "const char *" and a "char *". It is a reminder to the programmer as in "I should not alter this array, compiler please remind me if I do".

That is actually *quite* helpful if you want to write code that should run fine from the kickstart ROM. Just to mention one very obvious usage.

If your code is in ROM, you know it prior to writing it.
Forbidding something for everyone just because it won't work in ROM is very poor and very stupid.

Originally Posted by Thomas Richter

The inner function is called first, how else could it work...

You did not understand. I told about several inner functions. Now tell me in which order they are called.

Originally Posted by Thomas Richter

Fine, except that this is a job for a software engineer. "Coders" we have, indeed, more than enough...

But it seems software engineers are unable to do the job, where coders probably can...

Originally Posted by Thomas Richter

In *your* life maybe...

No, in yours too. Don't be naive.

[gimbal]

Originally Posted by TCD

You know a simple 'each to their own' never works in this forum

No but neither do walls of text. As soon as you have to create posts with 20 quotes in them you're just wasting screen real-estate for everyone else.

If it can't be said short and sweet, you're probably overthinking it.

[Thorham]

Originally Posted by Thomas Richter

Fine, except that this is a job for a software engineer. "Coders" we have, indeed, more than enough...

What a load of elitist nonsense. Also, you seem to think you're the only professional developer around here (if I'm wrong I didn't say anything) which is obviously not true.

And remember, 68k asm programming is a hobby and is used for smaller projects, and not for one million lines of code sized projects. Perfectly valid.

Originally Posted by meynaf

But it seems software engineers are unable to do the job, where coders probably can...

Don't fall for that silly coders vs software engineers elitist crap. Coder is just slang for programmer, and programmer is just the simple word for software engineer.

[Galahad/FLT]

Using C or other equivalents to write tools is sensible, because usually a tool itself doesn't need to be lightning quick, but the coding of it can be significantly faster than using ASM to do simple things like open file requesters, file handling, displaying something to screen etc where its speed doing that simply doesn't require optimised code.

But for the actual point where you need you code to be as fast as possible, ASM has no substitutes on 68000 based systems.

Having said that, a programmer that has used ASM for so long, likely has a library of routines that use sane equates and parameters so that writing a tool or utility in ASM need not be a headache and can be just as quick a process as writing in C.

[malko]

Originally Posted by AestheticDebris

[...] assembly will always beat or match everything else for pure performance. But not every developer is necessarily capable of writing optimal assembly [...]

As not every developer is necessarily capable of writing optimal C. And no compiler will ever correct lousy code into an extremely well optimised executable (nor will any asm assembler).

At the end, asm & C are languages. And languages can be learned, like French, German, Italian, Russian, Chinese, English, etc.
Some may say that 68k asm is complicated as Chinese and that, therefore, it is better to learn or use C (English). Those people forget that Chinese, as 1st languages, is spoken by 927 million people. Only 379 million speak English as 1st language.
Given that about 3 times more people speak Chinese over English, we can easily say that Chinese is not such a difficult language .