Layers.library V45 on the aminet

[Thorham]

If you can afford to waste the time then go ahead

I've said this before: My hobby is NOT a waste of time to me. What's really a waste of time is having been an alcoholic for 14 years doing nothing useful at all. If I had spent all that time writing 68k software in assembly language, then I'd have quite a few nice pieces of software.

Doing what you like doing isn't a waste of time. You don't like assembly language? Great, don't use it, but don't say it's a waste of time just because it's a waste time to you. Some people like peanut butter and some don't. No sense in arguing about that.

[guest11527]

Sure it's possible, it's possible that you'll get it finished before you give up, it's possible there won't be any bugs, it's possible that when you realise there is a better algorithm that requires you to start again that you will actually do it.

The problem goes deeper. The problem is that it's very likely that you do not even realize that you have an architecture problem somewhere in the code if you write everything in assembler. If you take enough time, you'll probably get working code if you work hard. But you're still lost irrelevant details. It's likely that you picked an algorithm because it looked on the microlevel pretty ideal. But whether that's relevant for the big picture is another question, and you'll easily loose the big picture in assembler - you're not forced to organize your code, and you don't have a compiler that helps you at the detail level.

[Thorham]

you're not forced to organize your code

In assembly language, organizing your code properly is even more important than in other languages.

[olsen]

The problem goes deeper. The problem is that it's very likely that you do not even realize that you have an architecture problem somewhere in the code if you write everything in assembler. If you take enough time, you'll probably get working code if you work hard. But you're still lost irrelevant details. It's likely that you picked an algorithm because it looked on the microlevel pretty ideal. But whether that's relevant for the big picture is another question, and you'll easily loose the big picture in assembler - you're not forced to organize your code, and you don't have a compiler that helps you at the detail level.

If somebody is deeply committed to using the language of his choice (say, assembly language, Perl, Visual Basic, Delphi, you name it), and has a clear idea of the limitations of the language, then there is literally no problem he cannot solve using that language, even if that means having to put in extra work to solve it.

You can mention how much more leverage a different language provides, tell war stories to illustrate the time and effort you saved by switching tools, but it won't leave any impression whatsoever. If somebody grew up learning one programming language, and found that it is fit to solve all the problems he ever encountered, never saw the need to look beyond it, you won't be able to talk him out of it.

Which is fine, until you have to collaborate with such a savant and find common ground to work with him. I trust you've been in this kind of situation, and so have I.

[guest11527]

In assembly language, organizing your code properly is even more important than in other languages.

You are not *forced to* by the language to do that. C and even more so C++ or Java requires(!) you to use language constructs to organize your code that are quite expressive and rich, and allows the compiler to check for the correctness of these constructs. In Assembler, you have nothing. Pretty much every Java code looks the same - same style. In C++, you have more freedoms and several programming styles are possible, but one way or another, the language offers you constructs how to address specific problems, and the compiler is there to check for the correctness of such constructs.

Anyhow, we're arguing in circles. Given that you never worked on a major project in assembler, I see that you can hardly judge why all that is beneficial for a project, and why it helps so much. Don't you think that it's rather ignorant to make such arguments without ever having gone through all this at least once?

Try it, then we do the talking. Probably in five years if you start now.

[OlafS3]

You are not *forced to* by the language to do that. C and even more so C++ or Java requires(!) you to use language constructs to organize your code that are quite expressive and rich, and allows the compiler to check for the correctness of these constructs. In Assembler, you have nothing. Pretty much every Java code looks the same - same style. In C++, you have more freedoms and several programming styles are possible, but one way or another, the language offers you constructs how to address specific problems, and the compiler is there to check for the correctness of such constructs.

Anyhow, we're arguing in circles. Given that you never worked on a major project in assembler, I see that you can hardly judge why all that is beneficial for a project, and why it helps so much. Don't you think that it's rather ignorant to make such arguments without ever having gone through all this at least once?

Try it, then we do the talking. Probably in five years if you start now.

I think you and Thorham (and Cosmos) are looking at it from a completely different perspective. You look at it as a professional developer, they look at it as hobbyists doing it just for fun and are happy if they squeeze out some bytes or make it a little faster on their own system and environment. This discussion about sense or nonsense of using assembler or if it makes sense that everyone does his own patches can last for another 1000 postings and will not come to a end. It is the same as discussing if it makes sense to use a exotic OS instead of mainstream. As long as they offer only patches (and do not spread the changed original) nobody can do anything about it. There are countless patches on aminet and everybody knows that using it is risky so people are responsible themselves if they use it or not.

Better would be AmigaOS 68k would still be in development but we cannot bake reality..

[wawrzon]

I think Thomas is right on the money about startup and C library code.

My guess is that there's about 2k of startup/clib code duplicated on each command, but it may also be gcc contributing.

