Layers.library V45 on the aminet

[LiveForIt]

I agree with takemehomegrandma in this case regarding the "first implementation", quote from this forum thread.

It smells lot of morphos fan boy views.

"Hyperions OS4" its not called that and its direct descendent of AmigaOS4. "most immature", well thats depletable MorphOS does not support the latest Graphics cards, AmigaOS4.1 do, and also AmigaOS4.x has memory protection that does work to find bugs and debug applications and it work. MorphOS allows more misbehaving programs to run. Is that a feature or is it a failure well if you ask me its a failure.

Personalty I see no point in improving AmigaOS3.x, every thing worth improving is already fixed is  already improved in AmigaOS4.1, more important its not random hacks, there is offical set of libraries, if you code to support this libraries your programs will run in future as well, they wont stop because some hobbyist decides they wont to do some thing different.

If there was some thing that should be fixed in AmigaOS3.x I think bring it up level that enable some large file system and hard drives to work, with out having to worry about corrupting your data, be the one thing that I think is a "Must" fix issue, every thing else is not mandatory.

Anyway this debate is pretty mutch irrelevant.

I agree with some comments about AmigaOS4.1 being close source is hinderance in some ways, there are things I like to add or improve, I don't care if did not get dime for it, because if did add this features it be useful to me latter on, when I write my programs or games.

But anyway in most/every case I do not need to modify the OS, to add new features, there are otherways, I can for example create my own set of libraries that complements the originals features, this way don't need to change the OS in any unexpected way, so no programs are going to stop working. This is what MUI is, they did not try to hack Gadtools, they created there own GUI system in system fremdly way, and now MUI has become a offical parts of MorphOS and AmigaOS4.1, well in the case of AmigaOS4.1 you need a key to unlock some its less importent features..

Picasso96 is also extension to graphic.library.

[LiveForIt]

No, I'm talking about AOS, not the hardware. The hardware is great, just the OS isn't.  

so way don't you install Linux 68k, or NetBSD 68K, or are this also bad or are this also not great?

In any case what ever you do your going to have to deal with limited hardware specifications, so there is trade off between having some thing that can do every thing and some thing that has to be light weight.

Anyway I'm curious what do you think is the most important part of OS that AmigaOS do not have? I ask this question because I know you like to take over the hardware.

[psxphill]

so way don't you install Linux 68k, or NetBSD 68K, or are this also bad or are this also not great?

In any case what ever you do your going to have to deal with limited hardware specifications, so there is trade off between having some thing that can do every thing and some thing that has to be light weight.

It's possible to do something light weight that can do everything, you just have to design it properly to start with.
 
 AmigaOS and Linux/NetBSD sit at opposite ends of the table, there is middle ground.

[LiveForIt]

It's possible to do something light weight that can do everything, you just have to design it properly to start with.  

In software, the more stuff you add the more the CPU has to do, there is limit what it can do. Well yes a good program will take less CPU cycles becouse it do the lest amount of work to active its goals, but still has to do the work.

AmigaOS and Linux/NetBSD sit at opposite ends of the table, there is middle ground.

in any case its lot of work, and if you wont to have application need to be ported from another OS, and so you need to port the support libs, and so on.

Anyhow its lot of work, most people don't have the time.

[NorthWay]

As far as Birdie is concerned: I don't have a contact to its author. Do you? Does anyone in the community have?  

I am pretty confident you will find him at https://www.linkedin.com/in/trondwernerhansen

[NorthWay]

For the record:

If anyone is interested in setting up a bounty for AOS sources then I'm willing to put down $1000. Personal, hobby, non-commercial money.
Make it for 3.1 only if that makes it any easier.

(The bounty should have some legal-speak that indemnify the buyer(s) if the rights are disputed at a later date.)

[bloodline]

For the record:

If anyone is interested in setting up a bounty for AOS sources then I'm willing to put down $1000. Personal, hobby, non-commercial money.
Make it for 3.1 only if that makes it any easier.

(The bounty should have some legal-speak that indemnify the buyer(s) if the rights are disputed at a later date.)

It's your money, but if I were you I would put that $1000 towards an AROS bounty to develop the 68k port to a better standard. It's more likely to happen (AmigaOS is never going to be open sourced) and has better long term benefits.

[psxphill]

In software, the more stuff you add the more the CPU has to do, there is limit what it can do. Well yes a good program will take less CPU cycles bedouse it do the lest amount of work to active its goals, but still has to do the work.

The trick is to do more with less. It's definitely possible to do better in comparison to Linux and NetBSD.
 
 With layers.library and the recent AllocMem patches it's shown it's possible to do better than 90's AmigaOS.

