Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

AuthorTopic: New Replacement Workbench 3.1 Disk Sets www.amigakit.com  (Read 925 times)

0 Members and 1 Guest are viewing this topic.

Offline wawrzon

Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #90 on: November 16, 2014, 01:20:51 PM »
@matthey
where do the jason quotes come from? its interesting in context of compiling aros with vbcc.
 

guest11527

  • Guest
Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #91 on: November 16, 2014, 01:57:52 PM »
Quote from: olsen;777608
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.  
Quote from: olsen;777608
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.
 

Offline LoadWB

Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #92 on: November 16, 2014, 02:50:37 PM »
Quote from: wawrzon;777609
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?
 

Offline wawrzon

Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #93 on: November 16, 2014, 04:30:50 PM »
@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.
 

Offline danbeaver

  • Lifetime Member
  • Hero Member
  • *****
  • Join Date: Mar 2012
  • Posts: 2454
  • Total likes: 0
Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #94 on: November 16, 2014, 04:39:49 PM »
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.
 

Offline danbeaver

  • Lifetime Member
  • Hero Member
  • *****
  • Join Date: Mar 2012
  • Posts: 2454
  • Total likes: 0
Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #95 on: November 16, 2014, 09:32:18 PM »
That would, of course, require the assistance of a Moderator.
 

Offline matthey

Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #96 on: November 16, 2014, 10:25:33 PM »
Quote from: wawrzon;777618
@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 ;).
 

Offline olsen

Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #97 on: November 17, 2014, 09:00:44 AM »
Quote from: Thomas Richter;777620
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.

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

Quote

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) ;)

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

Offline kolla

Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #98 on: December 07, 2014, 07:56:50 PM »
Quote from: Minuous;777616
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.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

Offline Oldsmobile_Mike

Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #99 on: December 07, 2014, 08:10:25 PM »
Quote from: kolla;779219
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.
Amiga 500: 2MB Chip|16MB Fast|30MHz 68030+68882|3.9|Indivision ECS|GVP A500HD+|Mechware card reader + 8GB CF|Cocolino|SCSI DVD-RAM
Amiga 2000: 2MB Chip|136MB Fast|50MHz 68060|3.9|Indivision ECS + GVP Spectrum|Mechware card reader + 8GB CF|AD516|X-Surf 100|RapidRoad|Cocolino|SCSI CD-RW
 Amiga videos and other misc. stuff at https://www.youtube.com/CompTechMike/videos
 

Offline Minuous

Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #100 on: December 07, 2014, 08:13:59 PM »
Quote from: kolla;779219
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.
« Last Edit: December 07, 2014, 08:17:13 PM by Minuous »
 

Offline kolla

Re: New Replacement Workbench 3.1 Disk Sets www.amigakit.com
« Reply #101 on: December 07, 2014, 08:19:52 PM »
No - that to be able to run OS3.9 on 68000 systems, like for instance Minimig.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS