Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Topic started by: amigakit on November 03, 2014, 09:41:48 PM
-
Our customers have regularly been asking for replacement Workbench floppy disk sets since their older disks have either become corrupted or worn out due to age. About a year ago, we approached our friends at Cloanto to enquire about a possible solution. As a result, we are pleased to announce the immediate availability of new Workbench 3.1 Floppy Disk Set (http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=1211)
(http://amigakit.leamancomputing.com/catalog/images/workbench_3.1_disk_set_sm.jpg)
This new distribution comes with some minor enhancements and updates:
- Updated C/Version (Y2K patch)
- Addition of Libs/workbench.library (for A-4000T 3.1 ROMs and 3.X ROMs)
- Updated S/Startup-Sequence (for 3.X ROMs)
- Updated Installer 44.10 and FastFileSystem 45.9 (to support larger disks)
- Installer itself is now part of the system installation (inside the Utilities directory)
As you may notice these disk sets are also compatible with the Amiga 4000T (workbench.library on floppy) so there is no requirement any longer to have two distributions of Workbench 3.1 media.
Direct Product Links:
United Kingdom Store (http://amigakit.leamancomputing.com/catalog/GBP.php?url=product_info.php?products_id=1211)
Europe Store (http://amigakit.leamancomputing.com/catalog/EUR.php?url=product_info.php?products_id=1211)
United States Store (http://www.amigakit.us/product_info.php?products_id=1211)
Canada Store (http://amigakit.leamancomputing.com/catalog/CAD.php?url=product_info.php?products_id=1211)
Thank you to Cloanto for their support in this project
-
Good price too! :-)
-
Good to see this.Is there a chance that in future you could enhance it even more? It was amazing to see what Cammy/Rebel achieved with 3.1 and only 16 colours. Would something like that be possible?
-
I will be ordering a set of these soon as I am done moving to the new house.
Any chance we could see an updated AmigaOS3.9 CDROM published in the future, with Boing Bags 1 & 2 already added, plus a collection of further enhanced files that people have been working on for years for a proposed Boing Bag 3?
I know getting all of the contributors to agree to a new AOS3.9 release would be difficult, as some of them may have left the community in recent years, but it never hurts to ask, even if the answer is NO. With the possibility of new FPGA clones of Amiga hardware coming out within the next year at speeds equal to over 300MHz Motorola 68000, plus some of the features of the 68020 and higher series chips implemented, and with the possibility of Picasso96 RTG emulation included, I would think that many users might be interested in purchasing a new updated version of AmigaOS3.9, to run on these new accelerators, or stand alone systems.
-
Ordered WB 3.1 while AmigaKit was stuck on Amiwest.
Hope they arrive soon, so I can do a clean install of my WB. Since Ive been re-learning WB 3.0 while adding hardware here and there, I get error messages. Learn by trial and error ;)
I was looking thru Cammys WB pallette/workbench setup just now. It really looks great!
I guess the skins shes mentioning in the post is giving the Startbutton and Workbench upper bar.
http://eab.abime.net/showthread.php?t=51657
http://eab.abime.net/showpost.php?p=732542&postcount=114
-
Q: Wasn´t Cloanto´s workbench distribution license only valid for emulation purposes? If then, can this be considered an ilicit act?
Could anyone shed some light on this?
Thanks
-
for a proposed Boing Bag 3
BB3 is already out, so is BB4, if you count the community-driven projects available for download here:
http://lilliput.amiga-projects.net/bbag4.htm
Occasionally people have trouble installing them, but that's the nature of Amiga software in general for ya. Many crazy configs, occasionally someone's going to have an issue. Myself and many others run them daily without any trouble. Runs like butter on my A2000! ;)
There's even updates beyond this, things like Peter K's icon.library that's updated every month or so. Definitely worth a look on Aminet for updates to many of the "core" OS files!
-
I was looking thru Cammys WB pallette/workbench setup just now. It really looks great!
If you haven't already seen it, check out this guide. Works great on mid-spec ECS machines, if that's what you have.
http://www.mfilos.com/2012/01/guide-making-workbench-prettier-using.html
-
My setup is;
A1200 with Blizzard 1230/50 Acceleration card+16 megabytes
Indivision mk 2
CF 4 gig
AmigaOne Keyboard
USB Mouse
RapidRoad 2xUSB thru clockport
So its a decently tricked out A1200 :P
(still havent gotten around to get the CD rom going, but Im sure WB 3.1 should be enough).
BUT I will check out the blog. Thanks :) (EDIT: checked it out, very nice!)
-
BB3 is already out, so is BB4, if you count the community-driven projects available for download here:
http://lilliput.amiga-projects.net/bbag4.htm
Occasionally people have trouble installing them, but that's the nature of Amiga software in general for ya. Many crazy configs, occasionally someone's going to have an issue. Myself and many others run them daily without any trouble. Runs like butter on my A2000! ;)
There's even updates beyond this, things like Peter K's icon.library that's updated every month or so. Definitely worth a look on Aminet for updates to many of the "core" OS files!
I sort of knew that already, but thought that BB1 & 2 were the only official Boing Bags released and everything after that was unofficial.
My point remains that some users would prefer an updated AmigaOS3.9 CD with all of the latest improvements already included, plus a comprehensive Install Script that would give us choices to install or not install any of the more questionable recent upgrades for AmigaOS3.x, would be really great. Some users out there (maybe you) are much better and more patient at testing and installing dozens of new patches and updated files, to get the most modern and efficient AmigaOS3.x experience, while others (like me) just want to pop a CD into the drive and hit the install button, with the possible exception of making a few simple choices on files that work better in certain situations, or on certain specific hardware models.
It would be a difficult job to find and obtain all of the approvals from 3rd party developers who have contributed to all the parts contained within AmigaOS3.9 and all of the Boing Bags since that time. Some of them may want a small royalty for selling their work again (which is fine with me). I would guess Hyperion would need to be involved, as I believe that they own the rights to AmigaOS3.9 (possibly excluding a few parts of it contributed by those same 3rd party developers), but I think it could be done, if someone had the determination to stick with it and track down everyone that has contributed.
I appreciate the people still working on updating AmigaOS3.x, because I never want to see that part of our community fade away, even though I am also a MorphOS and AmigaOS4.x supporter and user.
Edit: Just thought of another way in which much less approvals would be needed. If the updated AmigaOS3.9 were only an executable file that only contained the required files that have been added or modified after AmigaOS3.9 BB2, then it could include in the installer script, options to specify the locations of the users AmigaOS3.9 CD or ISO file and the two Boing Bag files on his hard drive. Then it would use those resources to do a new install that included the new and updated files that make up the unofficial Boing Bag 3 & 4 contributions. That way no copyright or intellectual property infringement would occur. The only downside to this idea is that those original AmigaOS3.9 CD's will eventually begin to fail or contain read errors.
-
Pretty cool there is def a need for this!
-
Q: Wasn´t Cloanto´s workbench distribution license only valid for emulation purposes? If then, can this be considered an ilicit act?
Could anyone shed some light on this?
Thanks
Perhaps they're supplied just to use with emulation. Shame if the disks "accidentally" slipped inside a real Amiga. ;)
Nice idea to update some of the files. Perhaps some pre-configured media cards containing complete hard drive setups of ClassicWB, Better Workbench, etc. could be marketed.
-
Lets face it, most of our Commodore Workbench disks are at least 20 years old now. I keep mine still wrapped up and use backups to preserve them. However we get a lot of telephone calls from customers with read/write errors struggling to boot their Workbench etc.
-
A bit offtopic;
But will my amiga-setup as shown above+the network card I ordered for the A1200 be able to use AmiStore? Or will the Store be restricted for ClassicPPC Amigas?
-
Yes. Quite a bit off topic :) an 030 is going to stuggle. My 060 finds it difficult. I will develop a more primitive GadTools version later for 030s.
-
How about a cd called AOS 3.86 or 3.89 or 3.99? :)
I would be great if AmigaForever could have a program for making a disk set.
It could be an external program.
-
Q: Wasn´t Cloanto´s workbench distribution license only valid for emulation purposes? If then, can this be considered an ilicit act?
Could anyone shed some light on this?
Thanks
Yes.
-
Oh man! if I had known this was available a few days ago. I just ordered the 4gb CF drive and I should have had this pre installed.
Hopefully my discs still function.
-
Oh man! if I had known this was available a few days ago. I just ordered the 4gb CF drive and I should have had this pre installed.
Hopefully my discs still function.
Contact AmigaKit and see if they have shipped your order already, or if not, have them amend your order to include the AmigaOS3.1 disks on your CF card. Since Matthew just returned from his AmiWest trip, they might be a day or two behind in processing orders and you might get lucky (though they are usually pretty fast at getting their orders packed up and shipped out).
-
wish there was a store in australia
-
Q: Wasn´t Cloanto´s workbench distribution license only valid for emulation purposes? If then, can this be considered an ilicit act?
Could anyone shed some light on this?
Thanks
OMG. 20+ years old software has been taken out from the grave of an ADF-only existence, for the delight of people who *needs* to use it on vintage systems, and you have to be worried about the licenses? This initiative should have been taken by the OS owners (A. Inc) or direct licensee (Hyperion), while you have to thank Cloanto, once again, for the great work and the useful service it did.
Relax, I am pretty sure Michele and others at Cloanto correctly verified all the legal issues before doing this, considering the attention too much people pays in futile things.
-
Got mine on order.
Just wish shipping wasn't so much from across the pond, but such is life.
Curtis
-
Contact AmigaKit and see if they have shipped your order already, or if not, have them amend your order to include the AmigaOS3.1 disks on your CF card. Since Matthew just returned from his AmiWest trip, they might be a day or two behind in processing orders and you might get lucky (though they are usually pretty fast at getting their orders packed up and shipped out).
Nope, Missed it. They shipped it out on Monday morning just before I read this post.
Oh well....
-
From the press release:
Thank you to Cloanto for their support in this project
I understand it's a press release, but that's a bit over the top, isn't it?
Here's cloanto's press release on the matter (http://www.amigaforever.com/news-events/classic-support-3-1/).
-
We approached Cloanto over a year ago with this project in direct response to listening to customer feedback on the matter. We are grateful for Cloanto's help here by bringing Workbench 3.1 back into distribution. Any genuine Amiga classic customer will be happy too at this news and that is what is important to us.
@tonyvdb
Sorry that you missed this - but thank you for your order.
@curtis
Thank you for your order too!
-
Since I where investing in some hardware bits and pieces for my A1200, I did wonder how long until my workbench disks last. Pretty much the reason why I got the WB 3.1.
For that inevitable failure.
-
OMG. 20+ years old software has been taken out from the grave of an ADF-only existence, for the delight of people who *needs* to use it on vintage systems, and you have to be worried about the licenses? This initiative should have been taken by the OS owners (A. Inc) or direct licensee (Hyperion), while you have to thank Cloanto, once again, for the great work and the useful service it did.
Relax, I am pretty sure Michele and others at Cloanto correctly verified all the legal issues before doing this, considering the attention too much people pays in futile things.
I am relaxed. It is that it is just funny to watch the cyberpirate police doing this kind of thing. Irony at its best.
And, I dont need to thank anyone. It is just another business. If it was a non profit scheme, then they would surely deserve gratitude.
So chill out mate, and enjoy the bumpy ride! :)
-
This new distribution comes with some minor enhancements and updates:
- Updated C/Version (Y2K patch)
- Addition of Libs/workbench.library (for A-4000T 3.1 ROMs and 3.X ROMs)
- Updated S/Startup-Sequence (for 3.X ROMs)
- Updated Installer 44.10 and FastFileSystem 45.9 (to support larger disks)
- Installer itself is now part of the system installation (inside the Utilities directory)
As you may notice these disk sets are also compatible with the Amiga 4000T (workbench.library on floppy) so there is no requirement any longer to have two distributions of Workbench 3.1 media.
So what you (Cloanto?) has done here, is actually to de-facto develop Amiga OS 3.2 and brought it to the world wide market! Congratulations! :) And IMHO you should have called it by its "real" name, "3.2" beats "3.1" any day! ;)
You should have struck a deal with Geit and put the excellent Grunch (http://www.geit.de/eng_grunch.html) tool on those disks by default! That way you could have provided an endless update stream to Amiga OS, further extending it by using AROS 68k components (for example).
But maybe you are saving that for Amiga OS 3.3? I recall some other OS vendor who once released a version bumped OS with the only update being the inclusion of a package manager! ;)
:)
-
Any chance we could see an updated AmigaOS3.9 CDROM published in the future, with Boing Bags 1 & 2 already added, plus a collection of further enhanced files that people have been working on for years for a proposed Boing Bag 3?
A great idea, Amiga OS 3.9 with all the related "boing bags" or whatever is a bit of a mess; it would be great if Haage&Partner would bring it all together into an Amiga OS 3.10 release to tidy things up and connect all the loose ends! :)
Someone should ask them. It seems to be some money to make on Amiga OS still, and if it can be done in an effortless enough way, then who knows? ;)
I know getting all of the contributors to agree to a new AOS3.9 release would be difficult, as some of them may have left the community in recent years, but it never hurts to ask, even if the answer is NO.
No need to ask, I presume the papers for Amiga OS 3.9 with all associated boing bags is already in order, it has been on the market for 1.5 decades after all, the only thing really needed is to license Grunch (http://www.geit.de/eng_grunch.html) and build up a SW database, where modern AROS components compiled for 68k could be used to develop the Amiga OS further! Long time overdue! :) (EDIT: And there are examples of other efforts (http://www.amiga.org/forums/showthread.php?t=67146) as well, of course! :))
I would guess Hyperion would need to be involved
Not at all, Haage&Partner has their own license, and they actually have a license to *develop* Amiga OS! ;)
as I believe that they own the rights to AmigaOS3.9
They don't, Haage&Partner does.
Amiga OS 3.1 is owned by Amiga Inc, but Hyperion has the:
"exclusive, perpetual, worldwide and royalty-free, transferable right and Object Code and Source Code license to [Amiga OS 3.1] in in order to use, develop, modify, commercialize, distribute and market [Amiga OS 3.1] in any form (including sublicensing), on any medium (now known or otherwise), through any means (including but not limited to making AmigaOS 4 available to the public via the Internet) and for any current or future hardware platform. For the avoidance of doubt with respect to the exclusive nature of the license granted to Hyperion for [Amiga OS 3.1] (but without prejudice to any Existing License Agreements listed on Exhibit 1), the Amiga Parties shall during the term of this Agreement not commercialize anywhere in the world (including through sub-licensing), distribute (free of charge or otherwise) or make available to the public (free of charge or otherwise), in any way or form (including but not limited to Object Code and Source Code form), on any medium (now known or otherwise) and through any means (now known or otherwise) [Amiga OS 3.1] (in part or as a whole) and any Operating System exhibiting a Software Architecture substantially similar to the Software Architecture of [Amiga OS 3.1] as described in the Documentation"
But indeed this might not mean in practice what it says in writing! It sure doesn't look like that now!
:)
-
OMG. 20+ years old software has been taken out from the grave of an ADF-only existence, for the delight of people who *needs* to use it on vintage systems, and you have to be worried about the licenses?
I agree. I have never liked Hyperion anyway. Neither Amiga Inc for that matter.
:pissed: ;)
This initiative should have been taken by the OS owners (A. Inc)
They are not allowed to.
or direct licensee (Hyperion)
They are allowed, but probably don't want to. After all, they are *already* pushing what they consider to be an evolved product based on Amiga OS 3.1.
Relax, I am pretty sure Michele and others at Cloanto correctly verified all the legal issues before doing this, considering the attention too much people pays in futile things.
Yeah, it will be interesting to see (on moobunny of course :lol: ;)) how this unfolds!
:)
-
That is great that you can finally get replacement Workbench 3.1 disks.
I think another OS disk that would probably benefit the A1000 owners is the V1.3 KICKSTART disk.
I know many instances of people requesting them for their newly acquired A1000s.
-
I have never liked Hyperion anyway. Neither Amiga Inc for that matter.
Go on, tell us how you really feel! :roflmao:
-
Nice to see this, but it looks like Amigakit is formatting HD media as DD media (see the two holes in either corner of the disk). That could lead to short life of the data stored on the disks. Longevity and reliability would be improved if these were real DD disks. Still available from here:
http://floppydisk.com/
-
Ug! I looked in all over for A4000T original disks a few years ago to no avail. I finally sold it off (don't judge) last year but was only able to give the boxed standard 3.1 disk set and the A4000T on "backup".
It's nice to know there are people with the ability to help the community doing just that! Keep it up!
Golden
-
@ amigakit
this is great news! just left a message on your site as well, please put these much needed replacement disks along with my latest order as my originals need a much deserved break after all these years;)
-
@ral-clan
We are using real DSDD 1MB disks.
@klx300r
Many thanks :)
-
Just for the record: these Disks are also available from Vesalia.de or amistore.eu. Amigakit is not the exclusive reseller of this Cloanto product.
-
@zylesea
So it looks like our project idea with Cloanto will benefit other resellers too?
-
Nope, Missed it. They shipped it out on Monday morning just before I read this post.
Oh well....
Yeah, they are usually quick on getting orders processed and shipped out the door, but it was worth checking on, just in case they had some kind of delay.
Enjoy your new bits of Amiga and the new 3.1 floppy disks. I will be ordering my own set soon. :)
-
@ral-clan
We are using real DSDD 1MB disks.
@klx300r
Many thanks :)
I remember a scare several months ago when some people were claiming that floppy disk production was going to stop and that they would be harder and more expensive to obtain in the near future. I guess that hasn't happened yet.
It is a shame that some perfectly working products stop being produced after newer alternatives take over as better products. This seems to happen with computer gear at a much faster rate than other areas. The rate of change in the computer industry is not always a good thing, and I remember the argument that Amiga users were lucky because they did not have to replace their computer every 2 or 3 years, like PC users and even Mac users did. The flip side of that is that Amiga users lost our parent company, partly because they did not continue to improve and innovate the Amiga at an acceptable rate, and it was discounted by most other outside users as just a game machine.
Back on topic, I am glad we can still get new floppy disks, even the DSDD ones seem to be available for now.
-
if only you could boot/install right off the CD drive. Then the discs would be less of a concern.
-
Amen to that!
-
if only you could boot/install right off the CD drive. Then the discs would be less of a concern.
3.9 can almost install off CD, all it needs is a single "Emergency" boot floppy to get it started. Still better than six. So close, so close! ;) Might have to try making a bootable USB, have heard there's others who have done it. One of these days when I have the time! ;)
-
If you have a Gotek USB floppy and have backed up your 3.1 floppies to adfs you don't need floppy disks anymore. http://cortexamigafloppydrive.wordpress.com/
But then again there's something about that floppy drive noise that is therapeutic...
-
i got multiple copies since i had to pay someone 20.00 for a pirate copy of 3.1 which i couldnt find..needed the install 3.1 disk to use my harddrive...these days i use the copy of 3.1 thats on the 3.5 workbench cd rom ..very handy ..with more datatypes etc ..thought about putting the cdrom copy onto floppy dunno if that would work..
-
Can you buy the ACA 500 accelerator with 3.1 pre-installed now then?
-
Hi Paulie85
You could buy the ACA 500 (http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=1168) then add the 4GB CF with Workbench 3.1 (http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=1214). That should do what you need :)
-
Well, I complained earlier about the cost of shipping from the UK to the USA, but I may have to retract some of that.
My set of disks is scheduled to be delivered tomorrow! WOW!! Order Tuesday and receive in on Thursday!
Heck, I would've been happy with a week delivery time, but 2 days and across the pond!
Very good amigakit. Very good.
M. Curtis McCain
-
Kinda cool, but at this day and age, the Gotek drive works as my ever reliable Work Bench recovery method. No floppies that age, no old drives that become defective or experience read errors.
-
Kinda cool, but at this day and age, the Gotek drive works as my ever reliable Work Bench recovery method. No floppies that age, no old drives that become defective or experience read errors.
Funny that's the exact same reasons why I love the original hardware and especially those very special sounds that bring me right back to a glorious time when computing was magical & yes ...roll the music...fun:)
Amiga 1000 sounds (http://www.youtube.com/watch?v=5UhiNbGTLt8)
-
I thought the last few of us remaining amiga users were resourceful enough to use ADFs?
I've 'recreated' my original A1200 WB3.1 disks at least twice in the past 20 years, by whacking ADFs back onto new DD floppies. I even reprinted nice glossy labels to go on the disks...
Mike.
-
@ mingle
+1 I made a backup with ADF's of mine too but problem I had was I couldn't find new DD disks and ended up using old disks I had lying around and just reformatted them so it's great to have the whole set with nice updates for a reasonable cost on new DD disks
-
I thought the last few of us remaining amiga users were resourceful enough to use ADFs?
I've 'recreated' my original A1200 WB3.1 disks at least twice in the past 20 years, by whacking ADFs back onto new DD floppies. I even reprinted nice glossy labels to go on the disks...
Mike.
You are right, most of us are resourceful enough to backup and recreate our Workbench Floppy Disks, but many users have neglected to do that, or may have been busy with other things in life and are just now returning to using their Amiga computers only to find that their disks have become corrupt while sitting in a box in the closet or attic.
Also there are a few new users finding out about the Amiga through emulation who then decide to go out and find a Commodore 68k Amiga on the used computer market and might get one without the floppy disks included, or the disks they get are corrupted.
All I know is that there have been requests for this product from several users, so I am happy that AmigaKit asked Colanto to produce these disks.
Now I just hope that someone will step forward and give us an updated version of AmigaOS3.9 with all of the 4 Boing Bags already included, plus any other system files, tools and utilities which have been improved or added since the completion of Boing Bag 4 was done a while ago. :)
I think that a version equal to AmigaOS3.10 would make lots of users happy. The experienced users know how to make their own custom Kickstart ROMs and choose all the right components to make the best AmigaOS3.x experience, but some users (like me) would gladly pay for all of that work to be done by the experts and just pop a new CD into my fast Amiga models and double click on an install icon for AmigaOS3.10 (A4000 w/80MHz 68060 & A1200 w/50MHz 68060, plus hopefully someday a 68060 powered Daughter board for my FPGA Arcade Replay board). As I wrote already earlier in this thread, I think that many buyers of the proposed Apollo FPGA accelerators or stand alone systems will want AmigaOS3.9, or an enhanced version equal to AmigaOS3.10, instead of AmigaOS3.1. Since these new accelerators are supposed to have built-in USB hardware on them, perhaps the Poseidon USB stack could also be included in AmigaOS3.10. I would really like to see this project happen and would gladly pay $40 to $50 for a new AmigaOS3.10 CD. Maybe I am the only one thinking that way and everyone else would rather do it themselves?
-
So, would it be better off to use this updated version of OS 3.1 or to get 3.9? I have the 3.5 CD but is 3.1 a better option if Im still planning to run the video toaster flyer software (yes I know its outdated now that HD is out) I still like to play with it as well as Lightwave.
-
wish there was a store in australia
I can never get them at the USA phone number. I wish AmigaKit would put a man and some small stock at the San Francisco mailing address. That would make it easy to get a hold of them in the western US and Australia time zones.
Chris
-
I can never get them at the USA phone number. I wish AmigaKit would put a man and some small stock at the San Francisco mailing address. That would make it easy to get a hold of them in the western US and Australia time zones.
Chris
Our phone server is down at the moment.
-
So, would it be better off to use this updated version of OS 3.1 or to get 3.9? I have the 3.5 CD but is 3.1 a better option if Im still planning to run the video toaster flyer software (yes I know its outdated now that HD is out) I still like to play with it as well as Lightwave.
I'm hoping someone will come along and give you more knowledgeable response to this, but wasn't there some compatibility issues between the Toaster software and 3.9? If not, and your system is beefy enough to support it, I'd see no reason not to run 3.9 (unless you want that nostalgia factor). ;)
-
I was able to get it to work with 3.5 but it took some rearranging how the files were placed in folders. It was a pain but it worked.
-
Our phone server is down at the moment.
;)
(http://makeameme.org/media/created/Hello-IT-Have.jpg)
-
;)
(http://makeameme.org/media/created/Hello-IT-Have.jpg)
Of course, I knew Id forgotten something, ;).
Need to find some time to fix it.
Tis true though for alot of todays tech. Remember going out to loads of service calls, just to turn customers TV's off and on again.
SONY's were the worst, had to leave them off for 20 mins as the caps held their charge that long.
-
Yes my os 3.1 are on the way ,wonderful and on we go best wishes Brian
Nice one Amigakit
-
My point remains that some users would prefer an updated AmigaOS3.9 CD with all of the latest improvements already included...
I would guess Hyperion would need to be involved, as I believe that they own the rights to AmigaOS3.9 (possibly excluding a few parts of it contributed by those same 3rd party developers)
It doesn't look like Hyperion has sufficient rights to do this under the Settlement Agreement between Amiga and Hyperion. The copyright part is a bit vague, leaving it to paragraph (c) of the Grant (1.) section to explain the scope of the agreement, which is what Amiga users always knew it was about, namely developing AmigaOS 4 for the PowerPC:
Solely for the purposes of marketing, distributing and making available AmigaOS 4 and any hardware required or desired to operate with AmigaOS 4...
-
Q: Wasn´t Cloanto´s workbench distribution license only valid for emulation purposes? If then, can this be considered an ilicit act?
Could anyone shed some light on this?
Did you see this (http://www.amigaforever.com/news-events/classic-support-3-1/) from the Amiga Forever site:
a "Classic Support" scenario was explicitly outlined in a Coexistence Agreement between Amiga, Inc. and Cloanto, for use also outside of emulated Amiga systems.
-
Is scsi.device also updated to support large drives?
-
Updated kickstarts would be great too. In general, an AmigaOS "3.2" with all essencial bits updated to what is in 3.9+boing bags, things like shell, various libs, handlers and devices - a 3.9 without all the fluff (Reaction etc) from 3.5 and 3.9. I have put together something like this already for my minimig.
-
Despite legal constraints: There's also a serious size constraint here to place 3.9 (or parts thereof) in ROM. The workbench.library is considerably larger than the 3.1 version, and so is the Shell. One way or another, something has to go from ROM. Workbench is a candidate, audio is a candidate, mathieesingbas is a candidate (the latter for more than one reason). It remains a bit unclear which compatibility issues may arise from this, which is probably the reason why nobody wants to do it.
-
Despite legal constraints: There's also a serious size constraint here to place 3.9 (or parts thereof) in ROM. The workbench.library is considerably larger than the 3.1 version, and so is the Shell. One way or another, something has to go from ROM. Workbench is a candidate, audio is a candidate, mathieesingbas is a candidate (the latter for more than one reason). It remains a bit unclear which compatibility issues may arise from this, which is probably the reason why nobody wants to do it.
Actually, if one were to build a new ROM there could be sufficient free space to keep all components in it. I tested this with a fully native build that utilizes SAS/C for almost all components. That change allows for considerable space savings, e.g. the A4000T ROM has enough room for the SCSI/ATA scsi.device flavours and workbench.library to fit. Taken a step further, the disk-based icon.library that was part of AmigaOS 3.5/3.9 could fit, too. The same could be done for the A1200 V40 ROM which has almost no free space left.
However, this native build is pretty much untested. If one were to use its components, mix them with existing components, the results might be more mature and robust than in a fully native build.
-
Actually, if one were to build a new ROM there could be sufficient free space to keep all components in it. I tested this with a fully native build that utilizes SAS/C for almost all components. That change allows for considerable space savings, e.g. the A4000T ROM has enough room for the SCSI/ATA scsi.device flavours and workbench.library to fit. Taken a step further, the disk-based icon.library that was part of AmigaOS 3.5/3.9 could fit, too. The same could be done for the A1200 V40 ROM which has almost no free space left.
However, this native build is pretty much untested. If one were to use its components, mix them with existing components, the results might be more mature and robust than in a fully native build.
Strange, so what's so incredibly huge in the 3.1 ROMs that CBM got so tight on ROM space? intuition alone? Ok, there *is* indeed some headroom left in the A2000 ROMs (and A500's of course), but as soon as the scsi controler or/and the on-board IDE had to go into ROM, CBM tried really to cram in the bytes.
-
Strange, so what's so incredibly huge in the 3.1 ROMs that CBM got so tight on ROM space? intuition alone? Ok, there *is* indeed some headroom left in the A2000 ROMs (and A500's of course), but as soon as the scsi controler or/and the on-board IDE had to go into ROM, CBM tried really to cram in the bytes.
As far as I recall the only two V40 ROMs which had little room to spare were those for the A1200 and A4000T models.
The A1200 ROM basically covers everything which the A500/A600/A2000 needs, which means PCMCIA hardware support. The big difference is in the graphics.library, which is significantly larger for the A1200 due to AA support, than the ECS version used in the A500/A600/A2000 ROM.
The A4000T ROM has even more crammed into it, which includes the ATA scsi.device, the really large A4091 scsi.device (which itself includes the bootstrap script for the NCR SCSI controller) and the large AA graphics.library. The combination of these components left no room for workbench.library, which was moved out to disk.
V40 was built almost exclusively using Lattice 'C' 5.04 which did not feature the more refined and effective optimization functionality available later in SAS/C. Commodore did not use SAS/C for production code, or for that matter, used 68020 code generation, because of code generation maturity issues. Because of this, all the compiled 'C' code was targeted for the plain 68000, and no 68020 specific optimizations could have helped to reduce the code size for the A1200/A3000/A4000/A4000T.
-
Actually, if one were to build a new ROM there could be sufficient free space to keep all components in it. I tested this with a fully native build that utilizes SAS/C for almost all components. That change allows for considerable space savings, e.g. the A4000T ROM has enough room for the SCSI/ATA scsi.device flavours and workbench.library to fit. Taken a step further, the disk-based icon.library that was part of AmigaOS 3.5/3.9 could fit, too. The same could be done for the A1200 V40 ROM which has almost no free space left.
Please leave the icon.library out of Kickstart. Everybody is using PeterK's icon.library because it's much faster, smaller and supports most Amiga icon types.
The A4000T ROM has even more crammed into it, which includes the ATA scsi.device, the really large A4091 scsi.device (which itself includes the bootstrap script for the NCR SCSI controller) and the large AA graphics.library. The combination of these components left no room for workbench.library, which was moved out to disk.
V40 was built almost exclusively using Lattice 'C' 5.04 which did not feature the more refined and effective optimization functionality available later in SAS/C. Commodore did not use SAS/C for production code, or for that matter, used 68020 code generation, because of code generation maturity issues. Because of this, all the compiled 'C' code was targeted for the plain 68000, and no 68020 specific optimizations could have helped to reduce the code size for the A1200/A3000/A4000/A4000T.
SAS/C "refined and effective optimizations"? You have to be kidding. The icon.library was compiled with SAS/C and PeterK's optimized version is now about 35% smaller with much added functionality (my record library reduction is 43% but that was an early version of GCC/EGCS which I could take to half size with some effort). I would say that SAS/C is better for size than speed. I have a working and well tested workbench.library which is 191168 bytes without any hand optimizations from me (it has bug fixes applied). I bet I could optimize away another 10kB or so with basic hand optimization (getting rid of that slow SAS/C copymem routine would probably save 500 bytes alone). Granted the code quality is nowhere near as bad as the intuiton.library. It might be worth trying vbcc for small executable sizes. Vbcc's features:
+ best 68k peephole optimizing assembler ever in vasm
+ uses optimized inlined assembler functions (the default)
+ sophisticated optimizations that exceed SAS/C (some don't seem to work)
+ cross-assembler for fast compiles on faster computers
+ good Amiga and 68k features and support (Amiga hunk output, IEEE math libraries for fp)
+ actively maintained by knowledgeable and helpful people who know the 68k and Amiga
+ source code available and compiles on a 68k Amiga with few dependencies
+ free for Amiga use
+ easy Amiga installation
+ good c99 support
? some of the link code is highly optimized (hit and miss)
- the 68k backend is average at best
- no 68k instruction scheduler
- lacking tools although many GCC and SAS/C tools are compatible (CPR debugger)
- slow at compiling
- memory hungry
- no C++ support
There should be a much improved version of vbcc out in the next few weeks. SAS/C is a dead end last decade compiler. How about giving the new version of vbcc a try?
-
Please leave the icon.library out of Kickstart. Everybody is using PeterK's icon.library because it's much faster, smaller and supports most Amiga icon types.
Relax, nobody is going to release a new kickstart anyhow, exactly due to the legal problems it would cause.
SAS/C "refined and effective optimizations"? You have to be kidding.
Back then had a good optimizer, compared to the other compiler(s) that were available, Manx (Aztec) namely. Gcc had an even better optimizer, but no (or unsufficient) native support for the Amiga toolchain, so it was often not an option to use.
I really haven't tried vbcc, so I cannot judge, but a lot of the compiles here depend on some SAS/C magic, for example layers depends on SAS/C being able to use the library base as the "data segment" of the code, so "global variables" (that's not exactly a C term, I know) appear in the library base. I'm unclear whether vbcc can do that, but gcc couldn't back then.
So it's much more a question of the overall tool chain than really some particular feature of the optimizer. SAS/C, even the latest version, has some bugs in its optimizer, too. Try to use mathieedoubbas mathematics and see it spill the lower 32 bits of the IEEE double floats from time to time... )-:
Anyhow, nothing's going to happen as far as the Kickstart is concerned, so it's all an academic discussion to begin with.
-
Back then had a good optimizer, compared to the other compiler(s) that were available, Manx (Aztec) namely. Gcc had an even better optimizer, but no (or unsufficient) native support for the Amiga toolchain, so it was often not an option to use.
That was what 20 years ago now?
I really haven't tried vbcc, so I cannot judge, but a lot of the compiles here depend on some SAS/C magic, for example layers depends on SAS/C being able to use the library base as the "data segment" of the code, so "global variables" (that's not exactly a C term, I know) appear in the library base. I'm unclear whether vbcc can do that, but gcc couldn't back then.
Vbcc uses the standard:
A7=stack pointer
A6=library base
A5=frame pointer (unused unless -use-framepointer)
A4=small data pointer (unused unless -sd)
Both A5 and A4 are free by default so there should be no conflicts. There is a function attribute called __saveds which loads A4 or a function called geta4() which can be placed at the start of a function using small data when not compiled for it. If A4 is used as the pointer to your library base, it may not take much to convert to compiling with vbcc. What SAS/C attributes and functions are used to setup and access the library base in this way?
Vbcc supports these attributes:
__far, __near, __chip, __saveds, __interrupt, __amigainterrupt, __stdargs, __section
So it's much more a question of the overall tool chain than really some particular feature of the optimizer. SAS/C, even the latest version, has some bugs in its optimizer, too. Try to use mathieedoubbas mathematics and see it spill the lower 32 bits of the IEEE double floats from time to time... )-:
Vbcc has bugs too but they are getting fixed :).
-
Please leave the icon.library out of Kickstart. Everybody is using PeterK's icon.library because it's much faster, smaller and supports most Amiga icon types.
Well, I'm not using it ;) So far I'm reasonably satisfied with the icon.library which I wrote for the OS 3.5 update. If there is a problem badly in need of a solution, it's in how workbench.library and icon.library interact for directory scanning and display. It just does not scale: larger icon files, more files, no matter what, the performance and responsiveness quickly goes down the drain.
SAS/C "refined and effective optimizations"? You have to be kidding.
Hey, I wrote "*more* refined and effective", and the reference was Lattice 'C' 5.04. SAS/C 6 was definitely an improvement considering the quality of the code optimization. However, it did take a couple of years to mature (1995-1996), by which time Commodore could no longer put it to good use.
I was told that Commodore was a driving force in getting SAS, Inc. to improve the code generator and the optimizer. They would submit samples of code as produced by the Green Hills compiler (obviously, they could not share compiler source code) and ask the compiler developers at SAS to replicate the results. Step by step the compiler improved.
The icon.library was compiled with SAS/C and PeterK's optimized version is now about 35% smaller with much added functionality (my record library reduction is 43% but that was an early version of GCC/EGCS which I could take to half size with some effort).
I can't comment on the size and functionality of the replacement icon.library, as I have never used it. I only spent a couple of months rewriting the icon.library from scratch, integrating NewIcons support, colour icon support, etc., making it work better with workbench.library, building new APIs, etc. The focus was not on optimizations for size or speed, because icon loading is pretty much restricted by what the file system can do (and that isn't much). My focus was more on making the whole thing as robust as I could, and on opening up the API.
I would say that SAS/C is better for size than speed. I have a working and well tested workbench.library which is 191168 bytes without any hand optimizations from me (it has bug fixes applied). I bet I could optimize away another 10kB or so with basic hand optimization (getting rid of that slow SAS/C copymem routine would probably save 500 bytes alone). Granted the code quality is nowhere near as bad as the intuiton.library. It might be worth trying vbcc for small executable sizes. Vbcc's features:
+ best 68k peephole optimizing assembler ever in vasm
+ uses optimized inlined assembler functions (the default)
+ sophisticated optimizations that exceed SAS/C (some don't seem to work)
+ cross-assembler for fast compiles on faster computers
+ good Amiga and 68k features and support (Amiga hunk output, IEEE math libraries for fp)
+ actively maintained by knowledgeable and helpful people who know the 68k and Amiga
+ source code available and compiles on a 68k Amiga with few dependencies
+ free for Amiga use
+ easy Amiga installation
+ good c99 support
? some of the link code is highly optimized (hit and miss)
- the 68k backend is average at best
- no 68k instruction scheduler
- lacking tools although many GCC and SAS/C tools are compatible (CPR debugger)
- slow at compiling
- memory hungry
- no C++ support
There should be a much improved version of vbcc out in the next few weeks. SAS/C is a dead end last decade compiler. How about giving the new version of vbcc a try?
Colour my curious. Where do I start?
The lack of an interactive source debugger is something of a dealbreaker, though. I'd hate to go back to where I was back in 1987. Life's too short for peppering your code with printf()s and assert()s, rerunning it, watching it crash, modifying it and rerunning it all over again. Now CodeProbe may not be much fun, but it's not that big a productivity sink as "old school" debugging is.
-
That was what 20 years ago now?
Yes, certainly - that's what I'm describing.
Vbcc uses the standard:
Sorry, that's not exactly what the problem is. The trick that is used here is the following: If you have a file like this:
struct Library *GfxBase;
void LIBFUNC foo(struct RastPort *rp)
{
SetAPen(rp,0);
}
then, with a properly defined LIBFUNC macro, SAS/C will place "GfxBase" as an object into the library you are creating (*not* the data segment), will create a library entry for "foo" and will use a6 to load a4 with the "near" data pointer, i.e. it will use the library base as "near" data. SAS/C can also create the fd file for your, or place the functions at specific offsets in the library.
As said, SAS/C provides a lot of system-specific "magic" to support AmigaOs development and a bit of the toolchain depends on this magic.
There are a couple of other "magical" support features it supports, so it does require some work to move from one compiler to another for system components. For user programs, this is much less an issue.
You don't even want to know how I compiled mathieesingtrans for 3.9 on SAS/C given that the compiler actually does not support single precision IEEE math...
-
Well, I'm not using it ;) So far I'm reasonably satisfied with the icon.library which I wrote for the OS 3.5 update. If there is a problem badly in need of a solution, it's in how workbench.library and icon.library interact for directory scanning and display. It just does not scale: larger icon files, more files, no matter what, the performance and responsiveness quickly goes down the drain.
I can't comment on the size and functionality of the replacement icon.library, as I have never used it. I only spent a couple of months rewriting the icon.library from scratch, integrating NewIcons support, colour icon support, etc., making it work better with workbench.library, building new APIs, etc. The focus was not on optimizations for size or speed, because icon loading is pretty much restricted by what the file system can do (and that isn't much). My focus was more on making the whole thing as robust as I could, and on opening up the API.
I appreciate that you are proud of your own work, and I'm not saying it's bad, but PeterK's icon.library really is significantly faster and it supports PNG and AmigaOS 4 icons as well as everything it did before while shrinking over 1/3. There is good and then there is amazing ;).
Hey, I wrote "*more* refined and effective", and the reference was Lattice 'C' 5.04. SAS/C 6 was definitely an improvement considering the quality of the code optimization. However, it did take a couple of years to mature (1995-1996), by which time Commodore could no longer put it to good use.
The guys that did SAS/C were professional, fixing a lot of bugs and giving a lot of Amiga support. The basic code generation was ok but they did some weird stuff like branching into CMP.L #imm,Dn instructions for little if any advantage and they loved the double memory indirect addressing modes like ([d16,An],od.w) which was used more with later versions (IBrowse has 1968 uses). These didn't hurt the 68020 code as much as for 68040 and 68060 where instruction scheduling is sorely needed. There are way too many byte and word operations for the 68060 which is most optimal with longword operations also. The direct FPU generation is poor for the 6888x and worse for the 68040+. It should be possible to generate good quality code for the 68020-68060, excluding the 16 bit 68000.
I was told that Commodore was a driving force in getting SAS, Inc. to improve the code generator and the optimizer. They would submit samples of code as produced by the Green Hills compiler (obviously, they could not share compiler source code) and ask the compiler developers at SAS to replicate the results. Step by step the compiler improved.
Looking at other compilers code generation is a good start. It's hard to imagine that Green Hills compiler was once better after looking at the intuition.library disaster. The Green Hills compiler is still around and pretty well respected in the embedded market for it's optimizing capabilities. They still have a ColdFire backend but I couldn't tell whether they had dropped 68k support.
Colour my curious. Where do I start?
The lack of an interactive source debugger is something of a dealbreaker, though. I'd hate to go back to where I was back in 1987. Life's too short for peppering your code with printf()s and assert()s, rerunning it, watching it crash, modifying it and rerunning it all over again. Now CodeProbe may not be much fun, but it's not that big a productivity sink as "old school" debugging is.
Frank Wille's vbcc site is here:
http://sun.hasenbraten.de/vbcc/
Unfortunately, the version there is pretty old now. There should be a new version available anytime (surely before the end of the year) with a huge number of bug fixes and improvements. You can always e-mail Frank for the newest sources also.
The newest version of vbcc for the Amiga 68k target generates Amiga symbols and debug information (with -g) in the Amiga Hunk format executables that is compatible with CodeProbe and BDebug. CodeProbe is a good debugger but I prefer BDebug from the Barfly package.
http://aminet.net/dev/asm/BarflyDisk2_00.lha
BDebug is another great developer tool you should try if you have not.
Sorry, that's not exactly what the problem is. The trick that is used here is the following: If you have a file like this:
struct Library *GfxBase;
void LIBFUNC foo(struct RastPort *rp)
{
SetAPen(rp,0);
}
then, with a properly defined LIBFUNC macro, SAS/C will place "GfxBase" as an object into the library you are creating (*not* the data segment), will create a library entry for "foo" and will use a6 to load a4 with the "near" data pointer, i.e. it will use the library base as "near" data. SAS/C can also create the fd file for your, or place the functions at specific offsets in the library.
Don't you mean the LIBFUNC macro causes the function to use A4 like a small data pointer to load A6 from GfxBase in the library base? What does the LIBFUNC macro look like?
As said, SAS/C provides a lot of system-specific "magic" to support AmigaOs development and a bit of the toolchain depends on this magic.
There are a couple of other "magical" support features it supports, so it does require some work to move from one compiler to another for system components. For user programs, this is much less an issue.
The C language did not specify much back then so every compiler had it's own customized features and pragmas. We have better C standards with C99 now that should be used where possible over custom compiler features. It's always a pain to convert the old stuff though. You should see the GCCisms that the AROS 68k build system uses and would need updated to compile with vbcc. It makes these problems look easy.
-
Relax, nobody is going to release a new kickstart anyhow, exactly due to the legal problems it would cause.
therefore i am trying to push for compiling aros kickstartt and eventually aros68k with vbcc, at least partly:
http://eab.abime.net/showthread.php?p=986550#post986550
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8929&forum=2
i will document the progress also here (for starters):
http://www.amigaforum.de/index.php?topic=42.msg216#new
please understand that this is an initoative of an noob, so it relays on experise of others, may take ages and lead to nowhere. but "learning by doing"
anyway any help is apreciated. i succesfully built a vbcc crosscompiler and am currently getting aros amiga-m68k target built regular way under gcc on ubuntu. one step at a time.
-
IThe basic code generation was ok but they did some weird stuff like branching into CMP.L #imm,Dn instructions for little if any advantage
That's what the peephole optimizer does, to avoid a branch around an instruction. Instead, this instruction is hiding in the data of the cmp.l# instruction. That's probably not an advantage on the 060 as it probably invalidates the branch-prediction cache, but it was at least a common optimization on even older microprocessors, like the 6502 (yes, really) where the BIT instruction served a similar purpose for avoiding "short branches".
There are way too many byte and word operations for the 68060 which is most optimal with longword operations also.
That rather depends on the source code. If the source uses a WORD, then what can the compiler do? There's an interesting interaction with the C language here I only mention for the curious (it doesn't make the compiler better or worse, it is just a feature that makes the time for the optimizer harder) and that is integer promotion. As soon as you have an operation with an integer literal (or any wider data type in general), it is first promoted to int. Thus, even something trivial like
short x = 2;
short y = x+1;
requires (as by language) first to widen the x to an int, then add one, then cast it down to a short. This is a trivial example where the optimizer will likely remove all the cruft of wideing and shorting, but there are more complicated examples like
if (x+1 == y)
which first widen x on the left, add the integer one, then y has to be widened, and then a full 32 bit comparison has to be made. And that's of course not the same as just adding a one to x in word since it differs in one single race condition, so all the widening cannot be optimized away. If I write that in assembler, and I know from other constraints that a wrap-around cannot happen (or I don't want to bother about for other reasons, who knows..) then I can do that of course much better by a single addq.w #1,dx, cmp.w. But its strictly speaking not correct, and not the same comparison.
In the end, it doesn't really matter much, unless you're in a tight loop somewhere in a computing-intense algorithm, and then you would probably look closer on what is actually happening there.
So, long story short: Some of the "seemingly useless" instructions are really there to follow the C language specs.
Looking at other compilers code generation is a good start. It's hard to imagine that Green Hills compiler was once better after looking at the intuition.library disaster.
It's not really a disaster. Greenhill haven't had registerized parameters, thus you see a lot of register ping-pong, but that's probably the only bad thing about it. Besides, it isn't heavy duty code to begin with.
Don't you mean the LIBFUNC macro causes the function to use A4 like a small data pointer to load A6 from GfxBase in the library base? What does the LIBFUNC macro look like?
LIBFUNC for SAS/C is just __saveds, i.e. requires the compiler to reload its NEAR data pointer, i.e. a4. Then there is another magic compiler switch that tells the compiler that the near data pointer comes actually from A6 plus an offset, where the offset depends on the size of the library base and whether there is any other magic that requires an offset from the library, to be determined at link time.
Thus, what the compiler essentially generates is a
lea NEAR(a6),a4
for __saveds in library code. Since NEAR is unknown until link time, the instruction remains in, even when the linker replaces the NEAR with zero. Which is the reason why you see some "seemingly useless" "lea 0(a6),a4) in layers, because the compiler could not possibly figure out that here NEAR=0, and at link time it is too late to remove that.
The C language did not specify much back then so every compiler had it's own customized features and pragmas. We have better C standards with C99 now that should be used where possible over custom compiler features.
Yes, but they don't have anything to say about library generation. A "shared library" is nothing C (or C99) has to say anything about, leave alone an Amiga shared library. So in one way or another, it requires some compiler support to build one, even nowadays. SAS/C offered a pretty good infrastructure for that, which is the reason why it is still what I use today. There's nohting in C99 to help you with that. The only other alternative would be to use a couple of assembler stubs (aka "register ping-pong") which is what happened for intuition. You didn't like that either. (-:
It's always a pain to convert the old stuff though. You should see the GCCisms that the AROS 68k build system uses and would need updated to compile with vbcc. It makes these problems look easy.
I have no doubt about that, but that's pretty much the reason why I'm reluctant to switch the compiler. These are code-generation problems I want to stay away from. I would reconsider if there would be the potential for a dramatic speedup or a dramatic size reduction when switching, but that doesn't look too likely.
-
That's what the peephole optimizer does, to avoid a branch around an instruction. Instead, this instruction is hiding in the data of the cmp.l# instruction. That's probably not an advantage on the 060 as it probably invalidates the branch-prediction cache, but it was at least a common optimization on even older microprocessors, like the 6502 (yes, really) where the BIT instruction served a similar purpose for avoiding "short branches".
I don't see other compilers like GCC or vbcc doing this trick. The 68020+ can hide code in a TRAPcc.W and TRAPcc.L instruction (TPF in ColdFire) as well to avoid a branch sometimes with an if-then-else (actually recommended and described in the ColdFirePRM). This technique can save a couple of cycles on the 68040 with it's large instruction fetch but it's not worth it on the 68020 and is usually slower on the 68060. It's not very friendly for debugging either.
That rather depends on the source code. If the source uses a WORD, then what can the compiler do? There's an interesting interaction with the C language here I only mention for the curious (it doesn't make the compiler better or worse, it is just a feature that makes the time for the optimizer harder) and that is integer promotion. As soon as you have an operation with an integer literal (or any wider data type in general), it is first promoted to int. Thus, even something trivial like
...
In the end, it doesn't really matter much, unless you're in a tight loop somewhere in a computing-intense algorithm, and then you would probably look closer on what is actually happening there.
Modern compilers will commonly promote shorter integer sizes to the register size, if there isn't too much overhead. Many superscalar processors like the 68060 have internal optimizations for and can only forward full register results. Unfortunately, the 68060 doesn't have the instructions it needs to make this happen efficiently like the MVS/MVZ ColdFire instructions and the MOVSX/MOVZX x86 instructions. I've been trying to get the ColdFire instructions (as encoded on the CF) into a new 68k like ISA for the new fpga processors coming out where most recently I have referred to them as SXT/ZXT (SXT replacing the EXT name which is still supported).
http://www.heywheel.com/matthey/Amiga/68kF_PRM.pdf
Promoting integers to the register size simplifies the backend also. Vbcc does this a lot and generates better 68060 code as a result with some cost to 68020 code speed and size (the 68040 handles the big instructions but is slowed some by extra instructions). GCC is somewhere in the middle between vbcc and SAS/C, trying to be smart about whether to promote registers or not.
It's not really a disaster. Greenhill haven't had registerized parameters, thus you see a lot of register ping-pong, but that's probably the only bad thing about it. Besides, it isn't heavy duty code to begin with.
It may not be a processor intensive library but it's one that could have a significant percentage of it's code optimized away. Register ping-pong usually isn't too bad but it can commonly result in register spilling which is bad. This compiler did a poor job of peephole optimizing also.
LIBFUNC for SAS/C is just __saveds, i.e. requires the compiler to reload its NEAR data pointer, i.e. a4. Then there is another magic compiler switch that tells the compiler that the near data pointer comes actually from A6 plus an offset, where the offset depends on the size of the library base and whether there is any other magic that requires an offset from the library, to be determined at link time.
Thus, what the compiler essentially generates is a
lea NEAR(a6),a4
for __saveds in library code. Since NEAR is unknown until link time, the instruction remains in, even when the linker replaces the NEAR with zero. Which is the reason why you see some "seemingly useless" "lea 0(a6),a4) in layers, because the compiler could not possibly figure out that here NEAR=0, and at link time it is too late to remove that.
Ok, so vbcc already has the __saveds attribute. It just needs a way to set the global data pointer in A4 to something besides what small data uses. It would be nice to add support for resident/pure executables that use global variables (in allocated memory) like SAS/C supports as this is also similar. I need to do some further research and investigating (I have the SAS/C manuals which are good). It may help if you could show how the custom data pointer is setup.
The "lea 0(a6),a4" may be difficult for the compiler to optimize but it's not a problem for a peephole optimizing assembler like vasm. There are only a few link code related optimizations that vasm can't make (where the section is unknown before linking) which are usually branches (JSR->BSR and JMP->BRA).
-
Modern compilers will commonly promote shorter integer sizes to the register size, if there isn't too much overhead. Many superscalar processors like the 68060 have internal optimizations for and can only forward full register results. Unfortunately, the 68060 doesn't have the instructions it needs to make this happen efficiently like the MVS/MVZ ColdFire instructions and the MOVSX/MOVZX x86 instructions. I've been trying to get the ColdFire instructions (as encoded on the CF) into a new 68k like ISA for the new fpga processors coming out where most recently I have referred to them as SXT/ZXT (SXT replacing the EXT name which is still supported).
That's pretty much what coldfire was about: Drop everything in the ISA what is not required for C, and arithmetic for words or bytes isn't. Instead, the move-and-extend came in, which are useful for reading unsigned words or bytes. It may not be a processor intensive library but it's one that could have a significant percentage of it's code optimized away. Register ping-pong usually isn't too bad but it can commonly result in register spilling which is bad. This compiler did a poor job of peephole optimizing also.
Maybe so. A recompile wouldn't hurt, but see above. It ain't going to happen. Ok, so vbcc already has the __saveds attribute. It just needs a way to set the global data pointer in A4 to something besides what small data uses. It would be nice to add support for resident/pure executables that use global variables (in allocated memory) like SAS/C supports as this is also similar. I need to do some further research and investigating (I have the SAS/C manuals which are good). It may help if you could show how the custom data pointer is setup.
It's basically set at the beginning of the __MERGED segment, or, if that grows larger than 32K, right in the middle so data can be accessed with positive or negative offsets. I don't think the manual states that, at least I don't remeber having it seen there. The trick for library code is that it is reloaded relative to the library base, and not relative to the __MERGED segment, so the data is allocated by exec when the library is created, allowing the lib to be placed in ROM. The "lea 0(a6),a4" may be difficult for the compiler to optimize but it's not a problem for a peephole optimizing assembler like vasm. There are only a few link code related optimizations that vasm can't make (where the section is unknown before linking) which are usually branches (JSR->BSR and JMP->BRA).
No, look, the lea __NEAR(a4),a6 is never seen by the assembler. The __NEAR section is generated by the linker (or not generated at all, in case of the library), and SLink is smart about to which point of the segment a4 will point, depending on how large the data is. Thus, in the end, __NEAR can be zero, or 0x8000, or some other value, if constant data is moved into the __MERGED segment that is addressed by absolute addresses rather than relative to a4. Thus, it is only the linker that knows what the symbol will be, and it is the linker that puts it in. For layers, the library base is so small that it is just put at the beginning and __NEAR remains zero, but when the linker puts in the zero offset, it is too late to patch up the code for a smaller move instruction as the linker would have to resolve all relative branches around such lea's. Which, of course, it cannot do since the references are simply lost at this point. The best it could do is to replace it by a move and a NOP, but that's not exactly an improvement either (in fact, it spills the pipeline).
-
@thor
if you think vbcc is lacking in comparison with sas/c it might be work to talk to phx personally. perhaps there is room for improvement. i have a feeling he is open for suggestions and it would be great to have an up to date compiler for amiga-m68k that is actively maintained and aware of system requirements, which apparently is not the simplest case when going with gcc.
-
I appreciate that you are proud of your own work, and I'm not saying it's bad, but PeterK's icon.library really is significantly faster and it supports PNG and AmigaOS 4 icons as well as everything it did before while shrinking over 1/3. There is good and then there is amazing ;).
I understand that PeterK's icon.library is written entirely in assembly language. Given the complexity of the whole design, warts and everything, that's nothing short of very impressive. Even the integrated PNG decoder is in fact integrated into the library code and not merely latched onto it. It appears that the library has been under constant development for almost four years now, and it shows.
Suffice it to say that spending four years on polishing an assembly language implementation of icon.library is the kind of luxury that few are able to afford, and which in the context of the OS 3.5 project would not have been an option.
The guys that did SAS/C were professional, fixing a lot of bugs and giving a lot of Amiga support. The basic code generation was ok but they did some weird stuff like branching into CMP.L #imm,Dn instructions for little if any advantage and they loved the double memory indirect addressing modes like ([d16,An],od.w) which was used more with later versions (IBrowse has 1968 uses). These didn't hurt the 68020 code as much as for 68040 and 68060 where instruction scheduling is sorely needed. There are way too many byte and word operations for the 68060 which is most optimal with longword operations also. The direct FPU generation is poor for the 6888x and worse for the 68040+. It should be possible to generate good quality code for the 68020-68060, excluding the 16 bit 68000.
It's possible that this development path was eventually taken. SAS, Inc. acquired the compiler so that it could more easily port their stochastic analysis package to more platforms and produce better quality ports. At the time the interest was less in making a better Amiga compiler, but in providing other 68k platforms (namely the Apple Macintosh) with the SAS flagship software.
As far as I know the Amiga compiler business did not actually make much money (probably lost money), but it became a convenient test bed for compiler development. At the time it's likely that there were more users of the SAS/C compiler for the Amiga than there were customers for the SAS software that was built using the same compiler technology. Commercial support for SAS/C ended long before the last patch for SAS/C was released for the Amiga, and it's possible that further enhancements to the code generation were made that never saw integration into SAS/C for the Amiga.
Looking at other compilers code generation is a good start. It's hard to imagine that Green Hills compiler was once better after looking at the intuition.library disaster. The Green Hills compiler is still around and pretty well respected in the embedded market for it's optimizing capabilities. They still have a ColdFire backend but I couldn't tell whether they had dropped 68k support.
As far as I know the Green Hills compiler (referred to as "metacc" in the slim "AmigaDOS developer's manual", ca. 1985) used to have a major advantage not just in performing data flow analysis, but also in generating code sequences, back in 1984/1985.
This was an optimizing 'C' compiler intended for use on Sun 2 / Sun 3 workstations, which was adapted so that it emitted Amiga compatible 68k assembly language source code (as an intermediate language). That source code was then translated using a 'C' language precursor version of the ancient "assem" assembler into object code format suitable for linking. Mind you, this was not an optimizing assembler, just a plain translator. All optimizations happened strictly within the 'C' compiler.
What exactly rubs you the wrong way with Intuition?
-
It's basically set at the beginning of the __MERGED segment, or, if that grows larger than 32K, right in the middle so data can be accessed with positive or negative offsets. I don't think the manual states that, at least I don't remeber having it seen there. The trick for library code is that it is reloaded relative to the library base, and not relative to the __MERGED segment, so the data is allocated by exec when the library is created, allowing the lib to be placed in ROM.
It looks like vlink for the 68k Amiga will use the value 0x7ffe (32766) for the small data __MERGED section offset unless overridden.
No, look, the lea __NEAR(a4),a6 is never seen by the assembler. The __NEAR section is generated by the linker (or not generated at all, in case of the library), and SLink is smart about to which point of the segment a4 will point, depending on how large the data is. Thus, in the end, __NEAR can be zero, or 0x8000, or some other value, if constant data is moved into the __MERGED segment that is addressed by absolute addresses rather than relative to a4. Thus, it is only the linker that knows what the symbol will be, and it is the linker that puts it in. For layers, the library base is so small that it is just put at the beginning and __NEAR remains zero, but when the linker puts in the zero offset, it is too late to patch up the code for a smaller move instruction as the linker would have to resolve all relative branches around such lea's. Which, of course, it cannot do since the references are simply lost at this point. The best it could do is to replace it by a move and a NOP, but that's not exactly an improvement either (in fact, it spills the pipeline).
I see what you mean about the lea __NEAR(a4),a6 optimization now. The symbol isn't evaluated until link time after the assembler. Vbcc does have cross-module optimizations (high optimization levels have bugs so I don't generally use more than -O2) which could take care of the JSR->BSR and JMP->BRA optimization I talked about earlier but it's highly doubtful it would be able to take care of symbols that are defined for the linker. Vbcc's 68k backend generated assembler code for loading the small data base looks like this.
xref t_LinkerDB
lea t_LinkerDB,a4
That's not going to work as the library base is dynamically allocated making it impossible to put a label (t_LinkerDB) there. I believe it would need a "MOVE.L custom_DB,a4" or similar. So much for my hopes of being able to use most of the small data handling. It looks like it would need some custom work in the backend to make it happen and it's tricky. Here are links to the vbcc 68k backend (machine.c) and startup.asm so you can have a look.
http://www.heywheel.com/matthey/Amiga/machine.c
http://www.heywheel.com/matthey/Amiga/startup.asm
Frank Wille can be e-mailed for the latest version of the vbcc sources.
if you think vbcc is lacking in comparison with sas/c it might be work to talk to phx personally. perhaps there is room for improvement. i have a feeling he is open for suggestions and it would be great to have an up to date compiler for amiga-m68k that is actively maintained and aware of system requirements, which apparently is not the simplest case when going with gcc.
If we could figure out what to do, we could make the changes and do the testing but Volker would need to look it over and ok it. The backend is complex enough that it's easy to have unintended consequences with changes.
This was an optimizing 'C' compiler intended for use on Sun 2 / Sun 3 workstations, which was adapted so that it emitted Amiga compatible 68k assembly language source code (as an intermediate language). That source code was then translated using a 'C' language precursor version of the ancient "assem" assembler into object code format suitable for linking. Mind you, this was not an optimizing assembler, just a plain translator. All optimizations happened strictly within the 'C' compiler.
What exactly rubs you the wrong way with Intuition?
There isn't anything wrong with how the Green Hill's compiler works but there are signs of lack of maturity in the compiler like this:
movea.w ($c,a3),a0 ; movea.w moves and then sign extends to a longword
move.l a0,d7 ; d7 is used later so this is needed
ext.l d7 ; Unnecessary instruction! We are already sign extended!
movea.l d7,a0 ; Unnecessary instruction! We are already sign extended!
Waste: 2 instructions, 4 bytes
movea.w ($1c,a0),a1 ; movea.w moves and then sign extends to a longword
move.l a1,d1 ; Unnecessary instruction! d1 is not used later!
ext.l d1 ; Unnecessary instruction! We are already sign extended!
movea.l d1,a1 ; Unnecessary instruction! We are already sign extended!
cmpa.l a3,a1
Waste: 3 instructions, 6 bytes, 1 scratch register
cmpi.l #$f3333334,d2
blt lab_1521c
cmpi.l #$f3333334,d2 ; Unnecessary big instruction! CC from first cmpi still valid
bne lab_1521c
Waste: 1 instruction, 6 bytes
divs.w #2,d0 ; could be asr.l #1,d0 as the remainder is unused
Waste: 2 bytes and a bunch of cycles
move.l d0,d0 ; funny or should we say scary way to do a tst.l
seq d0 ; the next 3 instructions could be replaced with and.l #1,d0
neg.b d0
ext.w d0 ; 68020 extb.l could replace next 2 instructions
ext.l d0
lea ($c,sp),sp
ext.l d0 ; Unnecessary instruction!
Waste: 3 instructions, 2 bytes
When I see MOVE.L Dn,Dn, I know the compiler has problems with it's register management. Compilers repeat the same mistakes of course. Add in all the function stubs because it can't do registerized function parameters and it's pretty ugly. It might be passable for a 68000 but for a 68020+ there are a lot of places that EXTB.L could be used, MOVE.L mem,mem instead of MOVE.B mem,mem and index register scaling in addressing modes.
-
It looks like vlink for the 68k Amiga will use the value 0x7ffe (32766) for the small data __MERGED section offset unless overridden.
Looks I got it almost right, it's been a long time. I had the impression that it also places a4 at the beginning of __MERGED when this is short enough. May also depend on some other options, for example whether constant data is moved into this section or remains in the text section. That's not going to work as the library base is dynamically allocated making it impossible to put a label (t_LinkerDB) there.
It would need a lea _DATA(a6),a4 here for libraries as the "bss-segment" is part of the library base, and the compiler generated library startup code would have taken care to copy the constant data to there. SAS has also a couple of additional options, as to give every program opening the library a new library base, if you configure it right. As said, there is a lot of magic happening here, also for "load and stay resident" programs, where SAS/C also provides a startup that copies the data segment into a private memory segment and relocates data from a private database of relocation offsets. I personally had never use for this, but it's just another example what the compiler was able to offer as a service and how well it was integrated into the system. As far as the quality of the compiled code goes, gcc 2.95 was ahead of SAS/C, but it was harder to use, even slower, and it was hard to use it for anyhting else but POSIX compliant C, i.e. integration was much worse. There isn't anything wrong with how the Green Hill's compiler works but there are signs of lack of maturity in the compiler like this...
Just a couple of short comments here: First of all, you're describing a set of low-level peephole optimizations the compiler misses. I don't have any experience with greenhill, but its not untypical that many optimizations happen at a higher level though code-flow analysis, e.g. leading to dead-code removal that do not short at instruction level. Thus, just from looking at the instruction level, you only get a very incomplete view on the compiler and its performance. What you rather see here is probably a lack of maturity of the code-generator, but that's only one out of many phases a compiler has to go through. That doesn't mean that the upper levels were any better, I just don't know. All I'm saying is that your judgement is a bit premature. In addition, allow me to fix a couple of your suggestions: First, divs #2,d0 is *not* equivalent to asr.w #1,d0. The former rounds to zero, the latter rounds to minus infinity. In specific (-1/2) = 0, but (-1 >> 1) = -1, so you cannot replace one without the other. Condition codes are also not equivalent. tst.l d0, seq d0 is also not equivalent to and.l #1,d0. move.l d0,d0 is probably untypical for a tst, but it would probably work completely alike, but it is indeed more likely that the code generator had a hickup here and did not notice that there was no need to generate the code in first place. Allow me to add that if you look nowadays at code gcc generates on x64 platforms you'll find that it generates considerably ugly assembler from your sources, with many code repetitions and jumps around labels etc. Still, the results show that the decisions made by the compiler were not that bad, its partially due to loop unrollment, and it also features a pretty good high-level code analysis that can shorten a lot of computations - but at a much higher level you would usually notice. Thus, it's not always that easy to see from the assembler what the compiler really intended, or what the original code should have been. That works for modern compilers, at least, only at the very low optimizer settings.
-
It would need a lea _DATA(a6),a4 here for libraries as the "bss-segment" is part of the library base, and the compiler generated library startup code would have taken care to copy the constant data to there. SAS has also a couple of additional options, as to give every program opening the library a new library base, if you configure it right. As said, there is a lot of magic happening here, also for "load and stay resident" programs, where SAS/C also provides a startup that copies the data segment into a private memory segment and relocates data from a private database of relocation offsets. I personally had never use for this, but it's just another example what the compiler was able to offer as a service and how well it was integrated into the system. As far as the quality of the compiled code goes, gcc 2.95 was ahead of SAS/C, but it was harder to use, even slower, and it was hard to use it for anyhting else but POSIX compliant C, i.e. integration was much worse.
I agree that it would be good to add support for several of the SAS/C custom data pointer features at the same time as the support needed will be similar. It would probably need to link with a custom startup as well as requiring changes in the 68k backend and some new options in vc (vbcc launch program). I still need to do some more research and I would probably need Frank's help. He wrote vlink so he knows the linker stuff like the back of his hand which could be very useful. If you looked at the source, it's complex but at least manageable unlike GCC. Jason McMullan tried to change some things in GCC for AROS and what follows are some of his comments.
Fix gcc to give diagnostics when it feels 'forced' to use a frame pointer, sufficient to allow a programmer to make the correct changes so that gcc would not make a frame pointer in that routine.
- This code is very convoluted and ugly. I tried this once, and ran away screaming.
Fix gcc to never need a frame pointer on m68k
- This may be impossible. reload1.c is an impenetrable morass of evil.
With vbcc we have friendly support help, manageable sources and the source is available. That's about as good as it gets.
Just a couple of short comments here: First of all, you're describing a set of low-level peephole optimizations the compiler misses.
I don't believe what I have described are peephole optimizations except for possibly the DIVS instruction (MOVE Dn,Dn -> TST Dn would be peephole but it's ridiculous enough that the best peephole assemblers don't look for it). Integer DIV by immediates can involve a complex algorithm that converts the DIV to a multiply by a magic number, shifts and adds. This is beyond a this for that low level substitution. GCC has been doing magic number integer DIV to MUL since the Amiga days but Motorola ignorantly took out an important tool for the multiply on the 68k by removing the 64 bit multiply. The other examples show that the compiler was not aware at times of the data types and sizes in it's registers and had issues with it's register management. These are serious issues that could potentially lead to a crash but it's bad enough that they cause poor quality code.
I don't have any experience with greenhill, but its not untypical that many optimizations happen at a higher level though code-flow analysis, e.g. leading to dead-code removal that do not short at instruction level. Thus, just from looking at the instruction level, you only get a very incomplete view on the compiler and its performance. What you rather see here is probably a lack of maturity of the code-generator, but that's only one out of many phases a compiler has to go through. That doesn't mean that the upper levels were any better, I just don't know. All I'm saying is that your judgement is a bit premature. In addition, allow me to fix a couple of your suggestions: First, divs #2,d0 is *not* equivalent to asr.w #1,d0. The former rounds to zero, the latter rounds to minus infinity. In specific (-1/2) = 0, but (-1 >> 1) = -1, so you cannot replace one without the other. Condition codes are also not equivalent.
DIVS.W is 32/16 so it is necessary to start with an ASR.L #1,D0. You are correct that a correction is necessary. Maybe something like this:
asr.l #1,d0
bcc.b .skip
addq.l #1,d0
.skip:
This is still a big savings over a hardware divide. This is normally not done by a peephole optimizer.
tst.l d0, seq d0 is also not equivalent to and.l #1,d0.
My point was that a Scc+NEG.B+EXT.W+EXT.L can be replaced by a Scc+AND.L#1 which is significantly faster on most 68k processors.
move.l d0,d0 is probably untypical for a tst, but it would probably work completely alike, but it is indeed more likely that the code generator had a hickup here and did not notice that there was no need to generate the code in first place. Allow me to add that if you look nowadays at code gcc generates on x64 platforms you'll find that it generates considerably ugly assembler from your sources, with many code repetitions and jumps around labels etc. Still, the results show that the decisions made by the compiler were not that bad, its partially due to loop unrollment, and it also features a pretty good high-level code analysis that can shorten a lot of computations - but at a much higher level you would usually notice. Thus, it's not always that easy to see from the assembler what the compiler really intended, or what the original code should have been. That works for modern compilers, at least, only at the very low optimizer settings.
Optimized code may be ugly, especially if it's big and increases complexity. I didn't give any marks for looks though, other than MOVE Dn,Dn remark. This code does not look particularly complex. It looks like it's mostly data movement with a lot of sign extensions, especially word->longword. It's too bad compilers haven't learned that this comes for free to an address register.
I did an ADis disassemble to a vasm reassemble with peephole optimizations and intuition.library went from 114536 to 107776 bytes for a savings of 6760 bytes or 5.90%. I would expect that compiling for the 68020 would save somewhere around that much again. I don't know if vbcc would do any better as it doesn't always generate the most optimized code yet either (vasm tries to clean it up but only safe peephole optimizations can be made). Vbcc wouldn't need the function stubs anymore so that could save more.
-
Did we go off topic?
-
Did we go off topic?
Pretty much so, but that's actually a pretty good discussion here and more fruitful than most others I've seen. Thus, if we can stay off-topic in that direction, I would appreciate it..
-
@thor
............ it would be great to have an up to date compiler for amiga-m68k that is actively maintained and aware of system requirements, which apparently is not the simplest case when going with gcc.
With the possibility of getting new accelerators for Commodore Amiga computers using an FPGA loaded with a Soft-Core 680x0 running at a speed equal to 400MHz or more, new programming tools for 68k coding would be a great thing to see created and maintained.
-
There isn't anything wrong with how the Green Hill's compiler works but there are signs of lack of maturity in the compiler like this:
...
When I see MOVE.L Dn,Dn, I know the compiler has problems with it's register management. Compilers repeat the same mistakes of course. Add in all the function stubs because it can't do registerized function parameters and it's pretty ugly. It might be passable for a 68000 but for a 68020+ there are a lot of places that EXTB.L could be used, MOVE.L mem,mem instead of MOVE.B mem,mem and index register scaling in addressing modes.
I think I understand your criticism. My experience with 68k assembly language could charmingly be described as "finding exceedingly clever ways not to use it", so I'm in not an expert in writing or optimizing it ;)
From what I gather, an optimizing assembler would have had difficulties improving upon the sequences the compiler emitted, because the relationships between the sign extension and the repetition thereof are not easy to spot.
Shuffling register contents around in order to avoid pushing them to the stack looks like a reasonable strategy in 1983's terms. This sort of thing only started to become a problem when it caused pipeline stalls, didn't it? For an 68010 or 68020, which would have been the targets of the compiler, it should have worked fine.
The compiler seems to be restricted to emitting 68000 code only, so no "extb.l" for you ;)
Given its age (the 68000 didn't become available until 1979, if I remember correctly, and the core of the compiler seems to date back to 1983), this still makes it a pretty good compiler which no doubt would continue to mature over the 1980'ies when the 68000 family saw widespread adoption, not just in desktop computers.
Aside from the ABI issues (function parameters passed on the stack), I would criticize the compiler for being obtuse in error reporting (at least, the logs which I saw are not particularly helpful). It's (of course) following K&R syntax rules with a few oddities included. For example, you could pass structures "by value", and the compiler would cleverly pack 'struct Point { SHORT x; SHORT y; }' into a 32 bit scalar value which would be passed on the stack. Problem is, Intuition *assumes* that the 'struct Point' parameter will be passed as a scalar value, and if you change compilers (say to SAS/C 6.50) then this assumption will no longer hold.
-
Pretty much so, but that's actually a pretty good discussion here and more fruitful than most others I've seen. Thus, if we can stay off-topic in that direction, I would appreciate it..
im all for it.
-
Updated kickstarts would be great too. In general, an AmigaOS "3.2" with all essencial bits updated to what is in 3.9+boing bags, things like shell, various libs, handlers and devices - a 3.9 without all the fluff (Reaction etc) from 3.5 and 3.9.
That wouldn't be great at all. ReAction is hardly "fluff", it's the official graphical interface for AmigaOS. If it was removed then most of Workbench would likewise cease to function (eg. Preferences), it's not some optional component.
-
@matthey
where do the jason quotes come from? its interesting in context of compiling aros with vbcc.
-
Shuffling register contents around in order to avoid pushing them to the stack looks like a reasonable strategy in 1983's terms. This sort of thing only started to become a problem when it caused pipeline stalls, didn't it? For an 68010 or 68020, which would have been the targets of the compiler, it should have worked fine.
Yes, except that the shuffle is here used to sign-extend a variable which is already sign-extended to begin with, so all the register-rearrangement is superfluous to begin with. It's (of course) following K&R syntax rules with a few oddities included. For example, you could pass structures "by value", and the compiler would cleverly pack 'struct Point { SHORT x; SHORT y; }' into a 32 bit scalar value which would be passed on the stack. Problem is, Intuition *assumes* that the 'struct Point' parameter will be passed as a scalar value, and if you change compilers (say to SAS/C 6.50) then this assumption will no longer hold.
Actually, if you follow ANSI C and would pass struct Point as a parameter, then it does require the compiler to pass this argument as a copy. I'm not sure what SAS/C does with that in this case, but it is not unreasonable to assume that it would simply copy it on the stack, too. In that case, the two options are pretty much equivalent: Whether the two members of the struct are on the stack because the compiler pushes them there as a single 32-bit longword due to the stack-based ABI, or whether it is on the stack because the compiler copied them there does not matter much. You probably cannot enforce the order on which they appear on the stack with Greenhill.
Anyhow, I wonder what actually depends on this. One thing that depends unfortunately on the stack-based ABI (but I don't remember whether it depends on struct Point) was Boopsis, which for that reason felt like an alien to the system, too (besides the other obvious one). The boopsi callbacks received parameters on the stack, unlike everything else where one would have probably used registerized parameters or a struct Hook * to call into the user functions.
-
im all for it.
My only concern is that with the thread title being what it is, this discussion will likely go unnoticed by others who either can benefit or have valuable contribution. Maybe it would be best to spin it off?
-
@loadwb
yes, right. assuming matthey, olsen and thor would agree this would be a good example of a case when moderator action might not only be justified but asked for, to move it to a new thread with a telling title. if so one of the involved might care to report themselves.
-
That WAS the point in my comment; when a completely separate topic pops up in a thread, it should be moved to its own thread.
-
That would, of course, require the assistance of a Moderator.
-
@matthey
where do the jason quotes come from? its interesting in context of compiling aros with vbcc.
From you :D.
http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler
@ThoR and Olsen
I read in the SAS/C manual about libinit, libinitr and the whole library building system interface. Some support by a compiler is necessary but this is a lot. Aminet has example library build systems that I need to research for vbcc (even GCC is supported). Maybe then I would be educated enough to talk to Frank Wille who has probably already been asked for more library support. I imagine it will take me a while (no hurry with current situation anyway) so I'm for letting the thread get back to topic. If it was possible, I think it would be good to have all the sources compiling with one compiler (but switchable to others if there is enough support) using a build system that could build everything or particular modules compiling for the 68000 or 68020 (with instruction scheduling for 68060 if possible). I don't see a need to abandon 68000 owners (includes fpga hardware with only 68000 support) and compiling for the 68020 is a nice space saver and extra performance for the larger AGA 68020 modules. It doesn't take much time to compile both and the size is plenty small enough to distribute on the internet. I have a feeling that there will be a time in the not so distant future when those sources are compiling again ;).
-
Yes, except that the shuffle is here used to sign-extend a variable which is already sign-extended to begin with, so all the register-rearrangement is superfluous to begin with.
Actually, if you follow ANSI C and would pass struct Point as a parameter, then it does require the compiler to pass this argument as a copy. I'm not sure what SAS/C does with that in this case, but it is not unreasonable to assume that it would simply copy it on the stack, too. In that case, the two options are pretty much equivalent: Whether the two members of the struct are on the stack because the compiler pushes them there as a single 32-bit longword due to the stack-based ABI, or whether it is on the stack because the compiler copied them there does not matter much. You probably cannot enforce the order on which they appear on the stack with Greenhill.
The problem with Intuition and its relationship with the Green Hills compiler is that Intuition depends upon the 'struct Point' to be passed as a scalar value.
I spent considerable time porting Intuition to use SAS/C, so that it could be built natively on an Amiga, and that's when I found how "fast and loose" Intuition plays with function parameter passing.
Given the quality of the code in general, I reckon it is not an accident or oversight how the K&R function and the call-back routines used in the state machine of Intuition treat their parameters. These must have been deliberate design choices.
Anyhow, I wonder what actually depends on this.
If I remember correctly (it's been a while), most of the operations which involve planar geometry (is this point within this area? do these areas overlap? scale this area to this size) use the packed 'struct Point', and Intuition uses these both in function parameters and in BOOPSI messages.
It's not as if these were the foundations upon which Intuition rests, but the use of this type of data structure is so pervasive that fixing up the code to make it less compiler implementation dependant will quickly get on your nerves.
One thing that depends unfortunately on the stack-based ABI (but I don't remember whether it depends on struct Point) was Boopsis, which for that reason felt like an alien to the system, too (besides the other obvious one).
I suppose this is true for every case of SmallTalk methods and practice transplanted to a different system (Objective-C comes to mind) ;)
The boopsi callbacks received parameters on the stack, unlike everything else where one would have probably used registerized parameters or a struct Hook * to call into the user functions.
That's the SmallTalk legacy. It could have been worse: imagine that these were TagItem lists, and how slow the parameter processing would have been.
-
That wouldn't be great at all. ReAction is hardly "fluff", it's the official graphical interface for AmigaOS. If it was removed then most of Workbench would likewise cease to function (eg. Preferences), it's not some optional component.
For me it is, I run 3.9 also without reaction, including 3.9 workbench. The prefs programs are really just glorified editors and can fairly easily be replaced.
-
For me it is, I run 3.9 also without reaction, including 3.9 workbench. The prefs programs are really just glorified editors and can fairly easily be replaced.
You are probably in the 1%. I don't think 99% of Amiga users would know how to rewrite their Preferences programs. What do you use? MUI? Shell scripts to change all your preferences? I can imagine that being a nightmare, haha. ;) Seems like a lot of work for very little reward.
-
For me it is, I run 3.9 also without reaction, including 3.9 workbench. The prefs programs are really just glorified editors and can fairly easily be replaced.
In most cases, there is no other equivalent to them that has the same functionality. Hand-editing the preferences files is not just a hassle, but also not a good idea as they are mostly undocumented.
Not just Preferences editors uses ReAction either but also HDToolbox, IconEdit, Exchange, etc.
Plus of course the fact that you would be unable to run lots of 3rd-party software.
All that just to save a few hundred kilobytes on your hard disk!? Seems like foolishness.
-
No - that to be able to run OS3.9 on 68000 systems, like for instance Minimig.