[Thorham]

so way don't you install Linux 68k, or NetBSD 68K

Because I don't want to. Also, what am I going to run under these  operating systems on a 68030? If I want to run Linux, then I'll just  install a current distro on my peecee.

In any case what ever you do your going to have  to deal with limited hardware specifications, so there is trade off  between having some thing that can do every thing and some thing that  has to be light weight.

Of course, but it's certainly possible to do better than AOS on a  68020/30, both in terms of speed, functionality and eye candy. In other  words, as good as possible without needing 60s and GFX cards, and what  not.

Anyway I'm curious what do you think is the most important part of OS that AmigaOS do not have?

Memory protection is the main one, but everything can also be done better, that's the idea.

I ask this question because I know you like to take over the hardware.

No, I don't. The thing I like to do is use the CPU to blit to the screen  memory directly, because it can be so much faster than using those  generic OS blitting routines. And audio, obviously, but what choice is  there?

and if you wont to have application need to be ported from another OS

And that's the second part of what I want. New programs written from scratch just for this new OS, with absolutely NOTHING ported from existing software. Would be too slow anyway. Imagine porting FireFox to 68k :lol:

Yeah, a 68k Amiga software utopia. Sadly, it probably won't ever happen.

[wawrzon]

For the record:

If anyone is interested in setting up a bounty for AOS sources then I'm willing to put down $1000. Personal, hobby, non-commercial money.
Make it for 3.1 only if that makes it any easier.

(The bounty should have some legal-speak that indemnify the buyer(s) if the rights are disputed at a later date.)

how are you going to make sure you are buying from the actual owner and that there will not be any claims from third parties in the future?

[Cosmos]

You still don't get it, right? I'm trying to find out what the situation is, understood? How much more explicit do I need to get?   Have you made any measurements showing the efficiency of these "improvements", and have you considered that this leaves the libraries in a pretty unmaintainable state?  

Again, what is "working" for you? For me it means that I can also fix something in two years in the future. With the kind of "improvements" I see from Cosmos this is unlikely to be even possible. First of all, it doesn't really improve anything, and second, even if the results were measurable, the improvements were lost or incompatible to any other changes that had to be made.

Have you watching my changes into my code ? Certainly no...

For example, the function R_AndRegionRegion in the graphics.library use two AllocMem (and of course two FreeMem at the end) for two tiny buffers (only $C) : I replaced by six clr.l -(sp) for these buffers on the stack now...

This function is now more than 1000 times faster, so the improvement is real...


You are a professionnal troller, you talk in the void, you have lost all credibility...

[guest11527]

For example, the function R_AndRegionRegion in the graphics.library use two AllocMem (and of course two FreeMem at the end) for two tiny buffers (only $C) : I replaced by six clr.l -(sp) for these buffers on the stack now...

