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

[meynaf]

Originally Posted by Karlos

so something more like this then:

    if (val) {
        ret = something;
            val = side_effect1(val);
    }
    if (val <= 0) {
        ret = something_else;
            val = side_effect2(val);
    }
    if (val < 0) {
        ret = again_something_else;
    }

When your code ends up like this you may need to rethink what you are doing.

No. Variable val isn't altered.

It is more like :

int somecode (int val, int other_param) {
    int xx,yy,ret;
    if (val) {
        ret = xx = side_effect1(other_param);
    }
    if (val <= 0) {
        ret = yy = side_effect2(other_param);
    }
    if (val < 0) {
        ret = yy - xx;
    }
    return ret;
}

[robinsonb5]

Originally Posted by meynaf

No. Variable val isn't altered.

It is more like :

int somecode (int val, int other_param) {
    int xx,yy,ret;
    if (val) {
        ret = xx = side_effect1(other_param);
    }
    if (val <= 0) {
        ret = yy = side_effect2(other_param);
    }
    if (val < 0) {
        ret = yy - xx;
    }
    return ret;
}

I trust xx and yy are initialised before the tests? Otherwise the compiler warning is correct.

[meynaf]

Originally Posted by robinsonb5

I trust xx and yy are initialised before the tests? Otherwise the compiler warning is correct.

The compiler warning is incorrect, even in case xx and yy are not initialised.
If you don't believe me, find a case where UMR occurs.

[Thorham]

Originally Posted by meynaf

The compiler warning is incorrect

C# does this too, which is odd for clear cases like this.

This doesn't compile (it's not even a warning in C#, just an error):

int a;
int b = Environment.TickCount;

if (b == 0)
    a = 1;

if (b < 0)
    a = 2;

if (b > 0)
    a = 3;

Console.WriteLine(a);

While this is perfectly fine (no warnings):

int a;
int b = Environment.TickCount;

if (b == 0)
    a = 1;

else if (b < 0)
    a = 2;

else
    a = 3;

Console.WriteLine(a);

[robinsonb5]

Originally Posted by meynaf

The compiler warning is incorrect, even in case xx and yy are not initialised.

OK yes, looking again I see there's no case where the third condition can execute without both the previous two having executed, so xx and yy are guaranteed to have a value by the time they're added.

[AestheticDebris]

Originally Posted by meynaf

No, ASM code isn't required to follow the platform ABI. It only has to know that most OS calls are expected to trash D0-D1/A0-A1. Everywhere the OS isn't called (which is most of the code), the coder is free to do whatever he sees fit.
To port code from a 68k platform to another, everything platform specific (HW, OS calls) has to be replaced. The platform ABI is of absolutely no relevance ; if new code trashes more registers, just save them around the call.
And, stack unwinding made by the OS ? Serious ?

Um, yes it is: https://devblogs.microsoft.com/oldne...8-00/?p=101088

Obviously that's a Windows centric article, but the principle remains the same regardless of OS. Even if you write assembly language, your program is supposed to remain within the constraints of the ABI. It won't necessarily fail if it doesn't, but you have wandered into the realm of "undefined behaviour" nonetheless.

[Thorham]

Originally Posted by AestheticDebris

Even if you write assembly language, your program is supposed to remain within the constraints of the ABI.

You can still use d0-d1/a0-a1 for whatever you want outside of function calls.

[meynaf]

Originally Posted by Thorham

This doesn't compile (it's not even a warning in C#, just an error):

What does the error message say ?

Originally Posted by robinsonb5

OK yes, looking again I see there's no case where the third condition can execute without both the previous two having executed, so xx and yy are guaranteed to have a value by the time they're added.

This is what the compiler misses. It also misses that the return value is set in all possible cases.

Originally Posted by AestheticDebris

Um, yes it is: https://devblogs.microsoft.com/oldne...8-00/?p=101088

Obviously that's a Windows centric article, but the principle remains the same regardless of OS. Even if you write assembly language, your program is supposed to remain within the constraints of the ABI. It won't necessarily fail if it doesn't, but you have wandered into the realm of "undefined behaviour" nonetheless.

No. Definitely not. In no possible case will this ever apply to current AmigaOS.

Actually that guy in the blog is probably just plain wrong even in the case of Windows. He is apparently confusing the language - which may do stack unwinding - with the operating system.
I'm not Windows internals specialist, but nevertheless...
Frankly, just compile a C program : there are no exceptions there, no stack unwinding of any sort. In C++ compiler settings you can even disable exceptions, to remove said stack unwinding.

And i can tell you for a fact that at least AmigaOS does not give a shit about what you put in your program's stack.

Anyway this is completely off. That D0-D1/A0-A1 are not scratch in some parts of an asm program, is totally different of what's in the stack.
The ABI only says what registers are supposed to be altered in case of an OS call, and this does not even apply to all OS functions.

[Thorham]

Originally Posted by meynaf

What does the error message say ?

Use of unassigned local variable 'a'

[Karlos]

The best compiler warning I ever saw came out of vbcc when compiling a Duff's Device example. It said, and I quote "This code is weird."

[robinsonb5]

Originally Posted by Karlos

The best compiler warning I ever saw came out of vbcc when compiling a Duff's Device example. It said, and I quote "This code is weird."

I think my favourite compiler message of all came from older versions of GCC: "class only defines a private destructor and has no friends."

Originally Posted by Meynaf

Actually that guy in the blog is probably just plain wrong even in the case of Windows.

I'd be *very* surprised if a blog post from Raymond Chen is wrong.

[meynaf]

Originally Posted by robinsonb5

I'd be *very* surprised if a blog post from Raymond Chen is wrong.

I don't care who the post is from (argument from authority).
It looks quite stupid that the OS does stack unwinding in the place of the compiler. It might however still be true in the case of Windows (which is rather crazy OS) and it could be interesting to disassemble some code to see what it does with the stack ; however, one 100% complete sure thing is that AmigaOS does *not* do anything like that. Neither do Atari TOS or MacOS 68k.

[alkis]

Originally Posted by meynaf

No. Variable val isn't altered.

It is more like :

int somecode (int val, int other_param) {
    int xx,yy,ret;
    if (val) {
        ret = xx = side_effect1(other_param);
    }
    if (val <= 0) {
        ret = yy = side_effect2(other_param);
    }
    if (val < 0) {
        ret = yy - xx;
    }
    return ret;
}

clang, gcc do not give a warning. Neither m68k-amigaos-gcc.
All tried with -Wall -Wextra

How do you get a warning?

[meynaf]

Originally Posted by alkis

clang, gcc do not give a warning. Neither m68k-amigaos-gcc.
All tried with -Wall -Wextra

How do you get a warning?

VS2022 with maximum warning level.

[robinsonb5]

Originally Posted by meynaf

I don't care who the post is from (argument from authority).

I agree that his expert status doesn't constitute proof that the post is correct - but nonetheless a blog post published on Microsoft's own website, and written by an expert with 30 years' experience of Windows internals is not likely to be fundamentally wrong in its entire premise; the bar for dismissal is rather higher than "that doesn't seem right - he's probably confused."

however, one 100% complete sure thing is that AmigaOS does *not* do anything like that. Neither do Atari TOS or MacOS 68k.

Agreed - we don't have to worry about this on the Amiga.

[Karlos]

The "Argument from authority" card is best used when dealing with a viewpoint that is inscrutable in some way, e.g. the case for a religious edict for which the only basis is "because it says so".

It's less well applied in cases where the position you are arguing against can be tested or validated in some way. Using it to downplay someone's claim in this way amounts to saying "I know better than you and your expertise/experience in this area is irrelevant.". There's a reason someone is considered an expert in a given area. And while it's true that they can still be wrong, on the balance of probability it would be hubris to disregard their opinion for simply having that expertise.

[meynaf]

Originally Posted by robinsonb5

I agree that his expert status doesn't constitute proof that the post is correct - but nonetheless a blog post published on Microsoft's own website, and written by an expert with 30 years' experience of Windows internals is not likely to be fundamentally wrong in its entire premise; the bar for dismissal is rather higher than "that doesn't seem right - he's probably confused."

Maybe, but having never seen this kind of affirmation anywhere else, along with the affirmation itself seeming illogical - and plain wrong in every system where this is easy to check (like on Amiga or similar platforms) -, this should at least raise some doubt. Is windows that different ?
If what he says is true, then the program isn't free of what it puts in the stack and even languages with no support for exceptions at all should do things for supporting the OS ones. Doesn't this sound plain crazy ?
I have few disassembly experience for windows, and the few i have traces back a few decades, but it did not suggest anything like that.
If the code omits the frame pointer, which i think is an option most compilers have, how can the OS possibly unwind the stack, knowing it could point to anything ?

Originally Posted by Karlos

The "Argument from authority" card is best used when dealing with a viewpoint that is inscrutable in some way, e.g. the case for a religious edict for which the only basis is "because it says so".

It's less well applied in cases where the position you are arguing against can be tested or validated in some way. Using it to downplay someone's claim in this way amounts to saying "I know better than you and your expertise/experience in this area is irrelevant.". There's a reason someone is considered an expert in a given area. And while it's true that they can still be wrong, on the balance of probability it would be hubris to disregard their opinion for simply having that expertise.

Your reasoning here is correct if the argument from authority is the only reason to dismiss the article - but it is not.
Search the web about stack unwinding : you will find many articles from many sources, but it is all about runtimes and specific languages, not operating systems.
I found nothing to back up this assertion. It has next to zero logic. It contradicts all personal experience i have. It is wrong for all platforms i know well.
But you're right at some point : yes it can be validated. So let's disassemble code and see what it does with the stack...

[Karlos]

Originally Posted by robinsonb5

I think my favourite compiler message of all came from older versions of GCC: "class only defines a private destructor and has no friends."

that's a good one. And yet it's entirely sensible in a way. A private destructor without any friends that can invoke it makes any instance of it it tricky to dispose of.

[AestheticDebris]

Originally Posted by meynaf

If what he says is true, then the program isn't free of what it puts in the stack and even languages with no support for exceptions at all should do things for supporting the OS ones. Doesn't this sound plain crazy ?

It's pretty much required for any OS that supports memory protection and virtual memory, because almost every instruction could theoretically generate an exception that the OS has to take care of and attempt to recover the process.

Originally Posted by meynaf

If the code omits the frame pointer, which i think is an option most compilers have, how can the OS possibly unwind the stack, knowing it could point to anything ?

The article is part of a series on how Windows supported the various CPUs it has run on over the years. I'd highly recommend those series to anyone with even a vague interest in assembly languages (and the blog in general to anyone who codes anything on Windows).

FWIW, on everything but 32-bit x86, unwind codes are used rather than frame pointers to unwind exceptions:

https://learn.microsoft.com/en-us/cp...?view=msvc-170

[meynaf]

Originally Posted by AestheticDebris

It's pretty much required for any OS that supports memory protection and virtual memory, because almost every instruction could theoretically generate an exception that the OS has to take care of and attempt to recover the process.

Memory protection and virtual memory don't work this way, or at least they don't need to.
They don't have to care at all about what's in the stack.
When an instruction fails to access memory, be it due to real error or some paging, the only useful information is the instruction itself. It may then trigger an exception, or some page load from disk and a restart of said instruction.

Originally Posted by AestheticDebris

The article is part of a series on how Windows supported the various CPUs it has run on over the years. I'd highly recommend those series to anyone with even a vague interest in assembly languages (and the blog in general to anyone who codes anything on Windows).

FWIW, on everything but 32-bit x86, unwind codes are used rather than frame pointers to unwind exceptions:

https://learn.microsoft.com/en-us/cp...?view=msvc-170

That's very Windows specific.
Besides, they don't say what happens for programs who just don't want to catch any exception.

All this said, your original argument was for Amiga and we clearly see all we have here just does not apply there.