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

[meynaf]

Originally Posted by No.3

ok, that's a nasty one, but easy to work around on older OSes: instead of 1x1 open a 1x2 screen - works at least with OS 3.1 !

Yes this is exactly what I did. Apparently it's a vertical size of 1 that's problematic.
It is not the only workaround i had to make though. Under v39 (fixed for v40) there is a bug for narrow viewports (x<64) and lowres, perhaps linked with AGA. No crash, but an error in the system's copperlist leading to a wrong display.

[Karlos]

Originally Posted by malko

If you only read the highlight you may think so. Formerly it is described in the page you linked above that a federal office (Atomic Energy of Canada Limited (AECL)) made some choices that leaded to mistakes.
Also, do you really believe that the coder(s) were not following strict procedures and orders ?

I believe the engineer(s) was/were probably following whatever procedures they had but they weren't remotely adequate.

The findings include the fact that there was no independent software review process, no real assessment of different real world scenarios, lack of testing, etc. There was no testing at all of the specific hardware and software combination that led to the lethal combination until installation at the hospital.

If you think I'm being unfair to the engineers in apportioning some of the blame to them for their hubris in falsely asserting the infallibility of their safety controls (also a finding) then be aware that I am also an engineer and take responsibility for mistakes that I make.

[Thomas Richter]

Originally Posted by meynaf

There is bloat. Probably not in registers, even though using high parts to store extra data is commonplace in asm, but when said ints reside in memory. An array of int is certainly much bigger than an array of int8 and careless programmers generate bloat because of this.

WTF? If you do not like ints, then don't use them, so what is the problem? Do you believe the average author of a higher programming language is incapable of understanding differently sized types?

Originally Posted by meynaf

What I want is a system that gives me full freedom. Not a nanny, not a guide, just freedom.

Look, with full freedom comes full responsibility. From all my experience I tell you that "full responsibility" is too much for "full sizes programs", simply due to the reasons you already described: If you do not have a compiler helpling you when compiling a larger software stack, you are lost in details, and you loose the ability to perform some automated checks. Of course you can say "I do not write programs that require such a software stack". That's all fine. However, as a matter of fact, there are problems out there that cannot be solved so easily, and for them, it is better to have some helping hand. Depending on the type of the problem you want to solve, the answer may be "language A" or "language B". I'm not particularly advocating C as the best solution to all such problems.

Originally Posted by meynaf

Then again, C does not help much even if you want to be guided. You need something of higher level, and i'm not sure that does not guide to a wrong way.

Then, use something at a higher level. C++ concepts, for example. Or whatever tool you find appropriate.

Originally Posted by meynaf

Let's insist on the word "obvious".

Unfortunately, most *my* mistakes are pretty obvious. Refactor a longer assembly function, miss that one register is already populated by something else - boom! Depending on how easy or complicated this function may be, this can be minutes or hours of debugging fun. If I know that the function I write is not particularly critical, why *do I* have to do the register allocation? That is a fairly trivial task the compiler can do, without much difference in results.

Originally Posted by meynaf

You won't get killed by having written a buggy program, especially not in the development phase.

That, of course, depends on the program and what it controls. (-;

Originally Posted by meynaf

Quick guess, it will use an address register instead of a data register.
It is not enforced, but it is there.

Why? Nobody says that it has to be this way, it is only a convention. Still, which pointer goes in which regster? Or, are address registers even used? Look at the dos.library - everything is in data registers, building on the calling conventions of the BCPL compiler.


Wouldn't it be better if instead of establishing a *convention* a language element would enforce that convention, and would warn you if something does not follow it?

Originally Posted by meynaf

Looking at code currently in the wild, they do not seem very good at that...

Looking at the code in the wild, they seem to be *pretty good* at that. The difference between hand-optimized assembler and compiled code with intrinsics is so minimal that it is not worth the investment.

Originally Posted by meynaf

It does that worse, actually, for several reasons :
- current data is shown in registers at any time, in comparison to variable watch which needs to be changed for every function you step in
- the disassembler will show you machine code in which you can eventually spot inefficiencies

Why does that matter? Most code (80%, actually) is not time critical at all. Most of the time, many programs just sit waiting for user input or I/O to happen.

Originally Posted by meynaf

- the debugging software is itself a magnitude more complicated with C (and thus more subject to failures)

Why? gdb seems to work pretty well with me.

Originally Posted by meynaf

Even for experienced programmers, some messages may be really, really cryptic.

Compilers pretty much improved on this in the past. Really.

Originally Posted by meynaf

Some are also just wrong and you have to silence them.

Actually, that happens pretty rarely to me. I believe the most common false warning I receive from gcc is "uninitialized variable" because by convention I compile with -Wall -pedantic (and a couple of others) to let the compiler tell me every single bit it finds suspicious, and I have a "no warning" policy. For such cases, you can initialize the variable manually - and this actually helps because you can be sure that *this* part cannot go bad if you refactor the code later on, and it is no longer "so obvous" that the variable will be, indeed, in each case initialized. So this is a good policy for robust programs.

Originally Posted by meynaf

This is true, even though nothing prevents compilers doing strange optimizations based on the undefined property of signed integer arithmetic overflow.

If you want warp-around policy, we have "unsigned" for that in C.

Originally Posted by meynaf

The problem in this case is that the C language offers no way to enforce that behaviour in the few cases it is actually useful - if this had been possible, noone would complain it adds a few overhead for cpus not having direct support for it.

Sure there is a way how to *enforce* wrap-around. That's unsigned. At least, this is how C works. There are other languages that work on other gronds. If you have a problem where this matters in particular, well, select a language that fits this particular need. Mutli-precision numerics in integer is probably nothing I would really do in C.

Originally Posted by meynaf

No. The data types could be floats and the equation would be exactly the same.

float beats integer, double beats float. Not particularly hard to remember.

Originally Posted by meynaf

In C++, even worse : they could be absolutely any class supporting the operator.

Or even better, depending on what you want to do. If I have two vectors, adding them with "+" makes perfect sense, and makes the code more readable, not less. It avoids messing with the details - if you write out a vector addition in assembler, is that really more readable? It is just obfuscination of the intended operation.


Of course, as with everything, with great power comes great responsibility. Operator overloading should only be used where it the symbol really matches closley the intended operation. The C++ standard went IMHO overboard with operator overloading for IO streams and << and >>, which makes the resulting code both less powerful and less readable. They have std::format these days which works much nicer. Python has the % operator for string formatting, which also works very nicely.


That's "live and learn". Not every aspect of every language is perfect. But that I do not have to fiddle with register allocation I consider a great improvement.

Originally Posted by meynaf

In asm it's the programmer who decides what this gives so he can be sure it is really what he wants. In C, what one gets isn't always what one wants.

And in assembler, it's the programmer who shouts herself into the foot - not exactly the right balance. Apparently, you seem to be some sort of control freak. I do not matter if the compiler helps me out most of the time for some minor annoyances in return. The anoyances (and abilities to create obscure bugs) in assembler are much larger. You are running into the risk of getting lost in detail - that is the major danger. You probably optimize a minor function one week, just to find out four weeks later that there is a better solution to the same problem (or probably never notice that fact).


A higher language is almost like a blue-print of an algorithm.

Originally Posted by meynaf

Programmers know that behaviour and it is often useful. But C does not have the tools to mix values like that, ending up with clumsy masking.

I know the behaivour of C, and I do not really miss any tools. I probably miss some higher up power to express my algorithms on an abstract level, but there are better programming languages for that as well - if the problem gets too complex for C, there is another language.

Originally Posted by meynaf

Which would have been fine if there had been an easy and portable way to tell it "yes I know !" for that particular code. So the compiler kinda asks you a question but you cannot answer.

You can answer by working on your code. Here, look, I'm initializing the variable for you. It's probably better I do because who knows whether I remember if I insert another "if"-clause somewhere that the variable is actually set. Assembler does not warn you at all. In how far that is better is beyond me. Of course, you can turn off such compiler warnings, just that I personally am happy to have them.

Originally Posted by meynaf

Of course, during all that time the language could have been properly designed so that warnings always tell something's really wrong, but it is another story.

Warnings are not a matter of a language. The C standard has absolutely nothing to say about warnings. It is the matter of a compiler implementation what it wants to warn you about.

[meynaf]

Originally Posted by Thomas Richter

WTF? If you do not like ints, then don't use them, so what is the problem?

Haha ! Don't use them. Very funny. As if i were not using programs i didn't write !

Originally Posted by Thomas Richter

Do you believe the average author of a higher programming language is incapable of understanding differently sized types?

Understanding something and making good use of it, are two different things.

Originally Posted by Thomas Richter

Look, with full freedom comes full responsibility. From all my experience I tell you that "full responsibility" is too much for "full sizes programs", simply due to the reasons you already described: If you do not have a compiler helpling you when compiling a larger software stack, you are lost in details, and you loose the ability to perform some automated checks. Of course you can say "I do not write programs that require such a software stack". That's all fine. However, as a matter of fact, there are problems out there that cannot be solved so easily, and for them, it is better to have some helping hand. Depending on the type of the problem you want to solve, the answer may be "language A" or "language B". I'm not particularly advocating C as the best solution to all such problems.

Even when using a compiler, one will always be lost in details. As what you have to provide is a full description.

Originally Posted by Thomas Richter

Then, use something at a higher level. C++ concepts, for example. Or whatever tool you find appropriate.

Higher level ? On the Amiga ?

Originally Posted by Thomas Richter

Unfortunately, most *my* mistakes are pretty obvious. Refactor a longer assembly function, miss that one register is already populated by something else - boom! Depending on how easy or complicated this function may be, this can be minutes or hours of debugging fun.

Then we're just different. MY mistakes are often far from obvious. No compiler in the world would help me for these.

Originally Posted by Thomas Richter

If I know that the function I write is not particularly critical, why *do I* have to do the register allocation?

What, don't you like doing register allocation ? It is fun.

Originally Posted by Thomas Richter

That is a fairly trivial task the compiler can do, without much difference in results.

I don't think so, no. Compiler register allocation is static : some are scratch, some are not. In asm this is dynamic.

Originally Posted by Thomas Richter

That, of course, depends on the program and what it controls. (-;

No it doesn't. I wrote "development phase" for a reason.

Originally Posted by Thomas Richter

Why? Nobody says that it has to be this way, it is only a convention.

I told it - it is not enforced.

Originally Posted by Thomas Richter

Still, which pointer goes in which regster?

Usually a0=source, a1=target. I tend to put same things in same registers.

Originally Posted by Thomas Richter

Or, are address registers even used?

Should be written at the start of the function, as a comment.

Originally Posted by Thomas Richter

Look at the dos.library - everything is in data registers, building on the calling conventions of the BCPL compiler.

A little illogic, but not a game changer.

Originally Posted by Thomas Richter

Wouldn't it be better if instead of establishing a *convention* a language element would enforce that convention, and would warn you if something does not follow it?

No, because such a convention may or may not be used depending on current situation.
Nothing is more annoying than the language attempting to push something when we want to do otherwise.

Originally Posted by Thomas Richter

Looking at the code in the wild, they seem to be *pretty good* at that.

Argh! We haven't looked at the same code !

Originally Posted by Thomas Richter

The difference between hand-optimized assembler and compiled code with intrinsics is so minimal that it is not worth the investment.

Intrinsics ? On the Amiga ?

Originally Posted by Thomas Richter

Why does that matter? Most code (80%, actually) is not time critical at all. Most of the time, many programs just sit waiting for user input or I/O to happen.

Why always bringing the speed into the discussion ? I was telling about debug facillities (if the word "inefficiencies" has mislead you, you have to know that speed isn't the only inefficiency there is).

Originally Posted by Thomas Richter

Why? gdb seems to work pretty well with me.

My point wasn't that it works well or not, it is that this is inefficient, large, complicated software. My debugger is 11kb.

Originally Posted by Thomas Richter

Compilers pretty much improved on this in the past. Really.

This doesn't seem to have reached MSVC.

Originally Posted by Thomas Richter

Actually, that happens pretty rarely to me. I believe the most common false warning I receive from gcc is "uninitialized variable" because by convention I compile with -Wall -pedantic (and a couple of others) to let the compiler tell me every single bit it finds suspicious, and I have a "no warning" policy. For such cases, you can initialize the variable manually - and this actually helps because you can be sure that *this* part cannot go bad if you refactor the code later on, and it is no longer "so obvous" that the variable will be, indeed, in each case initialized. So this is a good policy for robust programs.

And you generate useless init code.

Originally Posted by Thomas Richter

If you want warp-around policy, we have "unsigned" for that in C.

Right, but this is a clumsy way if the data is inherently signed.

Originally Posted by Thomas Richter

Sure there is a way how to *enforce* wrap-around. That's unsigned. At least, this is how C works. There are other languages that work on other gronds. If you have a problem where this matters in particular, well, select a language that fits this particular need. Mutli-precision numerics in integer is probably nothing I would really do in C.

Yes i have selected a language that fits this particular need and works well with multi-precision numerics.

Originally Posted by Thomas Richter

float beats integer, double beats float. Not particularly hard to remember.

Doesn't change the fact that you don't know by the equation alone.

Originally Posted by Thomas Richter

Or even better, depending on what you want to do. If I have two vectors, adding them with "+" makes perfect sense, and makes the code more readable, not less. It avoids messing with the details - if you write out a vector addition in assembler, is that really more readable? It is just obfuscination of the intended operation.

There are no vectors in 68k.

Originally Posted by Thomas Richter

Of course, as with everything, with great power comes great responsibility. Operator overloading should only be used where it the symbol really matches closley the intended operation. The C++ standard went IMHO overboard with operator overloading for IO streams and << and >>, which makes the resulting code both less powerful and less readable. They have std::format these days which works much nicer. Python has the % operator for string formatting, which also works very nicely.

That's "live and learn". Not every aspect of every language is perfect. But that I do not have to fiddle with register allocation I consider a great improvement.

Isn't it nice that everyone can use the tools they like ?

Originally Posted by Thomas Richter

And in assembler, it's the programmer who shouts herself into the foot - not exactly the right balance. Apparently, you seem to be some sort of control freak. I do not matter if the compiler helps me out most of the time for some minor annoyances in return. The anoyances (and abilities to create obscure bugs) in assembler are much larger. You are running into the risk of getting lost in detail - that is the major danger. You probably optimize a minor function one week, just to find out four weeks later that there is a better solution to the same problem (or probably never notice that fact).

The biggest annoyances in programming are not details such as register allocation. It is startup/cleanup code and error handling. C does not protect against these -- but my asm library does.

Originally Posted by Thomas Richter

A higher language is almost like a blue-print of an algorithm.

Originally Posted by Thomas Richter

I know the behaivour of C, and I do not really miss any tools. I probably miss some higher up power to express my algorithms on an abstract level, but there are better programming languages for that as well - if the problem gets too complex for C, there is another language.

If you like your tools, good. Just don't assume they're also the best for other people.

Originally Posted by Thomas Richter

You can answer by working on your code. Here, look, I'm initializing the variable for you. It's probably better I do because who knows whether I remember if I insert another "if"-clause somewhere that the variable is actually set. Assembler does not warn you at all. In how far that is better is beyond me. Of course, you can turn off such compiler warnings, just that I personally am happy to have them.

Working on the code isn't always possible.
Unitialized variables is relative rare in asm, as bss is cleared upon startup.
Stale pointers can happen in asm and are more deadly, but C doesn't protect against that.

Originally Posted by Thomas Richter

Warnings are not a matter of a language. The C standard has absolutely nothing to say about warnings. It is the matter of a compiler implementation what it wants to warn you about.

Then compilers are not mature enough. See you again in 10 years.

[Karlos]

This thread reminds me somewhat of this:

[ Show youtube player ]

[malko]

@Karlos : OT but interesting :

This documentary help understand how by training the brain adapt itself to reach performance (C or asm, as you like )
[ Show youtube player ]

A documentary about " the trees hiding the forest " :
[ Show youtube player ]
There are 3 really interesting documentaries. If you liked this one, you will for sure find and watch the 2 others.

Or this one in FR about antibiotics that are less and less useful due to the current use some do with it :
[ Show youtube player ]

[Thorham]

Originally Posted by meynaf

Higher level ? On the Amiga ?

Why not? I use Lua with a big float library as a programmable calculator on the Amiga. Or someone could port C# (without the massive .net framework). Also, C is higher level

Originally Posted by meynaf

There are no vectors in 68k.

They're software based. There's no reason you can't do 3D with vectors on 68k.

Originally Posted by meynaf

Indeed

Originally Posted by meynaf

Then compilers are not mature enough. See you again in 10 years.

Tried C#?

[Thomas Richter]

Originally Posted by meynaf

Haha ! Don't use them. Very funny. As if i were not using programs i didn't write !

Understanding something and making good use of it, are two different things.

So if I understand you correctly, everybody but you are incompetent? Is that right? Do you really believe people are stupid just because they use higher languages, and that those people do not understand memory bandwith issues?

Originally Posted by meynaf

Then we're just different. MY mistakes are often far from obvious. No compiler in the world would help me for these.

Oh, believe me. There is at least one mistake that is completely obvious to me, but far from obvious for you.

Originally Posted by meynaf

What, don't you like doing register allocation ? It is fun.

It is, to most degree, a waste of time.

Originally Posted by meynaf

I don't think so, no. Compiler register allocation is static : some are scratch, some are not.

Err. No. That might be true for 1989ish compilers such as the simple Aztec, but SAS/C can do better and that is by far not a very advanced compiler.

Originally Posted by meynaf

My point wasn't that it works well or not, it is that this is inefficient, large, complicated software. My debugger is 11kb.

A debugger for assembler/object code is relatively simple software.

Originally Posted by meynaf

And you generate useless init code.

No, not useless. Protective. Code never stays "as it was". Program development is continuous refactoring.

Originally Posted by meynaf

Yes i have selected a language that fits this particular need and works well with multi-precision numerics.

That depends on what else you need.

Originally Posted by meynaf

There are no vectors in 68k.

And the point is? It does not matter whether there are vectors on the 68K or not. What matters is that I get the result of a vector addition, and source code line that expresses my intend perfectly.

Originally Posted by meynaf

Isn't it nice that everyone can use the tools they like ?

Once again, use whatever you want to use. That was never the point.

Originally Posted by meynaf

The biggest annoyances in programming are not details such as register allocation. It is startup/cleanup code and error handling. C does not protect against these -- but my asm library does.

Err, what? Startup code is not an issue at all. Resource allocation and resource management is an issue. C provides very little help there, right. Assembler provides no help there, and why that is any better is beyond me. C++ provides lots of help there. RAII is a very recommendable pattern to avoid issues around resource management. Other languages provide other means of course.
Thus, it all depends on the language.

Originally Posted by meynaf

If you like your tools, good. Just don't assume they're also the best for other people.

I don't. I just see that it's best industry practise to use them. Of course, different tools, whatever fits your needs. Some people prefer such tools as MSVS, I prefer tools such as g++, gdb and ddd. No problem with that. I just see consider it very bad adivce not to use any and depend on a language that has *nothing* to offer. That is the issue. Not your likings of a language.

Originally Posted by meynaf

Working on the code isn't always possible.

Not? I develop on the code, and that's all that matters to me.

Originally Posted by meynaf

Unitialized variables is relative rare in asm

As it doesn't have variables, and no means to check for proper initialization, that's probably not a miracle. "bss" is not a "variable". It is rather means to allocate storage space through the loader. Problem is - it's only storage, without any life time control.

Originally Posted by meynaf

Stale pointers can happen in asm and are more deadly, but C doesn't protect against that.

Then, consider languages that provide better support in such regards. Rust might be a good candidate. C++ has "std::unique_ptr" for such exercises, and the RAII pattern. Java has garbadge collection, python does not require pointers. There are really many *better* possibilities.

Originally Posted by meynaf

Then compilers are not mature enough. See you again in 10 years.

*Warnings* are a good thing, and part of the tool. Use them, they provide valuable feedback.