Most of my changes involved using native methods that would be in ROM, doing my own startup (2-3 lines of C code, wouldn't work in x86 AROS) and using C that I knew would compile to better assembly.

IMHO it's more readable now and I fixed several bugs along the way. AROS AddBuffers for example won't work correctly on a real ROM, but this works on both back to v37 KS.

I had more of it done with SAS/C but switched to vbcc this weekend for c99 support and a better compiler.

its not like they dont want to support vbcc, there has been even some work put towards it, though first of all there is not enough human resources, so they must concentrate on compilers that are offering most up to date features, best multi-platform backend support, best posix compatibility, and active maintenance, backed up by huge team. i think in this respect relying on 4.x.x gcc is a right and reasonable trade off.

i would definitely love if you could help to improve aros68k, but its up to you of course and aros maintainers. if need be you could talk directly to toni wilen or via eab. i think even discussing things with him could be valuable given experience you have gathered. im aware though, that toni being winuae man, is less interested in performance optimizations for real hardware as long as he considers them premature, that means as long as implementation is incomplete and not very well tested.

[wawrzon]

There's an unreleased version of this library for OS3.x (the OS4 version is based on it). It's about 1/8th the size of the Warp3D 4.2 release version, fully supports every v4 array/element/index size primitive and is up to 2x faster at rendering triangle/strip/fan lists.

Those gains were from refactoring the C and then rewriting some vertex fetch routines in assembler. The latter did not give much gain since in the end the bus is the bottleneck.

and here we go again. things that could improve the experience on 68k are held back to remain os4 exclusive. of course you and the genuine source owners have every right to do what they please, but imagine what might have happened if you published your work as open source backend to wazp3d. perhaps it could even have become a template for volunteers king for opportunity to write other w3d drivers, and literally everyone could gain from it including os4 community.

[Thorham]

You are not *forced to* by the language to do that. C and even more so C++ or Java requires(!) you to use language constructs to organize your code that are quite expressive and rich, and allows the compiler to check for the correctness of these constructs.

Oh, come on, you can make a mess out of things in every language, and yes, assembly language makes that easier.

In Assembler, you have nothing.

Except the most important tool: Your brain. Nothing keeps you from structuring your assembly language code properly. If someone doesn't do that, then that's their mistake.

Anyhow, we're arguing in circles. Given that you never worked on a major project in assembler, I see that you can hardly judge why all that is beneficial for a project

I can see perfectly fine how higher level programming languages are beneficial to a larger project (use them myself on the peecee, where I don't use assembly language). I simply don't agree with you that you can't do it properly in assembly language.

and why it helps so much. Don't you think that it's rather ignorant to make such arguments without ever having gone through all this at least once?

No, it's not ignorant. What's ignorant is assuming that your personal experience with this applies to everyone. You say it's too hard, because you've had problems with it, and that's not right.

Also, I'd like to see what's so hard about a shell replacement in assembly language. Would be great if I could take a look at that (because you claim it was hard to do).

[guest11527]

I simply don't agree with you that you can't do it properly in assembly language.

Once again, and even simpler: "Then shut up and do it, then see what happens." Got it?

[Thorham]

To Thomas Richter:

All you're saying is that because you can't do it, no one can. Because you find it too hard, it's too hard for everyone. That's some major arrogance right there.

[wawrzon]

sighhhh......

[vxm]

Fortunately, the first C compiler was written in assembler.
(with that, it seems clear to me that I will not have new friends.)

[guest11527]

To Thomas Richter:

All you're saying is that because you can't do it, no one can. Because you find it too hard, it's too hard for everyone. That's some major arrogance right there.

Once again: "Shut up, try it yourself, we'll then talk". Which part of that did you not understand?

[guest11527]

Fortunately, the first C compiler was written in assembler.

 Where did you get that idea from? http://cm.bell-labs.com/who/dmr/chist.html

[Heiroglyph]

its not like they dont want to support vbcc, there has been even some work put towards it, though first of all there is not enough human resources, so they must concentrate on compilers that are offering most up to date features, best multi-platform backend support, best posix compatibility, and active maintenance, backed up by huge team. i think in this respect relying on 4.x.x gcc is a right and reasonable trade off.

Apparently they have technical issues with vbcc and a very gcc specific codebase.

http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler#VBCC

I still think this is the right path for native 68k though, which is the one platform I want and that I think is underdeveloped.

i would definitely love if you could help to improve aros68k, but its up to you of course and aros maintainers. if need be you could talk directly to toni wilen or via eab. i think even discussing things with him could be valuable given experience you have gathered. im aware though, that toni being winuae man, is less interested in performance optimizations for real hardware as long as he considers them premature, that means as long as implementation is incomplete and not very well tested.

I haven't discussed it with them because I'm still not sure I'm on the right track. I may realize exactly why they haven't done it themselves and I don't see a point in distracting them or making it look like a fork. It's just my little playground ATM.

The discussions lately (especially from you and OlafS3) convinced me to do something  instead of just complaining about how they handled it, lol.