Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
21 crawler(s) on-line.
 164 guest(s) on-line.
 1 member(s) on-line.


 Gunnar

You are an anonymous user.
Register Now!
 Gunnar:  3 mins ago
 OlafS25:  11 mins ago
 pixie:  12 mins ago
 Rob:  26 mins ago
 blmara:  51 mins ago
 miggymac:  1 hr 34 mins ago
 DiscreetFX:  4 hrs 2 mins ago
 DWolfman:  4 hrs 12 mins ago
 cncparts:  5 hrs 45 mins ago
 saipaman4366:  6 hrs 31 mins ago

/  Forum Index
   /  Amiga General Chat
      /  AmigaOS4 runs on MacMini
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 Next Page )
PosterThread
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 22-Jun-2008 15:32:21
#181 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@Turrican3

Quote:
That depends on our definition of Amiga and/or AmigaOS.


Amiga? An actual real machine made by Commodore. AmigaOS? And official incarnation of AmigaOS built from the actual AmigaOS source code. Usually OS3.1 in our case.

Amiga software? Software written for the Amiga computer and compatible with any machine running AmigaOS including modern versions.

Quote:
It is, indeed.
But we could leave that kind of -somewhat limited, one could say- use to UAE, and I think (I haven't been using it for a while, this feature might have been removed, even though it was quite useful) there's no problem in sharing data between the host OS and the emulated Amiga, since it can map directories and/or drives as native partitions.


One can use UAE, but it has to run in an old emulated environment, and drains resources. UAE is slow, it emulates the hardware, which might not be wanted. It's not as nice as running the actual programs under the new OS, they can get new breath of life.

Also, unless you have a native host 16-bit AHI driver, you won't be able to play 16-bit audio.

Drive sharing is still supported, though using directories can be incompatible. Even with OS4 I have found that UAE doesn't set the protection bits correctly under the emulation, so using a HDF image is still best. Drives are also slow, on OS4 I can't run software off the CD drive because it slows the emulation down so much. I have to copy to RAM first. Perhaps it is just OS4 UAE that has these issues, but it is a slower way of running legacy software then being emulated directly by the OS.

Quote:
It is difficult for me to answer: I guess (as I said before) that AROS lacks a lot of functionalities compared to OS4. But it is an unfair comparison IMHO, since OS4 is a commercial program/OS (albeit one with a *very* complicated development history due to lack of proper funding, basically) while AROS isn't.


I suppose OS4 is commercial to some extent. Though AFAIK it wasn't worked on full time. And AROS relies on programmers donating their efforts for the most part.


Quote:
But that's not the real issue, probably.

Problem is that AmigaOS (OS4) needs a completely different financial/development/etc. "context": there are far too question marks at the moment over its future, and we all know what I'm talking about.

AROS has none of those issues. It could (relatively) easily become more powerful than OS4, feature-wise. Problem is, at the current pace of development, it could take years, but hey, at least this has nothing to do with a certain soap-opera-like lawsuit.

(please note I'm not advocating AROS, actually I believe I've seen it running maybe just once or twice)


Yes, OS4 is looking a bit silly ATM, I wonder why we have any interest it it at all? OTOH, there is MorphOS, which IIRC took seven years to do. Similar to AROS, but had more people able to work on it in a more commercial sense.

Quote:
AmigaOS is an OS, nothing more, nothing less. It's the developers that decided which CPU it could run on. (more on this later)


They decided on the 68000. So anything made after for another CPU has to have things in common.

Quote:
No, because I would have bought an AmigaONE instead for that price.


Right! Which is what I did.

Quote:
Actually we don't need AROS to say that AmigaOS on x86 isn't possible.

Back in the 90's there was a time when Microsoft Windows NT ran on multiple platforms. It could run on x86 and... PowerPC too.

That's why I have difficulties in believing people saying "no to x86" for technical reasons, but as I said before: it's just my opinion, I don't want to change anybody's ideas.


Yes I remember NT PPC. It is possible, since NT was mostly an x86 OS, they made use the PowerPCs ability to address in little endian mode. It would have made the port easier.

There is also Linux, in both PPC and x86 (and other) flavours. So I wonder how they can compile for one or the other and have it work. Mac is now PPC and x86. And AROS can also run on a PPC as well as x86. AROS kind of acting like Linux that way.

But, looking at those examples, it's hard to say if the AmigaOS code can be easily ported to x86. Apart from being tied to the chipset, the Exec structures are also made for a 68K CPU. And other low level stuff. So Hyperion had to work those things out. Another thing is OS4 has I think 800 lines of assembly code. So I wonder, if they were trying to make it portable, why write in so much assembly? In it's current state it looks like even the OS4 source code would still need even more work to make it CPU generic.

Quote:
I don't know honestly. I'm just an old-time Amiga user, and I'd be extremely happy to see a reborn of the platform, I don't care if it's a niche, it's *still* my favourite OS and I just want it back.


 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 22-Jun-2008 15:36:01
#182 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@voyager2007

Quote:
That's right! There's really no reason not to run on x86. Especially with all the abundance of hardware and drivers.


Except we need the drivers as Amiga drivers.

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 22-Jun-2008 15:46:12
#183 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@tonyw

Quote:
It's precisely the abundance of hardware that makes it virtually impossible to support an X86 port. Any hardware that we support with a port (provided we can get programming data from the manufacturer) will be obsolete next year and unobtainable the next.


Yes, the AmigaOne was good when it came out. I could pick out from a list of supported graphic and sound cards.

But, things likes IDE cards or replacement USB cards or TV cards are a bit harder to track down. To a retailer these things are Windows hardware and and made to work with it. Supposedly guaranteed but not always. Now, what does a retailer know about what chipset is on what card? As far as he would be concerned, it works with Windows in a normal PC, that's all there is to know.

So, I think the same thing would happen as with the AmigaOne, access to cheap PC cards but which ones?

Case in point. I saw a cheap serial to USB converter for $22 today. Can it work with my Mac? The seller didn't know. There was no Mac logo on the box, so I walked away. Though I did wonder, can I hook the serial up to my A1200 and use it as a cheap USB? I guess the hardware wasn't designed to work that way.

 Status: Offline
Profile     Report this post  
Turrican3 
Re: AmigaOS4 runs on MacMini
Posted on 22-Jun-2008 16:12:05
#184 ]
Regular Member
Joined: 20-Jun-2003
Posts: 386
From: Italy

@Hypex
Quote:
Amiga? An actual real machine made by Commodore.

By this definition, even Escom-built A1200/A4000 aren't Amiga, not to mention Eyetech's AmigaONE...

Quote:
One can use UAE, but it has to run in an old emulated environment, and drains resources. UAE is slow, it emulates the hardware, which might not be wanted. It's not as nice as running the actual programs under the new OS, they can get new breath of life.

I don't know... you see, I can only justify the absolute need of (native) backward compatibility only as a temporary measure, just to be capable of running some obscure software not available on the new OS until a fresh new (hopefully more powerful) release has been written.

Quote:
I suppose OS4 is commercial to some extent.

Err no, not at all. OS4 is a fully commercial, proprietary OS product.

Quote:
Yes, OS4 is looking a bit silly ATM, I wonder why we have any interest it it at all?

I don't know about you, for me I guess it's the fond memories of the soooo many hours spent on my trusty A500 (and later A1200) that keep me hoping for a comeback.

Quote:
They decided on the 68000. So anything made after for another CPU has to have things in common.

Actually I was talking about OS4.

Quote:
Yes I remember NT PPC. It is possible, since NT was mostly an x86 OS, they made use the PowerPCs ability to address in little endian mode. It would have made the port easier.

Again, I don't know. But I guess that kind of issues are being handled by the Hardware Abstraction Layer (HAL, the name speaks for itself).

Quote:
Apart from being tied to the chipset, the Exec structures are also made for a 68K CPU. And other low level stuff. So Hyperion had to work those things out. Another thing is OS4 has I think 800 lines of assembly code. So I wonder, if they were trying to make it portable, why write in so much assembly? In it's current state it looks like even the OS4 source code would still need even more work to make it CPU generic.

I understand that OS4 is not tied to the Amiga chipset anymore. I also understand that it has a HAL, too, so it should *already* have a very good degree of CPU independency.

Of course this doesn't mean it will "automagically" run on any (different) HW on the planet, but if things were made the right way as I suspect, it shouldn't be THAT difficult to port it to other architectures, given a decent amount of resources: in our case, that means (well!) paid developers.

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 23-Jun-2008 4:25:16
#185 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@olegil

Quote:
Well, I've run Windows NT (not just the kernel, the whole NT 4.0) on one of my IBM PPC workstations, so porting just the kernel to the 360 should have taken them _several days_. Wow.


How about a version for the AmigaOne? Then I could run Windows on my A1 natively and demonstrate how Well Windows can run on the A1!

 Status: Offline
Profile     Report this post  
michalsc 
Re: AmigaOS4 runs on MacMini
Posted on 23-Jun-2008 5:42:45
#186 ]
AROS Core Developer
Joined: 14-Jun-2005
Posts: 377
From: Germany

@Hypex

Quote:
It is possible, since NT was mostly an x86 OS, they made use the PowerPCs ability to address in little endian mode.


Yes, they did.

Quote:
But, looking at those examples, it's hard to say if the AmigaOS code can be easily ported to x86.


It is easy. AmigaOS code is mostly C nowadays. C source file may be compiled to any architecture assuming there is a C compiler available.

Quote:
the Exec structures are also made for a 68K CPU


How do you mean they are made for 68k CPU?

Quote:
Another thing is OS4 has I think 800 lines of assembly code. So I wonder, if they were trying to make it portable, why write in so much assembly?


Try to write the prologue of exception handler for PPC architecture in pure C, without any CPU specific assembly. Try to read/modify PowerPC specific CPU registers without PPC assembly.

You can live completely without assembler in user space. You have to deal with it when you write an operating system, tough.

 Status: Offline
Profile     Report this post  
Hammer 
Re: AmigaOS4 runs on MacMini
Posted on 23-Jun-2008 10:47:21
#187 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5246
From: Australia

@olegil

Quote:

olegil wrote:
@Hammer

Well, I've run Windows NT (not just the kernel, the whole NT 4.0) on one of my IBM PPC workstations, so porting just the kernel to the 360 should have taken them _several days_. Wow.


The context was;
Quote:
Back in the 90's there was a time when Microsoft Windows NT ran on multiple platforms. It could run on x86 and... PowerPC too.

I then commented that MS continued the development and released a NT kernel variant for the POWER architecture.

In the middleware areas, both Windows XP/Vista and XBOX 360 runs Compact.NET/DirectX/XNA programs.

Last edited by Hammer on 23-Jun-2008 at 10:52 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

 Status: Offline
Profile     Report this post  
voyager2007 
Re: AmigaOS4 runs on MacMini
Posted on 23-Jun-2008 10:52:24
#188 ]
Regular Member
Joined: 5-Sep-2007
Posts: 432
From: Germany

@michalsc
Quote:
You have to deal with it when you write an operating system


Except, C was created as a language for implementing operating systems.

Quote:

void handle_exception( void ) {
auto int buf[0]; int a,b,c,d;
a = buf[-1]; /* return address */
b = buf[-2]; /* first item on stack before return address */
c = buf[-3];
d = buf[-4]; /* ... */
/* do stuff */
}




(Of course, emitting supervisor instructions either requires an inline-assembly feature or an __emit() function)

Quote:

void init_task( task_t* p ) {
__emit( 0X1234 ); /* symbolical instructions, the real ones would look differently */
__emit( 0X4321 );
}

 Status: Offline
Profile     Report this post  
Hammer 
Re: AmigaOS4 runs on MacMini
Posted on 23-Jun-2008 10:55:13
#189 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5246
From: Australia

@Hypex


Quote:
Also, unless you have a native host 16-bit AHI driver, you won't be able to play 16-bit audio.

WinUAE has 16bit AHI UAE driver.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

 Status: Offline
Profile     Report this post  
voyager2007 
Re: AmigaOS4 runs on MacMini
Posted on 23-Jun-2008 10:58:40
#190 ]
Regular Member
Joined: 5-Sep-2007
Posts: 432
From: Germany

@Hypex
Quote:
Except we need the drivers as Amiga drivers.

Task: Write a script or a program that translates a Linux driver to an Amiga driver.

 Status: Offline
Profile     Report this post  
michalsc 
Re: AmigaOS4 runs on MacMini
Posted on 23-Jun-2008 11:46:34
#191 ]
AROS Core Developer
Joined: 14-Jun-2005
Posts: 377
From: Germany

@voyager2007

Quote:
Except, C was created as a language for implementing operating systems.Except, C was created as a language for implementing operating systems.


But you still need some portion of assembly.

Quote:

void handle_exception( void ) {
auto int buf[0]; int a,b,c,d;
a = buf[-1]; /* return address */
b = buf[-2]; /* first item on stack before return address */
c = buf[-3];
d = buf[-4]; /* ... */
/* do stuff */
}


1. PowerPC uses link register to store return address
2. This function will destroy contents of scratch registers
3. This function will destroy CR register
4. This function will be unable to set up the supervisor stack pointer
5. On return, this function will issue blr (branch to link register) instead of rfi (return from interrupt).

Do you want to add something more?

Quote:
(Of course, emitting supervisor instructions either requires an inline-assembly feature or an __emit() function)


That's exactly what I wrote: "You can live completely without assembler in user space. You have to deal with it when you write an operating system, tough.". In my statement, the "deal with it" does not mean that you have to write everything in assembly. Far from it! You can trust me. I wrote the lowlevel core of AROS for x86, x86_64 and PPC and tried to eliminate as much assembly as possible. Yet, some tiny bits of assembly (either direct or intermixed with C) had to stay.

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 27-Jun-2008 4:07:23
#192 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@Turrican3

Quote:
By this definition, even Escom-built A1200/A4000 aren't Amiga, not to mention Eyetech's AmigaONE...


Did Escom really manufacture A1200 motherboards? They weren't old Commodore stock? If so I can't believe they would do that without changing the design.

There were also QuickPak A4000's weren't there? Okay, so now with nitpicking, should I say an Amiga engineered at Commodore?

I don't consider the AmigaOne to be an Amiga in the sense of being a real Amiga.

Quote:
I don't know... you see, I can only justify the absolute need of (native) backward compatibility only as a temporary measure, just to be capable of running some obscure software not available on the new OS until a fresh new (hopefully more powerful) release has been written.


If it gets written. There are also some older applications we just like. I have a friend who didn't purchase an AmigaOne for the very reason it didn't have AGA and all his old games wouldn't work. A modern PC runs Amiga games better than OS4!

But, with the point you make, the OS4 team felt the same. The basic emulator is built into Exec for 68k code such as drivers and also when OS4 wasn't fully PPC. Infact Rexx is still 68k. They integrated Petunia. They also put in WarpUP but only for a while, now it is worked on by a 3rd party. I was told time and again that they were only putting so much work into 68k compatibility. Even though they did put workarounds into functions to get around application bugs misusing APIs, but only so far.

OS4 has basic emulation of CIA left mouse and ignores chipset writes. But what I wanted was to be able to run 68k debuggers to see why rogue software breaks. But 68k trap code exceptions don't work, in MorphOS they work perfectly.

In future they intend to separate OS4 native and classic code, thus now having a "classic" OS4 environment with 68k in a sandbox along with the new Exec OS4 only. Reason being to have proper virtual memory, SMP support, 64-bit possibly and "unshared" memory spaces. I guess that will be ExecTG. Exec Third Generation?

Quote:
Err no, not at all. OS4 is a fully commercial, proprietary OS product.


What I meant was, it isn't commercial like Windows or OSX. You can't buy OS4 anywhere nor the hardware to run it. It isn't in the public eye. No one knows what it is! And by comparison OS4 wouldn't survive against the real commercial offerings. I hear talk about putting OS4 on small footprint devices, well, it's not even good enough for that. Even a cheap mobile phone has a web browser, media player and JAVA games. Well, we don't have a compliant web browser, fully working media player or JAVA. OS4 needs work before it can truly be called commercial IMHO.

That aside, a lot of 3rd party IT sites have recognised it as an official AmigaOS and the successor of OS3.x. So it does have that going for it.

Quote:
I don't know about you, for me I guess it's the fond memories of the soooo many hours spent on my trusty A500 (and later A1200) that keep me hoping for a comeback.


Yes, me too. In the meantime the AmigaOne kept my interest for a while. Right now I think machines like that are the only hope for AmigaOS. At least it was here, it came out, and there is still interest in it. Looks like it has carved out it's own Amiga niche for itself.

Quote:
Actually I was talking about OS4.


I thought you might. So in this case whatever CPU they use has to be compatible with the 68k to some extent. Remember they are porting the OS and not a copy and so in doing so they use the same system structures. The actual Exec library is designed around an MC68000 microprocessor that is not easily shaken off. There are interrupt vectors and all sorts of things. Not to mention 68k specific function calls. Some of these are used by the PPC, others have been extended on. But that is the base with which they worked with. Even address 4 still points to ExecBase under OS4! One could say then, well why not dump the old structures and reinvent them? That could be done, and it would have to be done as a fresh start, with only native applications and no legacy support. AROS is a good example of that. Although I haven't exactly looked into it, but I think even AROS uses fairly compatible AmigaOS structures. Or at least it does on an API software level.

But in the transition to another CPU the PowerPC was the most compatible with the AmigaOS structures. That and also the DEC Alpha I think.

Look at MorphOS which I think took seven years to make. And that was just re-implementing the AmigaOS 3.1 API to run on PowerPC. AROS essentially is doing the same thing on x86. So, I wonder, how does MOS and AROS compare? They should be similar. And also missing similar features. Last time I used MorphOS on a Pegasos machine I couldn't even find a simple text editor!

Quote:
Again, I don't know. But I guess that kind of issues are being handled by the Hardware Abstraction Layer (HAL, the name speaks for itself).


Interesting point. I remember the OS4 HAL being split into CPU, machine and common, IIRC. Now in that case, the CPU would have to handle the endian, since that is what it directly deals with. Machine in our case is Amiga or One. And whatever else those platforms have in common.

If the x86 could handle big endian as well like PPC then we might be using it right now. The 6502 was a little endian CPU so it could be said what the problem is. Of course the Amiga was no C64 clone!

Quote:
I understand that OS4 is not tied to the Amiga chipset anymore. I also understand that it has a HAL, too, so it should *already* have a very good degree of CPU independency.


Yes, they even got rid of the need for assembly and now everything can be done from a C compatible environment, including functions that once required an assembly routine. Now, they can use a C function or a default. For instance you can write an interrupt in C without any need for asm stubs. Simple.

OS4 makes use of the SystemV ABI (Application Binary Interface) which places arguments to functions in registers so that means a lot less stack is used. Intuition was written in C and all the 68k functions used to dump the arguments on the stack then call the real function. IMHO a lot less overhead with OS4, although volatile registers still have to be saved.

For x86 OS4 would need a whole new ABI, and since the register count is much less, it would have to go back to pushing arguments on the stack every time. Which is a worse case than 68k which had enough for arguments in registers. Of course, since x86 is fast, it won't matter that much if it isn't as neat.

Quote:
Of course this doesn't mean it will "automagically" run on any (different) HW on the planet, but if things were made the right way as I suspect, it shouldn't be THAT difficult to port it to other architectures, given a decent amount of resources: in our case, that means (well!) paid developers.


It would then end up like Linux I think. AmigaOS-PPC. AmigaOS-x86. Etc.

I've said this before and I'll say it again. AmigaOS4 and the AmigaOne brings AmigaOS closer to x86 than ever before!

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 27-Jun-2008 4:25:57
#193 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@michalsc

Quote:
Yes, they did.


So Microsoft do optimise their software! I wonder how it was done? Seems a bit hard with macros or assembler in-lines, PPC compiler option perhaps? That would make it easier.

Just ut of interest, IBM have their own emulation software for running x86 Linux software on the Power architecture.
http://www-128.ibm.com/developerworks/linux/lx86/

Quote:
It is easy. AmigaOS code is mostly C nowadays. C source file may be compiled to any architecture assuming there is a C compiler available.


Okay, so the source is easy. Is it easy as long as you stay source code compatible? Would it get hard beyond that?


Quote:
How do you mean they are made for 68k CPU?


Like I was saying to Turrican3, but also:

Quote:

struct ExecBase {
struct Library LibNode; /* Standard library node */

/******** Static System Variables ********/

UWORD SoftVer; /* kickstart release number (obs.) */
WORD LowMemChkSum; /* checksum of 68000 trap vectors */
ULONG ChkBase; /* system base pointer complement */
APTR ColdCapture; /* coldstart soft capture vector */
APTR CoolCapture; /* coolstart soft capture vector */
APTR WarmCapture; /* warmstart soft capture vector */
APTR SysStkUpper; /* system stack base (upper bound) */
APTR SysStkLower; /* top of system stack (lower bound) */
ULONG MaxLocMem; /* top of chip memory */
APTR DebugEntry; /* global debugger entry point */
APTR DebugData; /* global debugger data segment */
APTR AlertData; /* alert data segment */
APTR MaxExtMem; /* top of extended mem, or null if none */

UWORD ChkSum; /* for all of the above (minus 2) */


And to some extent:

Quote:
/* Processors and Co-processors: */
#define AFB_68010 0 /* also set for 68020 */
#define AFB_68020 1 /* also set for 68030 */
#define AFB_68030 2 /* also set for 68040 */
#define AFB_68040 3 /* also set for 68060 */
#define AFB_68881 4 /* also set for 68882 */
#define AFB_68882 5
#define AFB_FPU40 6 /* Set if 68040 FPU */
#define AFB_68060 7


...

Quote:
Try to write the prologue of exception handler for PPC architecture in pure C, without any CPU specific assembly. Try to read/modify PowerPC specific CPU registers without PPC assembly.

You can live completely without assembler in user space. You have to deal with it when you write an operating system, tough.


So the ABI you use can only do so much? Well I did understand that much, just that for an OS that was made closer to C, it just seemed to be a lot of lines for the basic primitive things needed in assembly.

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 27-Jun-2008 4:32:23
#194 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@Hammer

Quote:
WinUAE has 16bit AHI UAE driver.


Yes. EUAE does not. Thus OS4 EAUE does not. I see no reason for it not too. It emulates it as an interrupt from a device in expansion.library in the example code. So all it needs is to have the same expansion audio device added to EUAE and an associated AHI driver which should be the same as the WinUAE one as a 68k driver.

Last edited by Hypex on 27-Jun-2008 at 04:33 AM.

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 27-Jun-2008 4:37:17
#195 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@voyager2007

Quote:
Task: Write a script or a program that translates a Linux driver to an Amiga driver.


Write a script or a program you say. Well that sounds simple!

Actually, it can be done. The BetaScan drivers are based on SANE source code form Linux IIRC. And AHI uses a Linux based Emu10K driver. It acts as a wrapper for the Linux functions to do the low level stuff.

So, although it wouldn't be a pure Amiga driver, it would be possible infact to do this to some extent. Automating the process? I'm not sure about that.

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 27-Jun-2008 4:39:37
#196 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@michalsc

Quote:
I wrote the lowlevel core of AROS for x86, x86_64 and PPC and tried to eliminate as much assembly as possible. Yet, some tiny bits of assembly (either direct or intermixed with C) had to stay.


Okay, so how much? Did it differ between architectures?

Oh BTW, not much point making a PPC64 port now?

 Status: Offline
Profile     Report this post  
michalsc 
Re: AmigaOS4 runs on MacMini
Posted on 27-Jun-2008 6:27:23
#197 ]
AROS Core Developer
Joined: 14-Jun-2005
Posts: 377
From: Germany

@Hypex

Quote:
So Microsoft do optimise their software! I wonder how it was done? Seems a bit hard with macros or assembler in-lines, PPC compiler option perhaps? That would make it easier.


gcc compiler for PPC accepts option -mlittle (or -mlittle-endian) which has to be used if PPC code is going to run in little endian mode. Additionally, PPC may be put into little endian mode by setting one flag in MSR register.

Quote:
Okay, so the source is easy. Is it easy as long as you stay source code compatible?


Have a look at AROS software. Some of it had to be fixed to work on x86 architecture - mostly done by adding macros to convert endianess of some data. Some of AROS software was recompiled for x86 without change of a single line in the source code.

Quote:
Like I was saying to Turrican3, but also:

Quote:

struct ExecBase {...

[/quote]

Point for you. But, some of the fields may be reused on any architecture. Others have to stay unaffected and meaningless.

Quote:
it just seemed to be a lot of lines for the basic primitive things needed in assembly., it just seemed to be a lot of lines for the basic primitive things needed in assembly.


800 lines? It's not a lot. Compare it to hundred thousands of lines of architecture independent C code :)

 Status: Offline
Profile     Report this post  
michalsc 
Re: AmigaOS4 runs on MacMini
Posted on 27-Jun-2008 6:57:55
#198 ]
AROS Core Developer
Joined: 14-Jun-2005
Posts: 377
From: Germany

@Hypex

Quote:
Quote:

I wrote the lowlevel core of AROS for x86, x86_64 and PPC and tried to eliminate as much assembly as possible. Yet, some tiny bits of assembly (either direct or intermixed with C) had to stay.


Okay, so how much?


Let's have a look. The very first portion of AROS PPC kernel is written in assembly - it initializes the very basic MMU mapping (AROS kernel is mapped at 0xff800000 address), sets the stack, clears bss and such. It uses 26 PPC instructions.

Exception prologue on sam440 AROS port is a macro, 33 lines, expanded 16 times (for each exception entry one). Prologue calls the trampoline code which saves the rest of the CPU context and changes few bits in MSR - 34 lines. Return from exception restores the CPU context and returns back to user mode - 48 lines. The rest of exception handlers is in C.

Additionally, the exec.library/StackSwap is written in assembly. Additionally, few lines of the scheduler (and whole schedule chain of AROS) are in assembler, eg:

Quote:

__asm__ __volatile__("wrteei 0;");


They could be of course hidden in form of macros and/or volatile functions, like this example:

Quote:

/* Disable interrupts and let FPU work */
wrmsr((rdmsr() & ~(MSR_CE | MSR_EE | MSR_ME)) | MSR_FP);


There are some calls of this kind in AROS kernel, perhaps 100 or less... The userland code may use the C interface of AROS kernel, that is, calling functions of kernel.resource and exec.library.


x86_64 AROS is similar. A tiny startup code which prepares the stack and calls C entry, tiny portions of assembly in prologue of exceptions and interrupts entry/exit. StackSwap is, as in case of PPC, written in assembly. The biggest portion of asm code in case of x86_64 is the smp trampoline used to wake up the CPUs - beginning of this code is 16-bit assembly which turns on 32-bit mode, which sets up MMU and turns on 64-bit code, which calls C function :) The very rest of assembly is hidden behind inline functions and macros.

Quote:
Did it differ between architectures?


Yes, because of me :) The x86 core had much more assembly code in it. It was written in the old days, when I was still assembler freak. Now I grew up ;)

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmigaOS4 runs on MacMini
Posted on 30-Jun-2008 15:59:54
#199 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@michalsc

