[meynaf]

Originally Posted by Thomas Richter

No, why. Software development is not OT. You may not care about how to do it, though, but that doesn't make it irrelevant. Nobody is wasting time with assembler today. Rarely ever.

May i recall you on which site you are ?

Originally Posted by Thomas Richter

Actually, you don't know what I know - I know the instructions, I know what they do. I just don't write code in assembly, it doesn't make sense.

Knowing the instructions is not enough to be able to properly read code.

Originally Posted by Thomas Richter

Not good luck - the problem is that you don't know your way on modern machines. You could also benchmark my JPEG XS, good luck with that with your assembler on 68K.

"modern machines" are completely OT here.
As i suppose there is no 68k version of your JPEG XS, you're comparing apples and oranges.

Originally Posted by Thomas Richter

But that's a quite limited view, actually. You're telling me "assembler is fine", yet you care only about an outdated architecture rarely anyone else cares about.

This whole site is about said outdated architecture...

Originally Posted by Thomas Richter

How large a project goes is not on you. It is on the requirements of the product owner what the project should do.

If you're the project manager, it is.

Originally Posted by Thomas Richter

Is AmigaOs large, for example? Probably not by today's standards, but it is large enough for not wasting everybodies time with assembler.

AmigaOs is large but it consists of many independent modules, some of which are in asm. Taken individually, these modules aren't however very big. I could perfectly have rewritten them in asm if i wanted to.

Originally Posted by Thomas Richter

Yet, you are writing this very post on bloatware, using bloatware, depending on bloatware. This is probably some html engine, with some javascript client side, plus PHP serverside underneath (I don't know), so there is a lot of code already. And, guess what, my bet is that nothing of that was written in assembler, probably with the exception of some of the very low level parts of the Os you're using, and the server is using providing the page.

Sure, but it does not work very well overall if you look at details and compare with what the machine is supposed to be able to do on paper.
Yeah, that very same "sane" software that adds bogus newlines in your posts here (and you don't appear to care about).

Originally Posted by Thomas Richter

If that's all such a waste, why are you wasting your time with the waste?

Because there is nothing else available on the market.

Originally Posted by Thomas Richter

TADA! And for modularity, you need tools to organize the code, and that's why we have compilers and linkers. Modularity is the key, organization is the key. Not code size. Size is irrelevant, structure is relevant.

Tools won't organize the code at your place.

Originally Posted by Thomas Richter

Tells me the guy who refuses to use includes and labels. Yeah, right...

Correction : the guy who refuses to misuse includes and labels. There are labels and include directives in my code - just not the ones that i regard as inadequate.

Originally Posted by Thomas Richter

Nope:

move.l d0,d2

Is d0 signed or unsigned? It could be an implicit type conversion, or a pointer to int conversion, or whatever. There is nothing to see here, and nothing to warn.

If this is a joke it's a very poor one. It's quite obvious that this instruction can not cause a bug - it will work just fine regardless of signedness.
And no, it's not a type conversion. It's a longword and remains a longword.

Originally Posted by Thomas Richter

That's an implicit type conversion, and yes, C is prone to them. Other languages not. It will fortunately tell you many, though not all cases. Signed to unsigned comparisons compilers will be typically able to identify and warn you about.

A compiler will warn you if you mismatch signed and unsigned, but it can't do this with a constant (unless you explicitly ask for it).
In asm, otoh, you write different instruction.
You write blo for unsigned, blt for signed. Mere "<" is misleading.

Originally Posted by Thomas Richter

In assembler: Nobody warns you whatsoever for the above code if d0 can be negative, but d2 is a count can must be non-negative. Nothing happens. Either you know, or you shoot yourself in the foot. In which way this is any better I do not know.

A compiler won't warn you either if a values goes out of range during execution.
Worse, C codes declares signed overflow as undefined !

Originally Posted by Thomas Richter

But you should. Or arm, or whatever. This is where development happens.

Why would i care ? Compilers are here to hide these details. If i wanted to see x86 code, i would write x86 code.

Originally Posted by Thomas Richter

Not here in 68K land, that's just toy code.

Yeah, toy code. This has become your motto here.
But toy code is at least nice and enjoyable.

Originally Posted by Thomas Richter

Cache friendly means small data, yes, but good data organization. If you want to get such things fast, you're not writing assembly today. It's all about vector instructions, compiler intrinsics. The code the compiler generates from that is usually better than what you write by hand. Of course, you need to tell the compiler in the right way, and use the right data types for it. I''m not suggesting using "unsigned char" just because its small. But the appropriate vector of N unsigned characters which you can pipe through in parallel SIMD way.

Again, i'm not writing x86 asm (or arm asm), only good old 68k - so no vector instructions.

Originally Posted by Thomas Richter

That's why I'm reading the code the compiler generates for me, and then potentially tune it. I'm not writing this stuff by hand anymore. Compilers today can do auto-vectorization, loop unrolling, flow analysis and other neat tricks, and there have been cases where hand-optimizing the code went nowhere because the compiler just knew better what's fast and what isn't.

Then you are missing the point about what a compiler is for. It is an abstraction around the cpu, allowing to write portable code.