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

[Thomas Richter]

Originally Posted by Bruce Abbott

Interesting. So I couldn't possibly be reading this post and replying to it right now, on my A1200 using IBrowse with javascript turned off?

Probably your pain tolerance is very high. If I try that, I see lots of formatting tags in the "editor" that are irritating and not helpful. And there is much more of the web than just this forum. I also want to check the news or my train tickets online, and no, that doesn't work without javascript.

[meynaf]

Originally Posted by idrougge

But perhaps the compiler knows something (or rather lacks the ability infer something) here which we don’t. Perhaps it’s unprovable in C that ret can’t be mutated somewhere else between those if statements as it isn’t written as if/else/else or we still don’t have a »sufficiently smart compiler« yet.

In theory the compiler is free to assume that ret isn't changed in between because it isn't volatile, but that may be wrong. However, it might be good to have a way to hint that knowledge into the compiler.

Originally Posted by idrougge

Please, let’s at least pretend to stay serious.

What a nice appeal to ridicule.

Originally Posted by idrougge

It doesn’t have to be that way. Hand-optimised assembly wins every time, but not every routine needs that kind of optimisation and monomorphisation and static analysis allows even stupid high-level code to compile to good machine language.

And, as I have said, perfectly useful code can be written in higher-level languages. Even highly inefficient ones. Not every operation needs to be optimised to demo scene 40k limits.

Probably, but that doesn't make asm a bad tool.

Originally Posted by idrougge

But you can cause crashes in both cases. I have caused both memory leaks and crashes in both assembly and E.

Sure all can crash, but in asm, contrary to hlls, errors have a tendency to crash more often than working by accident.
Besides, as my asm system framework has resource tracking, i'm not doing memory leaks anymore.

Originally Posted by idrougge

Nice trick, but you never know when you’re really done. It’s bad enough to freeze interfaces at a higher level, but at least you haven’t committed to a certain register allocation.

Those are for internal use, not for passing parameters around. They have no impact on interfaces.

Originally Posted by idrougge

It’s not as though a compiler can’t do that analysis either. Note how certain high-level languages even allow you to write functions that allow tail recursion; that implies that the compiler can surmise that register reuse is permissible.

This requires cross-function analysis. Perhaps compilers can do this, but they still have to respect the ABI.

Originally Posted by idrougge

Congratulations, you’re on the way toward inventing a HLL.

Wouldn't it be great if we had the best of both worlds ?

Originally Posted by idrougge

It was in referral to your claim that the Amiga doesn’t have vector operations in its CPU. You don’t need to have them to do vector operations.

As much as we don't need an FPU to do floating-point. So what ?

Originally Posted by idrougge

And C is an Algol derivative, and Javascript contains Java in its name.

Ahem.

Originally Posted by idrougge

You might need to do that refactoring several times over as other parts change, or as you get time to do smarter, but more complex, refactorisations.

Maybe, but it's then your own code that you refactor. It's not the same thing as someone else's code.

Originally Posted by idrougge

I would agree if spurious warnings was a common problem, but it isn’t. Assembly seldoms gives you warnings, so it might seem that way, but warnings usually are raised for a reason.

Spurious warnings happen when the compiler misses something or is too pedantic.
For me, many have come from C or C++ bizarre specs.
In asm i think there should not be any warnings at all, everything it reports can be treated as errors.

Originally Posted by idrougge

How so? The if statements are the branch instructions. What makes you think it is more efficient?

Compare :

 moveq #ret1,d0
 tst condition
 bne .1
 moveq #ret2,d0
.1

with :

 tst condition
 beq .2
 moveq #ret1,d0
 bra .1
.2
 moveq #ret2,d0
.1

Originally Posted by idrougge

That’s what if/else is for.

No. If/else can only give two possibilities.

[meynaf]

Originally Posted by Thorham

Perhaps not in this case. A full blown up to date browser in ASM would indeed be madness

A full blown up to date browser is madness regardless of the language...

Originally Posted by Thomas Richter

Probably your pain tolerance is very high. If I try that, I see lots of formatting tags in the "editor" that are irritating and not helpful. And there is much more of the web than just this forum. I also want to check the news or my train tickets online, and no, that doesn't work without javascript.

That explains why your posts are often misformatted, with all those added empty lines.

[Don_Adan]

Originally Posted by Bruce Abbott

;    HTTPC.ASM
;
;    Compile with FASM for Menuet ( v1.40 for DOS )
;
;    This program implements a very simple web browser
;

And they're not kidding. The entire source is a single 36.1kB text file. No macros, no include files, just pure x86 asm!

I think that meynaf can transcode this x86 asm source to 68k asm, and Amiga will be have fast and simple browser.

[Bruce Abbott]

Originally Posted by Thomas Richter

Probably your pain tolerance is very high. If I try that, I see lots of formatting tags in the "editor" that are irritating and not helpful.

Funny, I wouldn't have thought that would bother an accomplished coder. I see the same formating tags here as I do on my PC.

And there is much more of the web than just this forum. I also want to check the news or my train tickets online, and no, that doesn't work without javascript.

Changing the goalposts?

Sure there's much more to the web, but when I'm using my Amiga this website is where I usually want to be (and on my PC a lot of the time too!).

You have a point about IBrowse not being able to do everything on the web. This was always a problem, even back in the 90s when Netscape introduced its proprietary extensions. The community caved to it and things have only gotten worse since then. There are only 3 browsers today that do 'everything' and Firefox (the only open source one) is slipping behind.

More and more websites have abandoned html and do everything in javascript, making compatibility a huge problem. I am runnig the latest Firefox on my Linux PC and it doesn't always render pages correctly. A seamingly simple web page might take up 1GB of RAM and be 100 times slower than it would be in plain html, even straining modern PCs.

So if you want to do 'everything' you have no choice but to get the latest most powerful PC available and run Windows. But like the asm vs HLL debate, that's not relevant here. It doesn't bother us that our Amigas can't do 'everything'. I'm very happy just being able to access this and other Amiga-related sites, and google etc.

It's actually quite surprising how much we can do on the net today with a 30 year old computer - despite all the roadbocks that have been set up against us. That is due to Amiga developers not being put off by unreasonable demands that it must do 'everything'.

[Thorham]

Originally Posted by meynaf

In asm i think there should not be any warnings at all, everything it reports can be treated as errors.

Depends. You could, for example, have a 'branch too long' warning, where the branch could be 8bit but it's 16bit, or something. Hardly seems critical.

Originally Posted by meynaf

A full blown up to date browser is madness regardless of the language...

Probably, which isn't too surprising seeing how overblown and full of crap the web is these days

Originally Posted by Bruce Abbott

It's actually quite surprising how much we can do on the net today with a 30 year old computer

It could've been much better if the web wasn't so effing bloated

[alkis]

Originally Posted by meynaf

In theory the compiler is free to assume that ret isn't changed in between because it isn't volatile, but that may be wrong. However, it might be good to have a way to hint that knowledge into the compiler.

I thought that I already hinted this but here is another try.
The microsoft compiler trips on that code. Gcc and Clang do not trip over this code. You could say microsoft compiler has a bug. I don't think you can draw conclusions of what a C compiler can do or can't based on a bug on a single C compiler.

You can have these arguments only for the microsoft (buggy) compiler.

[meynaf]

Originally Posted by Thorham

Depends. You could, for example, have a 'branch too long' warning, where the branch could be 8bit but it's 16bit, or something. Hardly seems critical.

It could be critical. If one asks for an explicit branch size then the code may depend on said code size.

Originally Posted by Thorham

Probably, which isn't too surprising seeing how overblown and full of crap the web is these days

Right, had the web been correctly designed, such software would be several orders of magnitude simpler. Note that original html was fine, actually.

Originally Posted by alkis

I thought that I already hinted this but here is another try.
The microsoft compiler trips on that code. Gcc and Clang do not trip over this code. You could say microsoft compiler has a bug. I don't think you can draw conclusions of what a C compiler can do or can't based on a bug on a single C compiler.

You can have these arguments only for the microsoft (buggy) compiler.

It was just an example.

[idrougge]

Originally Posted by Bruce Abbott

And drop the Amiga too, right?

As far as I am aware, we dropped the Amiga in 1994 at latest.

No, C isn't going away anytime soon, and as it was the preferred language (along with asm) on the Amiga which is now a retro computing platform, we should continue to use it in that role.

C is going away since the Amiga went away. In the Amiga days, it was used as a general-purpose high-level language. Since then, it has retreated into embedded platforms, an interop glue and the same niches occupied by assembly.

[idrougge]

Originally Posted by Thorham

C# does this as well, so it's probably that the compilers can't for some reason.

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);

Could it be that this is also unprovable in C# because of rules regarding mutability – possibly from different threads? One often runs into similar problems with Kotlin where a given value can only be accessed within a .let closure.

[idrougge]

Originally Posted by meynaf

In theory the compiler is free to assume that ret isn't changed in between because it isn't volatile, but that may be wrong. However, it might be good to have a way to hint that knowledge into the compiler.

Sorry, I was (again) referring to val, not ret. As ret is not used until the end of the function, it should not matter.

What a nice appeal to ridicule.

There must be a Wikipedia article about the use of Wikipedia links to argument techniques as an argument technique. So tiresome.

Probably, but that doesn't make asm a bad tool.

It also does not make it the most suitable tool, especially if we are referring to hand-optimised assembly. Getting people to write straight-forward, readable, documented HLL code in a timely manner is hard enough.

Sure all can crash, but in asm, contrary to hlls, errors have a tendency to crash more often than working by accident.
Besides, as my asm system framework has resource tracking, i'm not doing memory leaks anymore.

Every library call made with the arguments in the correct places is just as prone to crashing and just as prone to cause leaks whether you are using assembly or any other language. There are just so many ways to allocate and deallocate resources in AmigaOS.

