Layers.library V45 on the aminet

[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

[Rotzloeffel]

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

Because Thomas asked the owner of the rights (IMHO Hyperion) and they allowed Thomas to improve layers.library

That´s the way it should allways work:-) But we know better....

[wawrzon]

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

yes i remember it was technical issues of course. im not sure if this article is fully up to date, it must have been written by jason.

one issue not privilidgeing vbcc is of course that it is a native 68k compiler (afaik) and aros heavily depends on automatized cross compiling on servers to have actual nightlies ready at hand for testing by everybody. though since people are adding their preffered platforms to compile on i imagine vbcc could also be accepted if it was doable. what concerns missing features like different asm inline syntax (if i understand it right), we have here matthey who is helping with vbcc and vasm for input on that matter.

[OlafS3]

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

That is great :-)

I have reached the end of line regarding Aros 68k now. When you look at functionality I think the difference is not far but it still misses needed optimizations to reduce size and adapt it to the classic hardware. AmigaOS is still unbeatable there (its biggest strength and weakness at the same time). If some skilled developers would help there and help to remove incompatiblility issues everyone would benefit. And for the Aros developers compatibility to 3.1. is the main goal. Thomas has said he will answer questions so perhaps if we all work together something good can come out.

@Wawa

On aros-exec there is someone wanting to help testing on real hardware:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8851&forum=4&post_id=90173#forumpost90173

perhaps you can get in contact. We need more people being active then the progress will be much faster.

[guest11527]

Because Thomas asked the owner of the rights (IMHO Hyperion) and they allowed Thomas to improve layers.library.

Almost. Layers V45 was collecting dust on my hard disk for over 12 years. The project was done as a contribution to Os 4.0 a long time ago, and the code actually made it into Os 4. I just found that it would be too bad not to offer it to the classic system, even more so as some of the folks I know (Gunnar, for example) were planning new graphics cards, and the code we have here is a welcome extension. Actually, the story of all this is even older, years ago when I helped Tobias and Alex a little bit with P96, they already asked me whether it would make sense to clean up layers. Back then, I haven't had the time to do it, this then finally happened after 3.9. Probably a bit too late for the V2 of P96, but still in time to have it today.

One way or another, yes, I got permission, thus I'm not so pessimistic that there is probably some chance for further improvements to be made.

[wawrzon]

That is great :-)


@Wawa

On aros-exec there is someone wanting to help testing on real hardware:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8851&forum=4&post_id=90173#forumpost90173

perhaps you can get in contact. We need more people being active then the progress will be much faster.

who? magorium? i doubt he needs my help, anyway he didnt asked for any so..

[OlafS3]

who? magorium? i doubt he needs my help, anyway he didnt asked for any so..

no

ntromans

[Thorham]

Once again: "Shut up, try it yourself, we'll then talk".

Yeah, I think I will shut up

[vxm]

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

As far as I can remember, probably during training in microelectronics in the 80s:
"in 1972 the first version of C is written in assembler by Brian W. Kernighan and Dennis M. Ritchie."

[kolla]

gnu 68k compilers are shockingly bad, it's one of the things that needs the most development.

GCC (and glibc) for m68k has gotten quite a bit of attention the last few years and is far from "shockingly bad". Upgrade already.

[kolla]

Thoram: code an IPv6 capable TCP stack for AmigaOS in asm, it is very much needed, is perfectly doable and worth while on 68k, and complex enough to drive you insane.

[matthey]

one issue not privilidgeing vbcc is of course that it is a native 68k compiler (afaik) and aros heavily depends on automatized cross compiling on servers to have actual nightlies ready at hand for testing by everybody. though since people are adding their preffered platforms to compile on i imagine vbcc could also be accepted if it was doable. what concerns missing features like different asm inline syntax (if i understand it right), we have here matthey who is helping with vbcc and vasm for input on that matter.

Vbcc can cross compile from x86 or PPC which is generally all that is needed for fast cross compiling to 68k. AROS is using GCC specific functionality which is a problem. Vbcc has good C99 compatibility now (new unreleased version) and Frank Wille's vlink supports the AROS 68k ELF format. Frank Wille and the AROS developers need to hammer out the necessary changes to get it to work. There isn't a lot of motivation with GCC 68k code generation quality improving lately though.

[olsen]

Thoram: code an IPv6 capable TCP stack for AmigaOS in asm, it is very much needed, is perfectly doable and worth while on 68k, and complex enough to drive you insane.

Don't tempt me

But seriously, implementing an IPv6 TCP/IP stack in plain 68k assembly language should be doable. You'd have to start off small with the 1983 TCP/IP implementation, as documented and used in 4.2BSD, upgrade it to the 1988 implementation (with congestion control support) and then you're basically in business: this can be upgraded for IPv6 support.

The hard part is in fitting this into the bsdsocket.library framework which already exists, so that it can be used for existing client software on AmigaOS (and not just exist as a proof that anything is possible in 68k assembly language, even if you have to forgo shaving, bathing and seeing your family for an extended period of time). There is a blueprint in AmiTCP, but it will only get you so far. The only IPv6 API support which I am aware of exists in Miami Deluxe, and it has never been replicated; the number of IPv6 clients on the Amiga always was very small, too, which would make testing difficult.

Anyway, before somebody even thinks about it: don't write IPsec code in plain 68k assembly language, because this is going to end in tears. As soon as you're having to do serious heavy lifting in cryptography you're best advised not to write the code in a language which is difficult to audit and review for errors.

[Karlos]

and here we go again. things that could improve the experience on 68k are held back to remain os4 exclusive.

Not exactly. This work pre dated OS4. I never released it at the time because in fixing a few bugs (and doubtless introducing new ones) I broke compatibility with a few applications. Most notably some of the better demos. I wrote entire suites of tests and can honestly say the driver honoured the API but there exists a corpus of software that relied on some obscure undocumented and likely accidental side effects of the original code. And while the improved performance in synthetic tests was nice, the gains were marginal in most games because the bottlenecks where elsewhere (esp. on ppc).

And that's the moral of this story. Optimising the %&$#?@!%&$#?@!%&$#?@!%&$#?@! out of a single small area often leaves you with little to show for it other than more bugs than you started with. None of the fixes to the v4 drawing calls mattered for existing software except to my projects, and they were still broken / unimplemented in the other drivers, so my software was left running on P2 when voodoo was fast becoming the norm. MiniGL went from v3 api calls to v5 (OS4 only) rendering those fixes irrelevant for most applications.

I had marginally faster minigl 1.5 / heretic 2 / glquake and a lot of wrecked elude demos.

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.

I'd be happy to release it, but it isn't up to me. Warp3D belongs to Hyperion and is now part of OS4. It's also deprecated so they may be ok with it. Either way, I'd have to ask.

[psxphill]

GCC (and glibc) for m68k has gotten quite a bit of attention the last few years and is far from "shockingly bad". Upgrade already.

Can you back that up, I can't find any proof of that online.

As far as I can remember, probably during training in microelectronics in the 80s:
"in 1972 the first version of C is written in assembler by Brian W. Kernighan and Dennis M. Ritchie."

The C compiler was based on the B compiler, which had already been re-written in B by this point. B was originally written in TMG, but TMG was written in assembler by Doug McIlroy.

Never believe anything they teach you in school.

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html