What exactly is it that you do not understand with the word "measurement"? It means, making an experiment, showing the efficiency of the changes. It does not mean "guesswork". BTW, do you have an idea *why* there is an AllocMem()? (Actually, there isn't. There is a NewRegion() call). Thus, can you ensure that the buffers that are released there are in fact idental to the buffers allocated? Or did you "just made an experiment and it happened to work for you"?

THe software interfaces used there are there for a reason - the regions have luckely (unlike many other crap in gfx) a clear constructor method (NewRegion()), and it's typically a good idea to use that. Unless there is a very clear reason that this is not a good idea, and the only clear inidicator would be that there is a specific bottleneck in AndRegionRegion() in a specific situation. Thus, I ask you again: Which is the bottleneck, and which is the situation within which this bottleneck appears, and what is the speed improvement you get in this specific situation.

Just for the records, here is my specific bottleneck I addressed in layers V45, just for completeness: Open a lot of overlapping windows on a graphics-card driven screen, then re-arrange the windows (depth-arrangement), then measure. You'll get a noticable speedup.

Now, what's your story that requires this change, and how did you ensure that the change is correct?

Software engineering. You know it...

[LiveForIt]

for these buffers on the stack now...

So by increasing the stack footprint, you have cut down on memory allocations.

Theoretically any program that use this function can run out of stack, because many programs have small $STACK cookie, and default stack for shell commands and wb icons on Amiga is low to begin with.

[modrobert]

What exactly is it that you do not understand with the word "measurement"? It means, making an experiment, showing the efficiency of the changes. It does not mean "guesswork". BTW, do you have an idea *why* there is an AllocMem()? (Actually, there isn't. There is a NewRegion() call). Thus, can you ensure that the buffers that are released there are in fact idental to the buffers allocated? Or did you "just made an experiment and it happened to work for you"?

THe software interfaces used there are there for a reason - the regions have luckely (unlike many other crap in gfx) a clear constructor method (NewRegion()), and it's typically a good idea to use that. Unless there is a very clear reason that this is not a good idea, and the only clear inidicator would be that there is a specific bottleneck in AndRegionRegion() in a specific situation. Thus, I ask you again: Which is the bottleneck, and which is the situation within which this bottleneck appears, and what is the speed improvement you get in this specific situation.

Just for the records, here is my specific bottleneck I addressed in layers V45, just for completeness: Open a lot of overlapping windows on a graphics-card driven screen, then re-arrange the windows (depth-arrangement), then measure. You'll get a noticable speedup.

Now, what's your story that requires this change, and how did you ensure that the change is correct?

Software engineering. You know it...

Isn't the original graphics.library written in C?

You can't expect a C compiler to match the optimizations made manually by an assembler programmer. I've heard so many stories about how well C compilers optimize these days and how assembler is made redundant, and then when you actually disassemble the code the compiler produced, it's bloated, filled with jump tables, and inefficient code.

[itix]

So by increasing the stack footprint, you have cut down on memory allocations.

Theoretically any program that use this function can run out of stack, because many programs have small $STACK cookie, and default stack for shell commands and wb icons on Amiga is low to begin with.

They dont. There are many more OS calls consuming lot more stack and developers are adviced to not cut their stack size too small. The default stack size 4096 bytes is more than enough to most applications and stack command in the shell or WB icon setting dont have any effect to subtasks/processes anyway.

@modrobert

I've heard so many stories about how well C compilers optimize these days and how assembler is made redundant, and then when you actually disassemble the code the compiler produced, it's bloated, filled with jump tables, and inefficient code.

When you have 68020 or better it becomes irrelevant. On 68000 it can be noticeable, event without a stopwatch, but when it comes to Region functions in graphics library it becomes irrelevant again. If performance is problem you dont probably want to hand optimize Region calls but find better algorithm with O(n) or O(1) processing time.

[olsen]

Isn't the original graphics.library written in C?

All versions (1.x through 3.x) are written in a mix of 'C' and 68k assembly language, strongly leaning towards 68k assembly code. Looking at the API, you'll find that a large part of the operations are about filling in data structures, hooking them up and then eventually telling the hardware what to do with them. Typically, the "clerical operations" are written in 'C', and the part which talks to the hardware is written in assembly language.

graphics.library, like intuition.library, is one of the more complex operating system components, both in how it uses data structures and how many distinct operations it can carry out. Hence, you'll find that 'C' plays a major part in its implementation.

That said, when you need to talk to the hardware in a very specific manner, you couldn't do that quite so elegantly back in 1986 if you didn't use 68k assembly language. There is complex assembly language code in graphics.library, it even uses its own preprocessor (!) in order to simplify writing loops (while .. do) and control structures (if .. then .. else).

You can't expect a C compiler to match the optimizations made manually by an assembler programmer. I've heard so many stories about how well C compilers optimize these days and how assembler is made redundant, and then when you actually disassemble the code the compiler produced, it's bloated, filled with jump tables, and inefficient code.

If you have specific requirements for carrying out operations, you may get better control through the use of assembly language than any modern 'C' compiler could provide you with. C11 has just gained new control keywords in order to make interfacing to hardware more straightforward, but it will take a while for the language to evolve to give you the kind of control only assembly language can give you.

As for assembly language becoming largely redundant, it's probably unavoidable. 'C' in particular is a more expressive language which encodes in fewer lines what assembly language, by its very nature, requires much more effort to express. The thing is, if you can say the same thing with fewer words, the chances of mucking it up are somewhat reduced. If you have the right language, you can even verify the correctness of the instructions and data structures you used, which is something that eludes assembly language by its very design.

As for inefficient code, performance nowadays does not necessarily come out of implementing an algorithm through the optimum low level language encoding you could choose (that being assembly language). You can't necessarily predict how your code will be executed, and if you can, you might have to run the gauntlet of observing a handful of operating conditions under which it executes, such as regarding optimum pipeline use, prefetch, etc. This can get so ugly that it has to be automated (look up how one programmed the Motorola 56000 DSP in its day, just to get an idea how weird this can get) just to let the programmer worry about implementing his design correctly.

This is how progress looks like: the gains made through building faster processors are used in such a way that writing more complex software, more secure software and more reliable software becomes an easier goal to achieve through the use of tools and code generation which does not necessarily attempt to squeeze the last cycle out of the machine. This is, in the end a trade-off, if not a sacrifice.