Layers.library V45 on the aminet

[Heiroglyph]

@Thomas:
I just want to say thanks for the update.  That video really drives home what an improvement it is. That's nothing short of amazing.

I may not agree with your point of view on other peoples abandoned software, but I can certainly respect your point of view.

I just wish every thread didn't degrade into this mess and hope your thick skin holds up, we need all the help we can get.

@Thread:
Could we possibly get the thread back on track of discussing the actual library, it's performance and bugs?

I'm guilty too (see Cosmos thread) but come on guys, he's devoting his time to helping us all out, show some respect and start a different thread to debate in.

[Heiroglyph]

Byte counting is one thing, but have you seen the size of AROS 68k executables?

There are examples of commands in the c: directory where the OS3.1 version is a few hundred bytes, yet the AROS68k version is multiple thousands of bytes.

That's the type of thing that makes me facepalm when it comes to AROS.

It's not an issue of C vs. assembly either, as I have been working on real native versions based on their C code that are as small and sometimes smaller than the OS3.1 versions.

Sometimes it's added AROS specific calls, sometimes sloppy linking, often just awkward logic, but it's wasteful.

You can't throw away that much memory and disk bandwidth and expect it to run as well as the original OS did on the same hardware.

[Heiroglyph]

Why do you mind so much? The additional size is most likely due to the compiler startup code and some minimal glue code.

We'll have to agree to disagree here.  To me this is a symptom of a larger issue with AROS that is related to the current discussion.

IMHO, it's not a viable replacement for the original OS until it can run in reasonably similar resources and 4KB of wasted disk space, bandwidth and memory on a single command is patently ridiculous.

Working on the commands in c: is a stepping stone for me to get a workflow down while I become acquainted with the code base.

[Heiroglyph]

woulnt it be good to disassemble and examine asm of some possibly simple aros68k c: command to actually exactly check where the differences and problems are in order to optimize them away if possible.

You don't have to, just look at the code and compile it yourself.

Disassembly is rarely needed to find stuff like this, you just need someone to care about it.

Edit: Let me rephrase, lest people think that I don't like the AROS devs.  It's not "care" as in giving a damn, I meant care as in making that one of your priorities.

[Heiroglyph]

im not blaming you in any way, i think you bring some valid points, im just trying to figure out how they could be solved, in absence of better proposals.

I'm not sure what will become of this work, but here's a sample. I'm having trouble getting a table to format right in here, so read if you can, sizes are in bytes.

These aren't cherrypicked, they're just the ones I've done and tested enough to feel confident in them working like the originals.

Code: [Select]


Command OS3.1 Mine AROS (Vision 2.7)
AddBuffers 444 356 2168
Break 432 504 3732
ChangeTaskPri 460 476 3096
DiskChange 312 248 2052
Lock 536 628 2788
MakeDir 464 364 2732
MakeLink 700 556 2528
Relabel 584 580 3312
SetClock 668 636 4840
SetDate 688 724 3212

Total 5,288 5,072 30,460



[Heiroglyph]

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.

[Heiroglyph]

My first reaction was "who cares today for disk capacity" but then I thought a little and must admit that this is indeed important when you want to run it on classic hardware. Aros devs use PCs for development so stripping software down from 3 KB to 500 Byte has not a very high priority but if people want it in that direction it would be good if more people become involved. Of course you can replace most components so if you have reprogrammed something it could be used. But this is certainly a basic problem, many components certainly could be optimized.

Also when your disk access is measured in KB per second it's a lot more important than on a PC where 60MB per second isn't even considered fast.

Most of my time is still spent working out a good automated workflow for building and testing, but the code itself is pretty easy.

I'm hesitant to put this back into AROS though.  I'm using a compiler they don't want plus I don't have (or want) an x86 AROS development system and I refuse to check in code that I can't test.

[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.

[Heiroglyph]

Thomas and anyone else who contributed, I understand that you have NDAs so you can't work on open versions of system components.

Excuse me if I missed this along the way, it's a long thread, but how are you able to distribute binaries like this?

Also, are there more libraries that you have the ability improve and if so, which ones have potential?

I doubt most could give this same level of improvement, but any at all would be welcome in lieu of an official update.

Thanks