Quote:
gcc compiler for PPC accepts option -mlittle (or -mlittle-endian) which has to be used if PPC code is going to run in little endian mode. Additionally, PPC may be put into little endian mode by setting one flag in MSR register.


Okay, that's good, easy to do. I do wonder if this slows down the PPC internally.

Quote:
Have a look at AROS software. Some of it had to be fixed to work on x86 architecture - mostly done by adding macros to convert endianess of some data. Some of AROS software was recompiled for x86 without change of a single line in the source code.


So it doesn't look too hard. I wonder if C will ever move beyond needing macros for that sort of stuff and use a compiler option to automatically do it.

Quote:
Point for you. But, some of the fields may be reused on any architecture. Others have to stay unaffected and meaningless.


Sure. I suppose, without needing legacy support, you could infact remove everything not needed or used.

Unless, you port it to the ColdFire, then ExecBase is practically perfect!

Quote:
800 lines? It's not a lot. Compare it to hundred thousands of lines of architecture independent C code :)


By comparison, no. But, you want as much in C as possible, to be portable. So by itself that's a lot of lines. I consider C the "easy" bit.

Last edited by Hypex on 30-Jun-2008 at 04:01 PM.

 Status: Offline
Profile     Report this post  
michalsc 
Re: AmigaOS4 runs on MacMini
Posted on 30-Jun-2008 17:22:00
#200 ]
AROS Core Developer
Joined: 14-Jun-2005
Posts: 377
From: Germany

@Hypex

Quote:
Quote:

gcc compiler for PPC accepts option -mlittle (or -mlittle-endian) which has to be used if PPC code is going to run in little endian mode. Additionally, PPC may be put into little endian mode by setting one flag in MSR register.

Okay, that's good, easy to do. I do wonder if this slows down the PPC internally.


Accessing unaligned data is slower comparing to the PPC-native Big Endian mode.

Quote:
Quote:
800 lines? It's not a lot. Compare it to hundred thousands of lines of architecture independent C code :)

By comparison, no. But, you want as much in C as possible, to be portable. So by itself that's a lot of lines.


As I have already pointed it - you cannot have less assembly lines that easy. Besides, 800 lines of code is really just a bit. I took me much less than a month to have aros' exec running and multitasking on sam440. Keep in mind that I was not working full time on it: usually two or three hours every second or third evening.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle