Apollo Maggie 3D Chip - Preview Demo

[meynaf]

Originally Posted by Promilus

Sure. But the big question here isn't how fast YOU can write the same functionality in C but how fast average C developer can get ESPEasy-like functionality (node-node intercommunication through wifi, TCP/IP, MQTT protocol, drivers for plenty sensors, actuators, data logger, embedded scripting language, web gui and Over The Air upgrade tool) and in contrast how long would it take to average asm developer to do the same. I expect only honest answer at this one.

An average developer wouldn't be able to do that, regardless of the language.
And anyway, not a good example : this is not typical stuff we're going to see on our 68k machines - if at all.

[meynaf]

Originally Posted by Promilus

All I ever wrote is using HLL makes development easier, faster, code portable, better manageable and porting stuff from PC (either based on original source code or opensource implementation of game engine) is best proof of that.

The problem is that stuff ported from PC like that, is dead slow. I know, i ported a few things this way. And the only way to fix that is : rewrite it in ASM...

[Promilus]

And anyway, not a good example : this is not typical stuff we're going to see on our 68k machines - if at all.

Sure it is. Well, not best example as something which amiga could use. But that was just example of how complex hobbyists (!!) project can get and that's nothing in comparison how complex application amiga can run.

The problem is that stuff ported from PC like that, is dead slow

Some ports - yes. All ports - that's an exaggeration. Both Doom and Quake seems fairly optimized and while Quake is still more of a slideshow than FPS it's what PC players experienced with their first pentiums or last 486s (and no 3d accel). Projects like OpenRA, Openlara, GemRB, Dune Legacy, Settlers BTTR, VCMI etc. etc. are potential games which might at some point appear on Amiga. Doesn't mean it all is fast or bugfree. But it IS where there could have been nothing.

[meynaf]

Originally Posted by Promilus

Sure it is. Well, not best example as something which amiga could use. But that was just example of how complex hobbyists (!!) project can get and that's nothing in comparison how complex application amiga can run.

Sure, but a complex application is just made of many simpler modules - which can in turn be written in any language, and not necessarily the same.

Originally Posted by Promilus

Some ports - yes. All ports - that's an exaggeration. Both Doom and Quake seems fairly optimized and while Quake is still more of a slideshow than FPS it's what PC players experienced with their first pentiums or last 486s (and no 3d accel). Projects like OpenRA, Openlara, GemRB, Dune Legacy, Settlers BTTR, VCMI etc. etc. are potential games which might at some point appear on Amiga. Doesn't mean it all is fast or bugfree.

Well, most ports at least are slow.
Of course, they weren't very fast on the PC to start with, i.e. they often required a higher configuration than ought to be.

Originally Posted by Promilus

But it IS where there could have been nothing.

This is the only advantage i can see for compiled code.
As it does not help that much in later handling the code : rewriting C into asm isn't an easy task but the problem does not come from writing the asm : it comes from understanding what is that ***** original code doing ! Well, of course good C is easier to handle than bad C, but nevertheless.

[dreadnought]

Originally Posted by Promilus

Both Doom and Quake seems fairly optimized and while Quake is still more of a slideshow than FPS it's what PC players experienced with their first pentiums or last 486s (and no 3d accel).

486 yes, because of no FPU, but even on early Pentiums you could hit 15-20fps. Not ideal, but okay for single player. Anyway, the crucial point in context of this thred is that this was happening in the late Nineties, and we're now in the year 2022.

Originally Posted by Promilus

Projects like OpenRA, Openlara, GemRB, Dune Legacy, Settlers BTTR, VCMI etc. etc. are potential games which might at some point appear on Amiga. Doesn't mean it all is fast or bugfree. But it IS where there could have been nothing.

Tbh, nothing could be perhaps better in at least some of these cases. For the life of me I will never understand the reasons to play gimped versions of these great games, only for the sake of doing it on Amiga (sort of). Frankly, I'd much rather see the most amateurish, bottom PD-level game instead, as long as it was an original creation.

[Promilus]

Frankly, I'd much rather see the most amateurish, bottom PD-level game instead, as long as it was an original creation.

As mentioned earlier I'd welcome such title myself more than some PC port but ppl spent their money for pentium-class CPU and fast RTG and expect something in return. AFAIK all titles with heavy use of SAGA and AC68080 features are limited to what Gunnar and his kid made and titles with most impact recently are port of devilutionx and sonic. Those accelerators were made to be used. With all of their features. I just doubt there's much of the interest to create brand new games for that system outside of (hard)core members circle. V4 has been here for few years now and there's no flood of new titles. That's why ports are important as well.

[Seiya]

Amiga 68k softwares must run on any Amiga 68k model, not for a niche model only, because the risk is to have a more fragmented community and more hostility between various users in the long run.

[Promilus]

Well problem with that is 060-based turbo accelerators are rather scarce, just as expensive and they are slower (compute performance) so it's rather silly to expect games NOT being created to Apollo card users just because other cards can't keep up. Will PiStorm and Buffee make difference? Buffee in it's current form is just 68000 replacement. Chip itself is System on Package so consist SoC itself, memory die and few other things on common package. And from all of that only Amiga 68k signals come out. There's NAND memory controller (so eMMC, cheap "SSD" for Amiga) and PowerVR graphics integrated but unused. Maybe next design will use it. Or maybe next design will be on even newer chip (there are new with Cortex A53 and R5F and it costs roughly 3x more per chip and those from TI itself doesn't integrate RAM etc. so cost can go higher but it still is less than Cyclone V5 with 77k LE). PiStorm has it's own shortcomings. There are (are there still?) problems with access to chipset, musashi is slow but fairly compatible while emu is blazing fast but as JIT it either causes distortions or just crash the app itself (I believe that mostly happens with self modifying code though). But hardware-wise there's so much going on it would be a shame not to see any fruits of their labor (new apps and games).

[Thomas Richter]

Originally Posted by meynaf

You are charging the language for something it is not responsible of.

But of course it is! A language can (and will) check interfaces for you, for C for example the calling parameters. A language allows you to express, with the synatx of the language, to express your intentions. All this syntactic sugar higher programming languages offer is to "organize code" in a way that eases creation of a project.



A computer language is not just "something that will be executed by the CPU in the end", but it is something "a human needs to work on", so it is documentation and expression.

Originally Posted by meynaf

And remember you too have to deal with the consequences of your decision. Like wasting 50-75% of your raw cpu power for nothing,

First of all, it is hardly 50-75% but probably like 10%, if at all, and second it is "for something", and that something is mainainable code. If you need to be fast, you first check whether you are using the right algorithm for the job, and then you potentially isolate bottlenecks, optimize those, and if that does not help, you probably write some minor parts in assembler where it matters.


This nice toy example posted above where people compared a sort algorithm in C with an identical one in assembler was actually a very good example. It showed that for the simple bubble-sort, C code was only 7% slower, but it also showed something very important, namely that you need to use the right algorithm to begin with. If that program would have used a better algorithm, it could be more than 100% faster, depending on the data. Bubble sort is O(N^2), quicksort is O(N log N), so by choosing a better algorithm, you can gain a lot more than by choosing another language.

Originally Posted by meynaf

making memory hogs, and ultimately software that has potential exploits (and many hidden bugs) because "high level" language did hide something that would have been otherwise obvious in asm.

Actually, it is just the other way around. A high level language does not "hide" anything from you, but it helps you to avoid thinking about problems that were already solved by somebody else. In assembler, you need to solve them again, and chances are that you make a mistake somebody else already avoided. In assembler, you need to copy a string manually, you need to ensure the target buffer is large enough. Bad idea. In C, you have strcpy, bad idea because it requires the same check. In C++, you have std::string, which is always the right size because the language cares for you. It is one problem avoided. Does it matter? In most cases, no.


And this is just a trivial example.

Originally Posted by meynaf

Yes it is more rare today than it used to be, but you have to admit the fact that mainstream machines having very poor asm does not help.

Actually, x64 became a lot better with orthogonal and larger register sets. I still don't want to write in assembler, but it is not necessary anymore as compilers also got a lot better.

Originally Posted by meynaf

I am only telling you that every program can be done in asm and that for someone used to it, it's not as hard as it looks.

That's not feasible, and you know. Write a web browser in assembler.

Originally Posted by meynaf

That not everyone can do it, that you can't do it, that ThoR can't do it, that it's an horror on most cpu families, does not change that fact.

Talk is cheap. I bet you have never written any suitably complex program. With all the trivial toy examples with simple control logic, that's all simple, but I have gone through some sufficiently large sufficiently complex assembler projects to know where the deficiencies are. ViNCEd is an example of that experience - it is all assembler, and that caused just unnecessary complexity. The same program in C wouldn't be any less powerful or less performing, but it would have been ready in a fraction of the time, and it would have been a lot easier to update and maintain it.


There is rarely any program you write and then "it just works", but it is more write-update-fix-update-fix... because you get customer requests, feature requests, bug reports, and processing that with assembler is a PITA.



Just a very simple example is change of interfaces: Consider you need to update a function to just take another parameter, as part of a feature request. In Assembler, you have to go through the entire project and find calls to this function, ensure you get the argument passed in. You probably need to re-allocate registers in each caller. In a higher language, the compiler will check for you.


For some reason, you seem to assume that your development cycle is "write once - run program", but that's not how reality works. It is more "write-update-write-update-write-update" in an endless loop, and the "update" is not because I was doing bugs, but because people ask for features and improvements.

Originally Posted by meynaf

I made many ports from other platforms, none of which involved C on my side (but did involve, otoh, lots of brain damaged compiler-generated horrors).
At least with ASM a port can be made without having the source code.

Not exactly. You can create a lookalike of the original, with some (or huge) effort, and you need to spend another huge effort to update the thing later on. The problem is that in order to update or maintain somebody elses code, you actually need to understand the logic in that code, and a high level language does express this logic in a much better more readable, more understandable way than the actual assembler. This is what high level languages are good for. Expressing intentions!

Originally Posted by meynaf

A now this is becoming preposterous.
I have written code for many platforms, with many languages. It ranges from Pic to C370, with everything in between including pc programs in cpp and web apps in .net. I've been involved in a team that had to build a whole ISP solution.
And i did that better than all those guys who didn't have asm knowledge.

But, apparently, you haven't learned what these languages are good for.

Originally Posted by meynaf

This argument can be returned against you quite easily. Just replace high-level by asm.

By that, I hardly get better software. I maybe get 10% faster software if I had the chance to pick the right algorithm to begin with, but hardly more maintainable software, and hardly software with less bugs.

Originally Posted by meynaf

But again, maybe large projects are large more due to being poorly designed (and/or using the wrong tools) rather than what their inherent entropy involves.

Sure projects tend to be designed badly, that's normal. But how much effort does it take to change the design if that turns out to be the case, if the project is in assembler, compared to a project in a higher language.

Originally Posted by meynaf

But writing assembler is a way to avoid complexity

Hardly. Complexity comes with the problem you need to solve. A problem doesn't get smaller by the language. Assembler just *adds* complexity on top of that by requiring you to do tasks the compiler or language can do for you instead. Like checking arguments or pointers.

[Thomas Richter]

Originally Posted by Seiya

Amiga 68k softwares must run on any Amiga 68k model, not for a niche model only, because the risk is to have a more fragmented community and more hostility between various users in the long run.

That is, exactly, the problem here. It's creating a niche in a niche. Things would be very different if this would be an active platform with a sufficiently large user and customer base where you could tolerate incompatibilities because old obsolete software would be replaced by better new software using the new hardware capabilties.


However, that's not how the Amiga "market" works.Who is writing this software? The way how it is - we all depend on old software continue to work. I don't mind about the new instructions, registers... I wouldn't use anyhow, but I worry about old features getting removed or only implemented partially. First, get the basic job done, then care about the extras. But, the way how this goes, it is mostly about "shiny new features" rather than "getting the job done first".


Certainly, the latter is more boring and more painful, but it a lot more important.

[grond]

But a lot of the old software works fine on the new hardware. It is only some new specific software that doesn't run on old hardware. Of course, this new software is in the niche inside the niche but people with this niche hardware can walk out of their niche into the bigger niche.

[Bruce Abbott]

Originally Posted by Thomas Richter

It showed that for the simple bubble-sort, C code was only 7% slower,

For a generic bubble-sort sure, but a good asm coder is always looking for ways to make the code even more efficient.

it also showed something very important, namely that you need to use the right algorithm to begin with. If that program would have used a better algorithm, it could be more than 100% faster, depending on the data.

Yep, that's why comparing code snippets may give a false impression of a language's efficiency.

Yesterday I compared the speed of two 68k assemblers for the Amiga - ProAsm, which is written in pure 68k assembler, and vasm which is written in C. When assembling a typical medium sized project, ProAsm was 27 times faster than vasm. This speed increase is mostly due to using more efficient algorithms.

Unfortunately the source code for ProAsm was never published. However since it was written in asm I know that a disassembly is not too far off from the original source. This makes it my best bet for creating an assembler that works 'perfectly' at a fast speed. vasm has source code so it is easy to modify, but it's dog slow in comparison which makes it unattractive.

[OlafSch]

Originally Posted by meynaf

An average developer wouldn't be able to do that, regardless of the language.
And anyway, not a good example : this is not typical stuff we're going to see on our 68k machines - if at all.

sigh

There is no language perfect for every task

It all depends what you want to do
Automate something
Develop applications
develop low-level stuff like drivers
which platforms do you target (f.e. desktops or app development)
how much developers are involved?
what software development platforms are available targetting these platforms? How well supported and updated are these? Can they be extended? Which libraries/dll are directly supported and how good?

The class-libraries, extensions and OS support are very important if you look at how efficient you can create something working. But of course you add a lot of overhead with it making the exe bigger and in many cases the software slower. All comes with a price.

Even in old days 68k asm was used but mostly for speed reasons in some cases. Mostly it was a mixture of high-level language and asm. You cannot say asm is king, it all depends on what you want to do. Try to do a database based application with asm, it will unbelievable fast but you will propably die before it will be ready. On the other hand a game engine or raytracer in optimized asm would benefit very much from it. But both have the advantage to not depending on other resources.

[Thomas Richter]

Originally Posted by Bruce Abbott

For a generic bubble-sort sure, but a good asm coder is always looking for ways to make the code even more efficient.

For that, you first need to know what is the most efficient algorithm for your problem. Sure, for a simple sort, things may be rather obvious, but in practice, things are less obvious and as problems are a moving target, algorithms to solve these problems are as well.


Programming is not a static "problem->solution" job. It is a "problem->solution->new problem->next solution" job. The day you're ready with your first assembler approximation, I've already found better solutions for the next problem to come.

Originally Posted by Bruce Abbott

Yesterday I compared the speed of two 68k assemblers for the Amiga - ProAsm, which is written in pure 68k assembler, and vasm which is written in C. When assembling a typical medium sized project, ProAsm was 27 times faster than vasm. This speed increase is mostly due to using more efficient algorithms.

Fine example. So let's look at this: What does the "27 times faster assembling" buy you? Next to nothing. But let's look at the product: "ProAsm", last Aminet release 1997. Vasm - last release... I don't know, probably this year?


Now, that tells you a lecture more than the speed. Asm source is "outdated, unmaintained". High-level language source may be less efficient, but closer to the actual problem you want to solve.

Originally Posted by Bruce Abbott

Unfortunately the source code for ProAsm was never published. However since it was written in asm I know that a disassembly is not too far off from the original source. This makes it my best bet for creating an assembler that works 'perfectly' at a fast speed. vasm has source code so it is easy to modify, but it's dog slow in comparison which makes it unattractive.

Quite the other way round. The speed of the assembler does not matter much, but whether it works correctly and makes its job matters a lot. Will you update ProAsm? I doubt it. It's not worth the investment of time.


That is *exactly* the problem with assembler code.

[sean_sk]

Originally Posted by Seiya

Amiga 68k softwares must run on any Amiga 68k model, not for a niche model only, because the risk is to have a more fragmented community and more hostility between various users in the long run.

What a load of nonsense! By that reckoning, there should be NO AGA specific software. Give me a break!

[Thomas Richter]

This argument was probably correct 25 years ago where we had new development and a larger customer base. 25 years ago, you could also expect that users jump on a new hardware base, and vendors would provide software for it.

However, that hardware base turned out to be the PC, and thus Amiga stopped being an active platform.

[sean_sk]

Originally Posted by Thomas Richter

Amiga stopped being an active platform.

I fail to see why that should dissuade anyone from at least having a shot at developing the platform further, especially if they have the means to do so. If a person doesn't want to buy into it, then move on.

[phx]

Originally Posted by Bruce Abbott

Yesterday I compared the speed of two 68k assemblers for the Amiga - ProAsm, which is written in pure 68k assembler, and vasm which is written in C. When assembling a typical medium sized project, ProAsm was 27 times faster than vasm. This speed increase is mostly due to using more efficient algorithms.

I doubt that. ProAsm is faster because it was written in 68k assembler for AmigaOS only, and certainly uses a lot of assumptions and short cuts. vasm, on the other hand, is much more complex and can do many things which would probably require a complete rewrite of ProAsm to support them, because it is not that flexible. Most important, vasm is portable to any system which has a working ANSI-C compiler, which also makes the code more general and therefore slower.

If you like to develop and assemble on your Amiga directly I would never recommend vasm. There are enough alternatives which work fine. Starting with 060 or modern systems I wouldn't miss the features of vasm and assembly time is neglectable.

Originally Posted by Thomas Richter

Now, that tells you a lecture more than the speed. Asm source is "outdated, unmaintained". High-level language source may be less efficient, but closer to the actual problem you want to solve.

Right. I think nobody would doubt that (maybe except meynaf). The two main reasons for using HLL are: Maintainability. Portability.

The two main reasons for using 68k assembler are: Writing Amiga programs which are performance-critical (mainy games and demos). Having fun with 68k coding and optimization. There is nothing wrong with that!

[meynaf]

Originally Posted by Thomas Richter

But of course it is! A language can (and will) check interfaces for you, for C for example the calling parameters. A language allows you to express, with the synatx of the language, to express your intentions. All this syntactic sugar higher programming languages offer is to "organize code" in a way that eases creation of a project.

A computer language is not just "something that will be executed by the CPU in the end", but it is something "a human needs to work on", so it is documentation and expression.

Interfaces are not fully checked, as only the type of the data is checked - and if it is wrong then the program will not work so it's easy to debug anyway. It will not see anything if the data is of same type or can be silently converted but does not contain the right data.

About "organize code", i want to do that myself. As what is made by HLLs is quite often inadequate for the task at hand and we end up spending more time fighting the development environment than doing actual code.

Originally Posted by Thomas Richter

First of all, it is hardly 50-75% but probably like 10%, if at all, and second it is "for something", and that something is mainainable code. If you need to be fast, you first check whether you are using the right algorithm for the job, and then you potentially isolate bottlenecks, optimize those, and if that does not help, you probably write some minor parts in assembler where it matters.

No, it is 50-75% and sometimes a lot more - i could rewrite some code to be 14 times faster than before...
If it's just 10% then the code isn't cpu bound or nobody did proper asm optimization (a likely case for pc-like machines).
Fancy a code contest to prove your point maybe ?

Originally Posted by Thomas Richter

This nice toy example posted above where people compared a sort algorithm in C with an identical one in assembler was actually a very good example. It showed that for the simple bubble-sort, C code was only 7% slower, but it also showed something very important, namely that you need to use the right algorithm to begin with. If that program would have used a better algorithm, it could be more than 100% faster, depending on the data. Bubble sort is O(N^2), quicksort is O(N log N), so by choosing a better algorithm, you can gain a lot more than by choosing another language.

That's comparing quickly written asm code (and for a bogus cpu) with good C code using all optimization options (with a good compiler). Yet asm still wins in all cases.
Yes a better algorithm can help, i wouldn't use bubble sort anyway in asm, but sometimes it's not enough. My asm implementation of jpeg's "slow int" DCT ended up significantly faster than compiled version of "fast int" one.

Originally Posted by Thomas Richter

Actually, it is just the other way around. A high level language does not "hide" anything from you, but it helps you to avoid thinking about problems that were already solved by somebody else. In assembler, you need to solve them again, and chances are that you make a mistake somebody else already avoided. In assembler, you need to copy a string manually, you need to ensure the target buffer is large enough. Bad idea. In C, you have strcpy, bad idea because it requires the same check. In C++, you have std::string, which is always the right size because the language cares for you. It is one problem avoided. Does it matter? In most cases, no.

Nope - HLLs do things by themselves, be it adequate things or not. Sometimes it's not.
In asm, true, i had to solve these, but not again and again for every project. I wrote my own string handling routines to handle all this buffering issues and more, same for dynamic arrays. Now i just reuse that.

Originally Posted by Thomas Richter

And this is just a trivial example.

Indeed. HLLs fail even more when it's not trivial, for the simple reason their designers couldn't think about every possible case.

Originally Posted by Thomas Richter

Actually, x64 became a lot better with orthogonal and larger register sets. I still don't want to write in assembler, but it is not necessary anymore as compilers also got a lot better.

Well, still not orthogonal i'm afraid, but certainly better than Mips and Alpha for example (or even PPC or Arm).
But my point is only about 68k as it's the only architecture for which asm is enjoyable (except my own vm but it's another story).

Originally Posted by Thomas Richter

That's not feasible, and you know. Write a web browser in assembler.

Not feasible ? What a joke !
You have to understand that everything becomes asm one day or another, be it by hand or by compilation. So, by definition, everything is doable in asm.
I could easily fool you
But i will not. If i can do it in another language, i can do it in asm - but due to the everchanging web specs, it's a full day job and not for a single coder. I have better ways to use my time.

Originally Posted by Thomas Richter

Talk is cheap. I bet you have never written any suitably complex program. With all the trivial toy examples with simple control logic, that's all simple, but I have gone through some sufficiently large sufficiently complex assembler projects to know where the deficiencies are. ViNCEd is an example of that experience - it is all assembler, and that caused just unnecessary complexity. The same program in C wouldn't be any less powerful or less performing, but it would have been ready in a fraction of the time, and it would have been a lot easier to update and maintain it.

Talk is cheap indeed.
You can always find examples of bad software, no problem. You can't be sure, however, that a C version wouldn't have been worse.
I can give an example too. Take MEmacs from original AmigaOS (up to V39, it's maybe fixed later, i dunno). It's all C. It's terrifyingly slow when you open or write large files, but not only. Try to search for a text containing accentuated characters (f.e. umlauts) and it will fail, mismatching them for control chars. And that, due to signedness of char (something that does not happen in asm).

Originally Posted by Thomas Richter

There is rarely any program you write and then "it just works", but it is more write-update-fix-update-fix... because you get customer requests, feature requests, bug reports, and processing that with assembler is a PITA.

This is a PITA regardless of the language. Customers always want the moon or don't really know what they want. It does not depend on the language.
Bug reports are there because you made mistakes and/or did not use the right tool (though often there is none available).

Originally Posted by Thomas Richter

Just a very simple example is change of interfaces: Consider you need to update a function to just take another parameter, as part of a feature request. In Assembler, you have to go through the entire project and find calls to this function, ensure you get the argument passed in. You probably need to re-allocate registers in each caller. In a higher language, the compiler will check for you.

Yes the compiler will check, forcing you to perform all changes before you can do any test. In asm you can do it step by step, which is very valuable for big changes.
So often i wanted to do changes (in somebody else's code) and ended up with many compilation errors. Damned C code is fragile as a soap bubble (cpp is even more).

Originally Posted by Thomas Richter

For some reason, you seem to assume that your development cycle is "write once - run program", but that's not how reality works. It is more "write-update-write-update-write-update" in an endless loop, and the "update" is not because I was doing bugs, but because people ask for features and improvements.

Not all projects have people constantly asking for extras, and you can always say no to avoid feature creep.
But in any case you're indeed locked in that loop because compiled code is never satisfying.

Originally Posted by Thomas Richter

Not exactly. You can create a lookalike of the original, with some (or huge) effort, and you need to spend another huge effort to update the thing later on. The problem is that in order to update or maintain somebody elses code, you actually need to understand the logic in that code, and a high level language does express this logic in a much better more readable, more understandable way than the actual assembler. This is what high level languages are good for. Expressing intentions!

But what i do is straight 1:1 port, not a lookalike of the original.
And no, high level languages aren't exactly readable. No language actually is. Take a random source in a random project on the net, chances are good it doesn't even say what it's supposed to achieve !
People trust HLLs too much for readability, a big mistake. I rather trust my comments.

Originally Posted by Thomas Richter

But, apparently, you haven't learned what these languages are good for.

They weren't good for anything, only usable and not too bad. It was just that nothing better was available.

Originally Posted by Thomas Richter

By that, I hardly get better software. I maybe get 10% faster software if I had the chance to pick the right algorithm to begin with, but hardly more maintainable software, and hardly software with less bugs.

Then asm is just not for you, it's not dramatic.

Originally Posted by Thomas Richter

Sure projects tend to be designed badly, that's normal. But how much effort does it take to change the design if that turns out to be the case, if the project is in assembler, compared to a project in a higher language.

But this is precisely the point - in asm it never ends up in bloatware.
Anyway, in all languages it's probably easier to just rewrite it all, so original language does not matter that much here.

Originally Posted by Thomas Richter

Hardly. Complexity comes with the problem you need to solve. A problem doesn't get smaller by the language. Assembler just *adds* complexity on top of that by requiring you to do tasks the compiler or language can do for you instead. Like checking arguments or pointers.

There is a problem with complexity.

First, you are mismatching complexity involved in writing the code (checking arguments or pointers) with overall complexity of the code once it is finished (which matters a lot more !).

Second, as level of features of software raises, complexity also should ?
No. It shouldn't. At least, not by big amounts.
If it does, then there is something wrong in the design.
This is why you'll never see me writing "complex" (or very big) software.
The "me, i do big projects and you don't" looks more and more to me like an ego issue.

[meynaf]

Originally Posted by OlafSch

sigh

There is no language perfect for every task

It all depends what you want to do
Automate something
Develop applications
develop low-level stuff like drivers
which platforms do you target (f.e. desktops or app development)
how much developers are involved?
what software development platforms are available targetting these platforms? How well supported and updated are these? Can they be extended? Which libraries/dll are directly supported and how good?

The class-libraries, extensions and OS support are very important if you look at how efficient you can create something working. But of course you add a lot of overhead with it making the exe bigger and in many cases the software slower. All comes with a price.

Sigh.
Have I said there was a language perfect for all tasks ?
No. All i'm saying is that any task can be performed in asm (which is not true for all these HLLs), and that it's not as difficult as some pretend.

Originally Posted by OlafSch

Even in old days 68k asm was used but mostly for speed reasons in some cases. Mostly it was a mixture of high-level language and asm.

There has been equivalent programs in many languages, and at the end pure asm ones ended up being the ones which performed better...

Originally Posted by OlafSch

You cannot say asm is king, it all depends on what you want to do. Try to do a database based application with asm, it will unbelievable fast but you will propably die before it will be ready. On the other hand a game engine or raytracer in optimized asm would benefit very much from it. But both have the advantage to not depending on other resources.

A database based application in asm, what exactly would make it so difficult ?
It does not look very complicated.

Originally Posted by phx

I doubt that. ProAsm is faster because it was written in 68k assembler for AmigaOS only, and certainly uses a lot of assumptions and short cuts. vasm, on the other hand, is much more complex and can do many things which would probably require a complete rewrite of ProAsm to support them, because it is not that flexible. Most important, vasm is portable to any system which has a working ANSI-C compiler, which also makes the code more general and therefore slower.

But 27 times ?? No, sorry, extra flexibility shouldn't give that much of a slowdown.

Originally Posted by phx

If you like to develop and assemble on your Amiga directly I would never recommend vasm. There are enough alternatives which work fine. Starting with 060 or modern systems I wouldn't miss the features of vasm and assembly time is neglectable.

But why ? If written in asm, something like vasm could be done to work just fine on the Amiga.
Well, vasm is still not doing it right for me as it does not have a regular global config file like phxass, which at least means larger command line to type. It is not only slower - it also uses significantly more memory, which sometimes means it simply can't do the job !
(Not to mention it crashed a few times on me, without a clear way to reproduce the problem.)

Originally Posted by phx

Right. I think nobody would doubt that (maybe except meynaf). The two main reasons for using HLL are: Maintainability. Portability.

Well, it is not that simple. I have maintained and ported enough code to know it is at best less difficult.