Official update to OS 3.1 from Hyperion

[indigolemon]

Originally Posted by matthey

It is intuition.library which is compiled with the old Green Hill's compiler. The code was just never adapted to a newer compiler. I doubt it has anything to do with compactness of code as I expect intuition.library would be much smaller (and faster) without the stubs used to convert function register arguments to stack based arguments as the compiler did not support register arguments (the standard 68k AT&T ABI specifies stack arguments only).



It shouldn't be too difficult but it is likely a monotonous and error prone job so it would require some testing afterward.

Oddly, I was reading an old thread the other day, it seems both Peter Cherna and Olaf Barthel managed to convert intuition.library to ANSI C standards in two separate efforts!

http://eab.abime.net/showpost.php?p=...1&postcount=63

[matthey]

Originally Posted by indigolemon

Oddly, I was reading an old thread the other day, it seems both Peter Cherna and Olaf Barthel managed to convert intuition.library to ANSI C standards in two separate efforts!

http://eab.abime.net/showpost.php?p=...1&postcount=63

I do vaguely recall Olaf talking about this but I doubt the new intuition.library was ever released. The intuition.library in the 3.1 ROM still uses the inefficient reg->stack arg stubs and has some quite ugly code besides. The performance gain would likely be small as intuition.library does little CPU intensive work itself but shrinking it would save some valuable kickstart space.

[gulliver]

Yes, I can confirm Peter Cherna worked on porting intuition.library. His work needs to be checked, but it certainly compiles with SASC.

[Olaf Barthel]

Originally Posted by matthey

It is intuition.library which is compiled with the old Green Hill's compiler. The code was just never adapted to a newer compiler. I doubt it has anything to do with compactness of code as I expect intuition.library would be much smaller (and faster) without the stubs used to convert function register arguments to stack based arguments as the compiler did not support register arguments (the standard 68k AT&T ABI specifies stack arguments only).

At the time (1984-1986) the Green Hills 'C' compiler was apparently generating the most robust optimized code, and there was hardly any competition for it.

As far as I know the Manx and Lattice 'C' compilers, which became available in 1986, did not manage to reach the same degree of code quality until, finally, Lattice introduced the global optimizer. This is what had been at heart of what made the Green Hills 'C' compiler work so well. Before this technology found its way into the Lattice compiler (and SAS/C, then) your typical 'C' compiler was more likely to perform peephole optimizations only.

The practice of passing function parameters only over the stack can be criticized. In terms of "low hanging fruit" optimizations, this is where significant performance and size improvements can be gained. But this just was not possible back in 1986. What was possible was the high quality code and in particular the highly optimized code which the Green Hills 'C' compiler would produce.

Incidentally, a couple of weeks ago I watched Ed Logg's post-mortem on the game "The Gauntlet", which was created for a hardware platform rather similar to the Amiga in 1985. The hardware for "The Gauntlet" would use an MC68010 CPU, and the software was developed in 'C', using (guess what!) the Green Hills 'C' compiler. See [ Show youtube player ] for the presentation, which is titled "Gauntlet revisited by creator Ed Logg".

Ed Logg described the constraints imposed by the hardware on the game, and in particular how to achieve the desired frame rate with collision detection and the number of screen updates possible at that frame rate. One problem was in fact caused by the Green Hills 'C' compiler, which generated (I'm paraphrasing) too much code for the MC68010 to execute and keep the screen update rate within acceptable limits. In the post-mortem Ed Logg specifically mentioned that he had to write a post-processing program for the Green Hills generated code to work around this limitation.

So, that's how these things work out: on the one hand you can have great and robust code optimization which saves you the hassle of hand-optimizing it at the assembly language level, on the other hand you may have to balance the advantages of the more complex compiler doing the job for you with the side-effects (more code, ROM space constraints).

I'd say "intution.library" got off comparatively lightly in terms of performance constraints, its workings being driven mainly by user input (there's one big state machine at the heart of intuition). Where there are external constraints not directly related to user input (such as in "The Gauntlet"), making the code work well can be much more of a struggle.

[matthey]

Originally Posted by Olaf Barthel

At the time (1984-1986) the Green Hills 'C' compiler was apparently generating the most robust optimized code, and there was hardly any competition for it.

As far as I know the Manx and Lattice 'C' compilers, which became available in 1986, did not manage to reach the same degree of code quality until, finally, Lattice introduced the global optimizer. This is what had been at heart of what made the Green Hills 'C' compiler work so well. Before this technology found its way into the Lattice compiler (and SAS/C, then) your typical 'C' compiler was more likely to perform peephole optimizations only.

FORTRAN and BLISS languages had optimizing compilers much earlier. C compilers did not do much optimizing early on because C is a low level language and further optimization was thought unnecessary and slowed compile times. Programmers were supposed to be able to write efficient low level code for the CPU/hardware (Dennis Ritchie created C to better take advantage of the PDP-11 features, the CPU which heavily influenced the 68k). At the same time, C portability became more important than any previous language and the code could be optimized for different hardware. With portability came the need for more abstraction from the hardware and more of a need for optimization to give back performance which was lost in the process. This is the 2 headed monster of C with abstraction currently winning and low level coding suffering. I had a recent related e-mail conversation with Frank Wille (with comments from Dr Volker Barthelman). I was complaining about the vbcc 68k code generation for a simple and common C code which Dennis Ritchie himself had used in a book.

/* 
 * Source: Kernighan & Ritchie, The C Programming 
 * Language, 2nd Edition, Prentice Hall PTR, 1988, 
 * p. 105 
 * 
 * strcpy: copy t to s; pointer version 2 
 */ 

void strcpy(char *s, char *t) 
{ 
  while ((*s++ = *t++) != '\0') 
    ; 
}

The vbcc generated 68k code needs 18 instructions and spills 2 registers while optimal assembler code (obeying the 68k AT&T ABI) is 6 instructions with no register spills. Volker's translated comment was something like, "In the tests I did, this case occured very rarely (and today most coding guide lines would forbid something like that)." It's almost like we have 2 different C languages except that the abstracted and highly optimized version of the language seems to have won out but sometimes at a cost. Most old non-optimizing C compilers would do a better job with this code.

Originally Posted by Olaf Barthel

The practice of passing function parameters only over the stack can be criticized. In terms of "low hanging fruit" optimizations, this is where significant performance and size improvements can be gained. But this just was not possible back in 1986. What was possible was the high quality code and in particular the highly optimized code which the Green Hills 'C' compiler would produce.

Right. It was not possible with what was available. If the Green Hill's compiler was doing a good job of function inlining, a reg arg ABI will not give much performance. A study I read shows about 1% performance gain for a reg arg ABI with heavy function inlining using GCC and about 7% with function inlining turned off. Of course functions in an Amiga shared library can't be inlined so the 7% might give an idea of the gain from getting rid of the stubs. This is not much for a non-CPU intensive library but would be nice to have as the work is supposedly already done and it would save some kickstart space as well. Why wasn't the new intuition.library ever released (or was it in the 3.1 ROM but is still poorly optimized)?

Originally Posted by Olaf Barthel

Incidentally, a couple of weeks ago I watched Ed Logg's post-mortem on the game "The Gauntlet", which was created for a hardware platform rather similar to the Amiga in 1985. The hardware for "The Gauntlet" would use an MC68010 CPU, and the software was developed in 'C', using (guess what!) the Green Hills 'C' compiler. See [ Show youtube player ] for the presentation, which is titled "Gauntlet revisited by creator Ed Logg".

Ed Logg described the constraints imposed by the hardware on the game, and in particular how to achieve the desired frame rate with collision detection and the number of screen updates possible at that frame rate. One problem was in fact caused by the Green Hills 'C' compiler, which generated (I'm paraphrasing) too much code for the MC68010 to execute and keep the screen update rate within acceptable limits. In the post-mortem Ed Logg specifically mentioned that he had to write a post-processing program for the Green Hills generated code to work around this limitation.

So, that's how these things work out: on the one hand you can have great and robust code optimization which saves you the hassle of hand-optimizing it at the assembly language level, on the other hand you may have to balance the advantages of the more complex compiler doing the job for you with the side-effects (more code, ROM space constraints).

I'd say "intution.library" got off comparatively lightly in terms of performance constraints, its workings being driven mainly by user input (there's one big state machine at the heart of intuition). Where there are external constraints not directly related to user input (such as in "The Gauntlet"), making the code work well can be much more of a struggle.