This requires cross-function analysis. Perhaps compilers can do this, but they still have to respect the ABI.

The ABI is not really relevant when your code only used within your compilation unit. But the »official« 68k ABI is indeed really unfortunate in its insistence on using the stack instead of registers for even the most trivial call.

Wouldn't it be great if we had the best of both worlds ?

Yes. I really appreciate how E lets you write assembly anywhere in the source and even refer to variables as if they were just addresses. OTOH that makes life rather difficult for the compiler. Notably, E uses the stack for all function calls, even within a module.

As much as we don't need an FPU to do floating-point. So what ?

I mention this because you brought hardware vector processing units into the conversation when someone mentioned the usefulness of overloaded operators for matrices.

Maybe, but it's then your own code that you refactor. It's not the same thing as someone else's code.

That depends. First of all, oneself one year ago might be indistinguishable from »someone else«. Secondly, one might not have the time to do all the necessary refactoring from someone else’s code in one session, or even in one year. That’s what architecture (or the lack thereof) is about. I spent two years refactoring third-world code in my last assignment.

Spurious warnings happen when the compiler misses something or is too pedantic.
For me, many have come from C or C++ bizarre specs.
In asm i think there should not be any warnings at all, everything it reports can be treated as errors.

Compare :

 moveq #ret1,d0
 tst condition
 bne .1
 moveq #ret2,d0
.1

with :

 tst condition
 beq .2
 moveq #ret1,d0
 bra .1
.2
 moveq #ret2,d0
.1

Compare:

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

Each if is a tst. Each = is a move. If val is 0, the assignment to ret occurs twice, for no particular reason. If I were a compiler writer, I would have tried to insert a warning here that the code was nonsensical that it was writing twice to a variable before it was ever read from (unless it were declared volatile). Because this code looks like a logic error. Just returning immediately from each if statement would make the code easier to reason about.

No. If/else can only give two possibilities.

You may have more than one else.

[Thorham]

Originally Posted by idrougge

Could it be that this is also unprovable in C# because of rules regarding mutability – possibly from different threads?

Other threads can't access any of these variables in C#, so it can't be that.

[meynaf]

Originally Posted by idrougge

Sorry, I was (again) referring to val, not ret. As ret is not used until the end of the function, it should not matter.

Ok so indeed the compiler doesn't know that val can't be mutated between the ifs. This not only triggers spurious warnings, it removes optimization opportunities as well.
If the spec says otherwise then the compiler is just buggy. Else it is the language failing to provide a way to give that hint to the compiler.

Originally Posted by idrougge

There must be a Wikipedia article about the use of Wikipedia links to argument techniques as an argument technique. So tiresome.

Check articles about fallacies and tell me if you find one.

Originally Posted by idrougge

It also does not make it the most suitable tool, especially if we are referring to hand-optimised assembly.

It is the tool that gives the best result at the end, for me this is enough.

Originally Posted by idrougge

Getting people to write straight-forward, readable, documented HLL code in a timely manner is hard enough.

With that i can certainly agree.

Originally Posted by idrougge

Every library call made with the arguments in the correct places is just as prone to crashing and just as prone to cause leaks whether you are using assembly or any other language. There are just so many ways to allocate and deallocate resources in AmigaOS.

But the thing is precisely this : my asm system framework does all these calls for me.

Originally Posted by idrougge

The ABI is not really relevant when your code only used within your compilation unit. But the »official« 68k ABI is indeed really unfortunate in its insistence on using the stack instead of registers for even the most trivial call.

Right. But unless linking with code in C (that sometimes happens) i don't have anything such as a compilation unit because i'm not using a linker when i can do otherwise.

Originally Posted by idrougge

I mention this because you brought hardware vector processing units into the conversation when someone mentioned the usefulness of overloaded operators for matrices.

This is the word 'vector' which has bringed this misunderstanding.

Originally Posted by idrougge

That depends. First of all, oneself one year ago might be indistinguishable from »someone else«. Secondly, one might not have the time to do all the necessary refactoring from someone else’s code in one session, or even in one year. That’s what architecture (or the lack thereof) is about. I spent two years refactoring third-world code in my last assignment.

Well, my code from one year ago is very much the same as today. But indeed code 15-20 years ago may be quite different. You may however have noticed that the more you advance, the better the code you write and it starts to become quite stable.
Secondly, refactoring the whole code isn't necessary to prevent having to redo same code. You may refactor it routine by routine, keeping some interfaces with older code.

Originally Posted by idrougge

Compare:

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

Each if is a tst. Each = is a move. If val is 0, the assignment to ret occurs twice, for no particular reason. If I were a compiler writer, I would have tried to insert a warning here that the code was nonsensical that it was writing twice to a variable before it was ever read from (unless it were declared volatile). Because this code looks like a logic error. Just returning immediately from each if statement would make the code easier to reason about.

And again you forget that this code isn't the original one, it has been simplified to the minimal amount showing the erroneous behaviour.

Originally Posted by idrougge

You may have more than one else.

Not without an extra if.