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

[meynaf]

Originally Posted by Thomas Richter

Nobody forces you do use a specific language. I'm only against *advocating* assembler as a good language to use for others. That is the problem.

And in a similar way i am against *advocating* assembler as a bad language to use for others.

Originally Posted by Thomas Richter

You use Amiga-key shortcuts instead as this would make it a better Amiga program. There is something called the "Amiga Style Interface Guide" that provides guidelines for GUIs. One of the guideline is that menus use the Amiga-key, Amiga-C is copy, Amiga-V is paste,... etc.


This reminds me of Golded-4: It was (or is) certainly a very powerful editor, but it felt like a complete alien in the Amiga system as it used its own GUI elements. Custom size gadget, custom buttons... I would not disagree that the buttons the Os provides are "old style" and limited, but at least the system has a consistent look with them, and you can customize them to something else if you like. If program authors like Dietmar rolled their own GUI, you get kind of the same problem as in Linux: A completely inconsistent and confusing user interface.


Or in short: Don't. Find the best possible Amiga equivalent such that the program integrates nicely into the rest of the system, even if that makes it different from the original. Port the idea, not the look.

That could work for a port. But not for code that has to work unmodified in several platforms.

In addition, even if i limit myself to right-Amiga, many combinations still won't work : F1-F10, Spc, Del, Help, Backspace, etc.

[Karlos]

The issue is with those who want to force ME to use a compiler.

Who is that though? I mean everyone has strong opinions on what's the right tool for the job but nobody's "forcing" anyone to do anything. That's just silly.

[AestheticDebris]

Originally Posted by meynaf

That could work for a port. But not for code that has to work unmodified in several platforms.

In addition, even if i limit myself to right-Amiga, many combinations still won't work : F1-F10, Spc, Del, Help, Backspace, etc.

A cross-platform layer that doesn't abstract the differences in key modifiers so that each platform uses appropriate keys, isn't really very cross-platform at all.

[meynaf]

Originally Posted by Karlos

Who is that though? I mean everyone has strong opinions on what's the right tool for the job but nobody's "forcing" anyone to do anything. That's just silly.

Isn't saying a tool is inadequate, an attempt (even disguised) to at least discourage the use of said tool ?

Originally Posted by AestheticDebris

A cross-platform layer that doesn't abstract the differences in key modifiers so that each platform uses appropriate keys, isn't really very cross-platform at all.

And how to get the 'right' keys to use, according to you ?
How could the client code possibly say which keys to use, without really saying it because it's up to the layer to choose ?
For example, original program says alt-S for "save" and alt-shift-S for "save as" : what can the client code say to keep that on original platform, and the Amiga cross-platform layer could choose in place of them, especially without triggering conflicts ? Or if some options use function keys ?

[AestheticDebris]

Originally Posted by meynaf

For example, original program says alt-S for "save" and alt-shift-S for "save as" : what can the client code say to keep that on original platform, and the Amiga cross-platform layer could choose in place of them, especially without triggering conflicts ? Or if some options use function keys ?

Off the top of my head? Have the platform layer define a bunch of "meta" keycodes, so META_KEY_SAVE or META_KEY_SAVEAS would then map onto the OS dependent key combination. Although I'd probably do it all a a much higher layer, much as stuff like WPF does and define Actions that can be assigned to menu entries, buttons etc as well as.automagically responding to system wide key presses. But then I've only spent the time it took to type this thinking about it...

[Karlos]

Originally Posted by meynaf

Isn't saying a tool is inadequate, an attempt (even disguised) to at least discourage the use of said tool ?

No, it's an opinion. It's the opinion of some developers that assembler is the wrong choice for application development and that there are languages that are much better geared towards that task. It's the opinion of other developers that high level languages are lame bloatware. I prefer dealing with facts. The facts are that high level languages (let's include C in that definition) have been and continue to be responsible for the vast majority of application software produced in the last 30 years. Assembler sees much less use here, except as an optimisation aid in some tight code paths.

It's a fact that an experienced assembler programmer can beat the output of compiled languages on certain hardware but it's equally a fact that on modern hardware the gaps close and in some cases, the hardware isn't particularly developer friendly and a compiler can produce better code. However, for 68K, you do have the benefit of a fixed goalpost and the lack of investment from compiler vendors in obsolete ISA. So, it's a fact that on Amiga/68K the chances you can beat the compiler are a lot better.

Its also a fact that this previous fact may not matter. If your application is IO bound or event driven, it's spending most of it's time sleeping anyway.

Opinions are like farts. We all express them and they are rarely appreciated by others. This is probably a fact

[meynaf]

Originally Posted by AestheticDebris

Off the top of my head? Have the platform layer define a bunch of "meta" keycodes, so META_KEY_SAVE or META_KEY_SAVEAS would then map onto the OS dependent key combination.

Are you conscious the number of distinct menu items is much larger than the number of metas you can imagine ? And even more larger than the number of available keys ?

Originally Posted by AestheticDebris

Although I'd probably do it all a a much higher layer, much as stuff like WPF does and define Actions that can be assigned to menu entries, buttons etc as well as.automagically responding to system wide key presses. But then I've only spent the time it took to type this thinking about it...

Yeah, another thing that's very theoretical and easier said than done.
For now i'll use same keys everywhere (and layout menus myself as gadtools doesn't support that).

[meynaf]

Originally Posted by Karlos

No, it's an opinion. It's the opinion of some developers that assembler is the wrong choice for application development and that there are languages that are much better geared towards that task. It's the opinion of other developers that high level languages are lame bloatware.

More than an opinion, it is individual experience that differs.

Originally Posted by Karlos

I prefer dealing with facts.

Beware, as opinions are often wrongly presented as facts...

Originally Posted by Karlos

The facts are that high level languages (let's include C in that definition) have been and continue to be responsible for the vast majority of application software produced in the last 30 years.

Yeah, sadly. Buggy software, bloatwares, security issues, all continue to plague us.

Originally Posted by Karlos

Assembler sees much less use here, except as an optimisation aid in some tight code paths.

It is much more widely used in the case of retrocomputing.

Originally Posted by Karlos

It's a fact that an experienced assembler programmer can beat the output of compiled languages on certain hardware but it's equally a fact that on modern hardware the gaps close and in some cases, the hardware isn't particularly developer friendly and a compiler can produce better code.

The compilers produce "better" code only because nobody really challenges them.

Originally Posted by Karlos

However, for 68K, you do have the benefit of a fixed goalpost and the lack of investment from compiler vendors in obsolete ISA. So, it's a fact that on Amiga/68K the chances you can beat the compiler are a lot better.

It's not that the chances are just "better", it's that i beat the crap out of them every time.
And again, speed isn't the only advantage. It is also quite satisfying to make code shorter.

Originally Posted by Karlos

Its also a fact that this previous fact may not matter. If your application is IO bound or event driven, it's spending most of it's time sleeping anyway.

Maybe, but it'll still be shorter, faster to startup and having smaller memory footprint.

Originally Posted by Karlos

Opinions are like farts. We all express them and they are rarely appreciated by others. This is probably a fact

Oh sorry, i've just... errhh... never mind.

[Karlos]

It is much more widely used in the case of retrocomputing

Granted. But what proportion of all application software produced in the last 30 years is that? And how much of that proportion is in turn due to the lack of modern HLL support for "retro" systems or conversely, where tooling exists, is due to the simple preference to write code for those systems close to the metal as part of the retro experience?

Yeah, sadly. Buggy software, bloatwares, security issues, all continue to plague us.

Not all code written in HLL is bugged, insecure bloatware and not all code written in assembler is compact, performant perfection.

Maybe, but it'll still be shorter, faster to startup and having smaller memory footprint.

It is still a fact that this may not matter. If the program reacts to input within whatever timescale is less than user perception or uses a few KB more or less, on a system with memory capacity measured in megabytes, the end user - that mythical beast who judges our effort - isn't likely to notice or care. Except when that end user is yourself, perhaps.

[meynaf]

Originally Posted by Karlos

Granted. But what proportion of all application software produced in the last 30 years is that?

Why should we care ? We are on a retro system forum, on a thread about Asm vs C explicitly mentioning the Amiga in its title.
Or are you attempting a strawman fallacy by going out of the subject that is pure Amiga coding, with me having absolutely never defended using asm on "modern" platforms ?
Anyhow, most of this application software has been made on machines where asm isn't a good option, not because asm itself is bad, but because they run on cpus with unfriendly instruction set architectures.

Originally Posted by Karlos

And how much of that proportion is in turn due to the lack of modern HLL support for "retro" systems or conversely, where tooling exists, is due to the simple preference to write code for those systems close to the metal as part of the retro experience?

Are the reasons really important ? I do not know or even care why other asm coders prefer asm. Everyone is free.

Originally Posted by Karlos

Not all code written in HLL is bugged, insecure bloatware and not all code written in assembler is compact, performant perfection.

Not all, but still the most part.

Originally Posted by Karlos

It is still a fact that this may not matter. If the program reacts to input within whatever timescale is less than user perception or uses a few KB more or less, on a system with memory capacity measured in megabytes, the end user - that mythical beast who judges our effort - isn't likely to notice or care. Except when that end user is yourself, perhaps.

You seem to forget that there isn't just a single program running in a machine. So a few KB more, plus a few KB more, plus a few KB more...

[Karlos]

It's not a strawman argument, it's an observation on where the prevailing attitudes towards HLL v assembler come from. I personally don't care what you want to write your code in, I have no investment in it whatsoever.

Nevertheless, the fact remains that for application development, HLL are successful, far moreso than assembler. Even on the Amiga, how much productivity software is or was written in HLL versus assembler? Games, libraries, datatypes and small utilities seem to be the primary target there. And yes, some large applications are written in assembler, but are they the rule or the exception?

[meynaf]

Originally Posted by Karlos

It's not a strawman argument, it's an observation on where the prevailing attitudes towards HLL v assembler come from. I personally don't care what you want to write your code in, I have no investment in it whatsoever.

Nevertheless, the fact remains that for application development, HLL are successful, far moreso than assembler. Even on the Amiga, how much productivity software is or was written in HLL versus assembler? Games, libraries, datatypes and small utilities seem to be the primary target there. And yes, some large applications are written in assembler, but are they the rule or the exception?

Why would the fact something's widely used or not count ? This is just a case of argumentum ad populum.

[Karlos]

Originally Posted by meynaf

Why would the fact something's widely used or not count ? This is just a case of argumentum ad populum.

Isn't it obvious? There's usually a good reason something is widely used and conversely why something else is not, in any field of endeavour. This is not argumentum ad populum because we are not talking about opinions any more we are talking about measurable outcomes. The measurable outcome here is that, quelle surprise, tools (i.e. HLL) designed to facilitate the development of applications have had more success in their delivery than languages designed to instruct the CPU, instruction by instruction, precisely you want to do. The reason for that is again obvious. It takes more code and more effort to do things the lower down you go. And sure, you may have written some library of modular assembler that you now use to take the effort out of this, but that was still effort expended at some point. You are left with the effort of whatever else it is your application needs to do, still left to expend.

HLL allow more people to write more code, more quickly and this trend generally becomes stronger the higher up you go. More people writing more code, more quickly means more software being developed. You can argue over the quantity/quality ratio but the fact remains a lot of good software is written in HLL, even on the Amiga, that might not exist at all otherwise. You can set up a Window and deal with IDCMP input in not much imperative C code at all, but when it's as simple as instantiating an object and attaching observers to it in some even higher level language, you might even be doing this in a single line of code. Naturally, there's a price to pay with all of this, your code becomes more and more the glue between components you didn't write, but if your goal is to get something done in a timely fashion, it's a trade-off to be evaluated because it may make the difference between your application ever getting written or not.

[meynaf]

Originally Posted by Karlos

Isn't it obvious? There's usually a good reason something is widely used and conversely why something else is not, in any field of endeavour. This is not argumentum ad populum because we are not talking about opinions any more we are talking about measurable outcomes.

Of course yes it is completely about opinions. It is opinions that drive the choice of a programming language.

Originally Posted by Karlos

The measurable outcome here is that, quelle surprise, tools (i.e. HLL) designed to facilitate the development of applications have had more success in their delivery than languages designed to instruct the CPU, instruction by instruction, precisely you want to do. The reason for that is again obvious. It takes more code and more effort to do things the lower down you go. And sure, you may have written some library of modular assembler that you now use to take the effort out of this, but that was still effort expended at some point. You are left with the effort of whatever else it is your application needs to do, still left to expend.

Sure, HLLs are supposed to facilitate the development of applications. But they don't, at least not as much as you seem to believe. If current languages were satisfying, why would new ones appear every now and then ?

Originally Posted by Karlos

HLL allow more people to write more code, more quickly and this trend generally becomes stronger the higher up you go. More people writing more code, more quickly means more software being developed. You can argue over the quantity/quality ratio but the fact remains a lot of good software is written in HLL, even on the Amiga, that might not exist at all otherwise. You can set up a Window and deal with IDCMP input in not much imperative C code at all, but when it's as simple as instantiating an object and attaching observers to it in some even higher level language, you might even be doing this in a single line of code. Naturally, there's a price to pay with all of this, your code becomes more and more the glue between components you didn't write, but if your goal is to get something done in a timely fashion, it's a trade-off to be evaluated because it may make the difference between your application ever getting written or not.

What you wrote here is, for the most part, not relevant for Amiga.
On the Amiga, the fact is that there is a magnitude more software that wouldn't exist if it wasn't written in asm than the other way around.

[Thomas Richter]

Originally Posted by meynaf

What you wrote here is, for the most part, not relevant for Amiga.
On the Amiga, the fact is that there is a magnitude more software that wouldn't exist if it wasn't written in asm than the other way around.

Why not? Let's just check. Of the kickstart, it is probably 40% assembler and 60% C, which depends a little bit on how you count because the workbench and icon libraries are both in C, but either workbench or kickstart depending on revision. Historically, it was probably even 40% C, 20% assembler and 20% BCPL because the dos.library and the OFS were both in BCPL.


For the workbench, it was probably 10% assembler and 90% C.


For P96, it is approximately 20% assembler for the core and 80% C for the rest, for the drivers, it is quite the reverse with the majority of them being in assembler, or mostly in assembler with some minor parts in C.


Thus, this seems to give you a fine pattern: The lower you go, the more assembler it becomes, and the higher you go, the less. That is not at all surprising from what I said before. Thus, whoever made a decision which language to pick, the outcome of the decision seemed to be in good agreement with my recommendation.


It also shows something else: The console.device is entirely in assembler, and it is not in a maintainable state. The graphics library is probably to 40% in assembler, and not in a maintainable state. Intuition is in C and well-maintained, the con-handler is in C and well maintained, and the shell is in C and well-maintained. The only thing that is in decent shape in assembler is probably exec and expansion, both low-level tools. Well, seek a pattern?

[meynaf]

Originally Posted by Thomas Richter

Why not? Let's just check. Of the kickstart, it is probably 40% assembler and 60% C, which depends a little bit on how you count because the workbench and icon libraries are both in C, but either workbench or kickstart depending on revision. Historically, it was probably even 40% C, 20% assembler and 20% BCPL because the dos.library and the OFS were both in BCPL.


For the workbench, it was probably 10% assembler and 90% C.


For P96, it is approximately 20% assembler for the core and 80% C for the rest, for the drivers, it is quite the reverse with the majority of them being in assembler, or mostly in assembler with some minor parts in C.


Thus, this seems to give you a fine pattern: The lower you go, the more assembler it becomes, and the higher you go, the less. That is not at all surprising from what I said before. Thus, whoever made a decision which language to pick, the outcome of the decision seemed to be in good agreement with my recommendation.

And what does this change ? Nothing, actually.
Except that if more parts had been in asm, more modules would have been able to fit in space limited rom.

Originally Posted by Thomas Richter

It also shows something else: The console.device is entirely in assembler, and it is not in a maintainable state. The graphics library is probably to 40% in assembler, and not in a maintainable state. Intuition is in C and well-maintained, the con-handler is in C and well maintained, and the shell is in C and well-maintained. The only thing that is in decent shape in assembler is probably exec and expansion, both low-level tools. Well, seek a pattern?

And who decides something is in a maintainable state or not ? If this is you or anyone unable to code proper asm, sorry, it is biased.
You are saying that to people who have not seen the sources and are unable to verify your claims.

[Karlos]

Originally Posted by meynaf

And what does this change ? Nothing, actually.
Except that if more parts had been in asm, more modules would have been able to fit in space limited rom.

It may be a controversial opinion but I actually think cramming a ton of stuff into the ROM was probably not a great idea. You need the minimum resources to boot the machine, initialise the hardware/drivers and hand off to a disk based OS if one is present. ROM based operating systems just end up being more expensive and more of a faff for the user than disk based media.

And who decides something is in a maintainable state or not ? If this is you or anyone unable to code proper asm, sorry, it is biased.

The people that have to maintain it and build upon it.

You are saying that to people who have not seen the sources and are unable to verify your claims.

I've seen them, but I don't expect you to agree with my assessment.

[StingRay]

Originally Posted by Thomas Richter

It also shows something else: The console.device is entirely in assembler, and it is not in a maintainable state.

That's the fault of the programmer(s), not the used programming language.

[Thomas Richter]

Originally Posted by meynaf

And what does this change ?

Hopefully your opinion by providing some hard facts.

Originally Posted by meynaf

If this is you or anyone unable to code proper asm, sorry, it is biased.

You are saying that to people who have not seen the sources and are unable to verify your claims.

The problem is the "data organization" side, much more than the "opaque code side". C at least provides you with proper tools to structure your data. The console.device is a fine example of where such support was missing. The character map of the console.device is essentially created around two big arrays, one array containing characters, the other containing attributes. Offsets into this array are (in a rather opaque way) kept as pointers pre-divided by 2 into this array (in some way - yes, "pointer over two" as an idea), without proper documentation. Essentially, "the only noteworthy data structure is the array".


It "somehow" works, but due to lack of proper indication of the structures and lack of documentation, the whole thing is not in a maintainable state.


Of course, one can write bad code in any language if one really insists, but higher programming languages at least provide you with tools to express your ideas in a (even machine-readable) readable way. Data structures you can of course also use in assembler, but you need to be in the "culture" of using them, and whoever wrote or updated the console was not.


Thus, again, if I'm against recommending assembler as programming language because the culture of "structuring concepts" you get with training in a higher language you are likely going to miss in assembler. The console and graphics are prime examples of the lack of such thinking. Both are more "piles of code", but not "structured ideas".



From the style of Exec, I would believe Carl had some background in higher languages as there is structure, even though assembler does not enforce it.

[Thomas Richter]

Originally Posted by StingRay

That's the fault of the programmer(s), not the used programming language.

No, and that's where I disagree. Higher languages provide you with the toolset to express your ideas properly. Assembler does not. Data structures are one important concept one need to be trained in to write understandable and maintainable programs, but there is nothing in assembler that pushes you in this direction. It is a matter of education you get as "by-product" from learning a higher language - thinking abstractly in concepts rather than thinking of "pushing values around" as you do in assembler.