Nice article on Gauntlet which is one of my favorite arcade games. It's another Gary Gygax influence. I have thought many times about doing an Amiga co-op networked (1 character per computer) remake with some reminiscent elements from Warcraft II and Diablo added. A M.U.L.E remake with co-op networking (simultaneous 1 character per computer action) and Warlords (simultaneous 1 character per computer action) would be fun also. Add standard voice chat support to the AmigaOS and the Amiga could be a social thing. I'm off to play a little DDO (Dungeon and Dragons Online) with my brother and a friend who played pen and paper D&D back in the day. It has the voice chat like I'm talking about. Gary Gygax even provided the DM voice for some quests and has a shrine. I had someone ask if it was worth waiting in line for the new NES console day before yesterday while playing and I told him about FPGA retro simulation hardware. I'm on the old Euro/German server Wayfinder if you want to check it out some time. There are still several German guilds too. I have a good story about accidentally running with some of them. I don't know if Amiga will ever get a clue that gaming and social networking are needed to bring the Amiga back. Those in charge seem quite oblivious.

Originally Posted by wXR

I fundamentally share in your pirate attitude. It is how I feel as well, but some people have a soft spot for the so-called law

It is not the "so-called law". It is the law.

Sadly, some people like you, <snip> "wXR" <snip>, working in the financial services business, don't respect the law. You seem to think that money can buy everything, like that $50K you offered to throw at anyone holding a grudge against Cloanto or Hyperion?

I don't know if the companies you work with approve of this conduct (maybe we should ask them?), but I don't like seeing people like you around our community, especially when they use populist words like "liberate".

If you don't like to respect laws, why not become a politician, or start a petition to change the law? But encouraging, even financing, a revolt against the law, targeting small software developers who stood out for their work to abide by the law, doesn't seem right to me.

[alpine9000]

Hopefully everyone can relax a bit!!

I think the situation the majority of us on here are looking for would hopefully be win-win for everyone.

Firstly, are the owners of the IP in a position to legally release the source code under GPL or similar ?

Next, is the value the community places on having the source released greater financially than the value the current IP holders receive from keeping it closed?

If the answer to both those questions is yes, (and we can raise the funds for point 2), then everyone wins.

[ptyerman]

Originally Posted by LadyJane85

It is not the "so-called law". It is the law.

Sadly, some people like you, <snip> "wXR" <snip>, working in the financial services business, don't respect the law. You seem to think that money can buy everything, like that $50K you offered to throw at anyone holding a grudge against Cloanto or Hyperion?

I don't know if the companies you work with approve of this conduct (maybe we should ask them?), but I don't like seeing people like you around our community, especially when they use populist words like "liberate".

If you don't like to respect laws, why not become a politician, or start a petition to change the law? But encouraging, even financing, a revolt against the law, targeting small software developers who stood out for their work to abide by the law, doesn't seem right to me.

Agreed and well said. It's this dismissive attitude from some that does a lot more harm than good, we're lucky really that most of the Amiga vendors/businesses are thick skinned and hardy and do largely ignore any negativity!

[Locutus]

Originally Posted by LadyJane85

It is not the "so-called law". It is the law.

Sadly, some people like you, <snip> "wXR" <snip>, working in the financial services business, don't respect the law. You seem to think that money can buy everything, like that $50K you offered to throw at anyone holding a grudge against Cloanto or Hyperion?

I don't know if the companies you work with approve of this conduct (maybe we should ask them?), but I don't like seeing people like you around our community, especially when they use populist words like "liberate".

If you don't like to respect laws, why not become a politician, or start a petition to change the law? But encouraging, even financing, a revolt against the law, targeting small software developers who stood out for their work to abide by the law, doesn't seem right to me.

Powerplant, is it you?

[ascp]

Originally Posted by alpine9000

Hopefully everyone can relax a bit!!

I think the situation the majority of us on here are looking for would hopefully be win-win for everyone.

Firstly, are the owners of the IP in a position to legally release the source code under GPL or similar ?

Next, is the value the community places on having the source released greater financially than the value the current IP holders receive from keeping it closed?

If the answer to both those questions is yes, (and we can raise the funds for point 2), then everyone wins.

Totally agree with the above!! LadyJane85 can you take your personal opionions about other forum members in P.M with them directly please?

[Olaf Barthel]

Originally Posted by matthey

FORTRAN and BLISS languages had optimizing compilers much earlier. C compilers did not do much optimizing early on because C is a low level language and further optimization was thought unnecessary and slowed compile times.

Last year I read the book "Expert C programming: Deep C secrets' by Peter van der Linden, which goes into great detail how the language design and the compiler evolved in tandem. The compiler was designed to be very compact, which, for example, explains why 'C' uses so very few reserved keywords and reuses them for different purposes (such as "static"). This is also why the more complex error checking operations were split off into the separate "lint" command.

In order to make the compiler run fast, it had to load fast, too, and this put pressure on the language design to make it simpler and more compact. I reckon that the original portable 'C' compiler was not spending too much effort on optimizing the code.

Programmers were supposed to be able to write efficient low level code for the CPU/hardware (Dennis Ritchie created C to better take advantage of the PDP-11 features, the CPU which heavily influenced the 68k).

I read Lions' commentary on Unix 6th edition when it was reissued in the late 1990ies: while the code had been edited for clarity and readability, it's hard to deny that it looks like it was hand-optimized, and then some. Very lean code - if only things could have stayed this straightforward

At the same time, C portability became more important than any previous language and the code could be optimized for different hardware. With portability came the need for more abstraction from the hardware and more of a need for optimization to give back performance which was lost in the process. This is the 2 headed monster of C with abstraction currently winning and low level coding suffering. I had a recent related e-mail conversation with Frank Wille (with comments from Dr Volker Barthelman). I was complaining about the vbcc 68k code generation for a simple and common C code which Dennis Ritchie himself had used in a book.

/* 
 * Source: Kernighan & Ritchie, The C Programming 
 * Language, 2nd Edition, Prentice Hall PTR, 1988, 
 * p. 105 
 * 
 * strcpy: copy t to s; pointer version 2 
 */ 

void strcpy(char *s, char *t) 
{ 
  while ((*s++ = *t++) != '\0') 
    ; 
}

The vbcc generated 68k code needs 18 instructions and spills 2 registers while optimal assembler code (obeying the 68k AT&T ABI) is 6 instructions with no register spills. Volker's translated comment was something like, "In the tests I did, this case occured very rarely (and today most coding guide lines would forbid something like that)." It's almost like we have 2 different C languages except that the abstracted and highly optimized version of the language seems to have won out but sometimes at a cost. Most old non-optimizing C compilers would do a better job with this code.

The old generation of 'C' compilers seems to have died out in the 1990'ies, eventually. For the Amiga Manx Aztec 'C' and Matt Dillon's compiler for DICE seem to have been the last generation of this branch.

But let's not overgeneralize: some optimizing 'C' compilers still generate cracking good assembly language code. It seems that the quality is somewhat related to how well the back-ends for the respective processor family are maintained. The MC68000 family is not getting the kind of attention it used to receive some 25+ years ago.

Right. It was not possible with what was available. If the Green Hill's compiler was doing a good job of function inlining, a reg arg ABI will not give much performance. A study I read shows about 1% performance gain for a reg arg ABI with heavy function inlining using GCC and about 7% with function inlining turned off. Of course functions in an Amiga shared library can't be inlined so the 7% might give an idea of the gain from getting rid of the stubs. This is not much for a non-CPU intensive library but would be nice to have as the work is supposedly already done and it would save some kickstart space as well.

It does save a lot of ROM space if you build intuition.library with SAS/C, using register parameter passing and keeping function inlining to a minimum. More space yet can be saved if you build the library for the 68020 instruction set. Even with the most basic optimizations enabled the code becomes more compact and faster.

It has been awhile since I looked at intuition.library. I recall that Intuition would not benefit greatly from inlining, flow analysis, etc. because it is fundamentally not built around algorithms and data structures which would. Singly-linked lists are the "backbone" of almost all the linked data structures which Intuition uses. Because there are no accessor functions or APIs for stringing them together or for processing them, scalability is very limited. The kind of optimizations which a compiler would bring to the table will not help you to conquer these limitations.

Why wasn't the new intuition.library ever released (or was it in the 3.1 ROM but is still poorly optimized)?

Because Commodore went out of business before the major changes in Kickstart V42 could have been more widely tested or sold.

I checked the code again, and it turns out that the last changes made to to intuition.library were performed by David Junod (not by Peter Cherna) in February 1994. At this time Commodore was only some three months away from bancruptcy.

[wXR]

Originally Posted by alpine9000

Hopefully everyone can relax a bit!!
Firstly, are the owners of the IP in a position to legally release the source code under GPL or similar ?

Next, is the value the community places on having the source released greater financially than the value the current IP holders receive from keeping it closed?

If the answer to both those questions is yes, (and we can raise the funds for point 2), then everyone wins.

These are indeed the most pressing questions.

I get the impression that the community -- as in, the whole of what is left that might actually care about this topic -- has never considered what AmigaOS 3.1's "liberation value" might be. Perhaps that is something to discuss with Powerplant here. However, as suggested in other threads, the actual ownership of its various components may be quite complex. My opening guess would be something in the range of $250,000 to $500,000 to fairly accommodate any actual rightsholders for the whole lot. And by "fair" I mean, the near-total depreciation of the asset could be hand-waved in order to make almost everyone happy.

"Thanks for trying, buddy."

On the front of general progress, I've been negotiating with counsel over the weekend who will hopefully accept a retainer and begin to take on -- at the very least -- the aforementioned "disentanglement" according to available documentation. Assuming this is a go, I'm going to ask said counsel to maintain a presence here in this forum, so that something like public accountability is maintained. I'm sure there will be a temptation by one or two members here to burn up the retainer with false leads, so it will probably have to be a unidirectional presence for the time being. There are a few other avenues that I will be pursuing simultaneously (thanks to grond for a few tips) in order to tease out actual ownership. Despite the quite interesting idea of simply accepting the surface story, I decided it is best to go all the way so that this cannot be challenged again later.

[DamienD]

I've had to edit your post LadyJane85 (and subsequent quotes of your post afterwards).

Please do not ever post people's real names anywhere on EAB without the person's permission to do so...

Do it again and I will permanently ban you immediately

[kolla]

Originally Posted by LadyJane85

It is not the "so-called law". It is the law.
...
If you don't like to respect laws, why not become a politician, or start a petition to change the law?

You are definitely _not_ from Belgium!!

[tom256]

Not to go into details.

Problem is that nobody is developing AOS3.x. Who care about AOS PPC 4.x. 100 people?? Maybe even not.

Most of people want to have new version of AOS for Amiga classic. We want support of big HDD in ROM, improved libraries, optimized exec, new features. Just to confirm my word please check sell of AOS4.1 Final for Amiga Classic. Hyperion was surprised and wasn't prepare to sell so many copies.

Still Amiga Classic market is few thousand people looking for new products. It at least few time bigger than AmigaNG market. Most of us do not care about AmigaNG, from our point of view this OS is wasting of time and resources (Same for MorphOS, who need it?).

[utri007]

Originally Posted by tom256

Not to go into details.

Problem is that nobody is developing AOS3.x. Who care about AOS PPC 4.x. 100 people?? Maybe even not.

There are several thousands Amiga OS4 users. It is not much, no doubt for that.

I'm very pleased with my Sam 440ep Flex and most likely will bought Tabor when it comes out. I hasn't have lots of use, but is my "retro room's" download / web surf machine.

OS3/68k problem is that even when community is big, most of us things that everything should be free, or available from recycle bin.

Lately here has been loud crying when something cost something like 5€.

I'm very surpriced how well Vampire has been sold or has it? I expressed interest, but decided not to go that route. Instead I decided upgrade my Apollo 68040 accelerator to 68060. Now I have two 68060 accelerators. Vampire seems to be about 150-200mhz 68060 equivalent, it has very powerfull 68k cpu, but it doesn't matter, 50mhz-400mhz is not enough for any general use.

[Lord Aga]

Originally Posted by utri007

There are several thousands Amiga OS4 users.

That would be 3,000 - 4,000 - 5,000 people with PPC "NextGen" machines? I seriously doubt that.

[grond]

Originally Posted by Lord Aga

That would be 3,000 - 4,000 - 5,000 people with PPC &quot;NextGen&quot; machines? I seriously doubt that.

Even if there were more than 1,000 active AOS 4.x users, how many of them would not use a 68k-Amiga with similar processor speed? I believe that not only the number of 68k-Amiga users is much higher than that of PPC-Amiga users but also that a much higher proportion of 68k-Amigas simply doesn't consider PPC-Amigas a viable option.

[utri007]

Pointless, there is no 800mhz - 2000mhz 68k cpus. OS has no updates or updates are actually "downgrades". There are plenty 68k hobbyists with emulated enviroment with pirates kickstart and OS or with A500 and gotek . They don't buy anything, they just play old games. Sometimes they start to cry if something costs about 5 euros.

[wawa]

hehe