I must be feeling very vocal this morning .
Anyway, after the unpteenth time of reading about the above on Ann/A.org I want to know why people are saying you can't just recompile the modules from 68k to PPC. I mean I'm not a C coder (at least not for a long time), but surely a lot of the work in porting a program from one platform to another is due to differences in compilers and/or differences in OS API's etc, if you are using the same developement evironment (gcc) the same OS (the modules are all going to work the same be they 68k or PPC) and no endian issues, surely it IS more or less a matter of recompiling with an extra flag set on the compiler or something. I mean there wasn't this fuss about recompiling between 68020 and 68060 just a different flag set. People recompile apps for different versions of UNIX all the time (linux/Solaris etc), surely if it's been written for portability (which Hyperion keep saying the modules have) in mind then converting from a 68k OS4 to a PPC OS4 is going ot be quite simple, especially if all of the PPC assembler is done (it appears to be if they are saying they can run 68k workbench on a PPC via emulation). So whilst I'll admit there probably will be a few problems, I fail to see why people are saying it's not as easy as a recompile, as far as I'm aware it very almost is. Please feel free to explain to me why this isn't the case, if it isn't. I really am interested to know why, this isn't meant as troll bait or the like by the way, I would genuinely like to know.

Mark

_________________
IceStar Media Ltd.

Yes, if you want to compile something for a new processor, it's usually not a big deal. The thing you have to worry about when you code is endianess. How the processor expects the numbers.. However, if you are aware of this, it won't be too hard a job.

99 times out of 100, taking opensource code for linux (coded for x86, little endian) and compiled on solaris (sparc architecture, big endian) works flawlessly.

Might be other things you have to worry about too, things I'm not aware of. But I dare say that about all the games Hyperion has converted to Amiga and Mac has come from the little endian world and entered the big endian world. They have seen this a couple of times now, and I'm pretty sure they know how to avoid the problems, and if bugs slips in anyway, they know how to find them.

_________________
If I started a site about cow dung, and someone wanted to discuss dog poo, I wouldn't give a ####.

Quote:

So whilst I'll admit there probably will be a few problems, I fail to see why people are saying it's not as easy as a recompile, as far as I'm aware it very almost is.

When the Friedens say it is nearly as easy as a recompile, I surely trust them a lot more then some pseudo-coders who don´t even put their names in their postings. I wouldn´t worry too much about this, as IMO the Friedens are two of the most talented coders we have for the Amiga and surely know what they are doing.

_________________
"I'd rather be vaguely right than precisely wrong."
- J.M.Keynes

If it is just modules they are recompiling I don't think they will have much of a problem.

After all, these modules would have been written so they could be easily compiled under both the 68k and PPC environment.

_________________
OS4.1 + SAM Flex
RIP my A1XE.. that used to have an appetite for batteries!

Sure, just porting modules will be fine. The tricky bit is in integration.

If module A is in 68k and module B is in PPC and A makes calls to B it has to do it through a function call that will be across a (pragma style) architectural boundary ( the emulator/real boundary ). Visa-vera is also the same. Now there isn't just the matter of making the pragma call, there is a problem of addressability across the boundary to handle. Referenced addresses and offsets from them ( e.g. the context of the execution thread ) must have meaning in both the PPC and the 68k thread.

This is AFAIR what they achieved in ExecSG and hopefully Petunia will cope.

A proper address space solution would be a technically superior achievement than a sandbox approach.

I am very impressed with the technical acumen of the AOS4 solution so far.

Recompiling C modules originally targeted for 68K to PPC is trivial. Both are big endian architectures (or more correctly bi-endian in the case of the PPC).

Most OS modules were already migrated from SAS C to GCC in the course of the OS 4 development.

The same doesn't hold when these modules are written in 68K ASM or when they contain parts written in 68K ASM.

A lot of the development work centered on reimplementing such modules (DOS, layers, timer.device are just three examples that come to mind).

The main challenge is not so much the recompilation as such but the seamless integration of 68K and PPC modules in the same whole with 68K modules calling on PPC modules and vice versa.

We spent the last few months on that and we're quite pleased with the results so far.

_________________

Quote:

The tricky bit is in integration.

Integration isn't that much of a deal, either

For one thing, both 68k and PowerPC are running in the same (albeit virtual) address space. There is nothing that the PowerPC can see that the 68k cannot see (speaking of 68k, I mean of course the emulator).

I remember being laughed at (by the usual "experts" which shall be left unnamed) when we said that calling PPC from 68k and vice versa will be handled transparently. As it stands now, it is. You can call Dos library from a PowerPC program as you call a PPC library, although DOS is still in 68k. When we move DOS to PowerPC, the same will still be true. Not even a recompile will be necessary.

The same applies to hooks. It doesn't even matter if you stuff a 68k pointer or a PPC pointer into a hook. Using CallHook will take care of that. You can even jump from one CPU to the other, although this will be slightly slowerdue to the exception.

Quote:

A proper address space solution would be a technically superior achievement than a sandbox approach

Yes, this is why we chose this way. It's harder, because things must fit more tightly, and the new Exec must carry over some "features" of the old. But as it stands now, the boundaries between 68k and PPC are virtually gone. This even applies to interrupt handlers which can be in 68k code.

@Rogue
Are we back to using amiga.lib (i.e. stubs) or can we use pragmas to call AmigaOS functions directly?

Perhaps FD2Pragma has been updated to produce PowerPC pragmas for AmigaOS 4.0 but I just don't know it yet.

@Mark
I would ignore anything said by anyone not working on AmigaOS 4.0 because they simply don't know. Unless they are porting code to AmigaOS 4.0 right now, they haven't a clue what is really involved. Myself included.

_________________
ExecSG Team Lead

Rogue wrote:

Quote:

You can call Dos library from a PowerPC program as you call a PPC library, although DOS is still in 68k. When we move DOS to PowerPC, the same will still be true.

I've been told in PPC you use different OpenLibrary() call than in 68k code? If so, why? =) If not, I apologize my wrong information :)

Quote:

The same applies to hooks. It doesn't even matter if you stuff a 68k pointer or a PPC pointer into a hook. Using CallHook will take care of that. You can even jump from one CPU to the other, although this will be slightly slowerdue to the exception.

What happens if the application (illegally) calls hook "by hand"? Does CallHook() use some trick and when it is not used can MMU detect 68k->PPC jump?

Quote:

I remember being laughed at (by the usual "experts" which shall be left unnamed) when we said that calling PPC from 68k and vice versa will be handled transparently. As it stands now, it is. You can call Dos library from a PowerPC program as you call a PPC library, although DOS is still in 68k. When we move DOS to PowerPC, the same will still be true. Not even a recompile will be necessary.

See now thats where I would have been laughing at the so called experts, because (maybe I'm being a bit naive) but in my view why should it matter what processor the code is running on, if a module runs on 68k and accepts parameter x in a certain format, and the same module running on ppc also accepts parameter x in the same format, why should it care whether it comes from a 68k module or a ppc module (as long as it returns values/output etc in a defined format of course). Just a simplified view I know but still......

Mark

_________________
IceStar Media Ltd.

> Are we back to using amiga.lib (i.e. stubs) or can we use
> pragmas to call AmigaOS functions directly?

Neither. You basically call each library function through a function pointer. There's no need anymore for any pragma or stubs because the libraries are now using a defined ABI (System V.4, with a slight variation for libraries, which is handled by the compiler internally).

> I've been told in PPC you use different OpenLibrary() call
> than in 68k code? If so, why? =) If not, I apologize my wrong
> information :)

No, that's wrong. You use the same OpenLibrary in both PPC and 68k (in fact, the 68k variant is just a jump from 68k into a PPC function).

The only difference is that you need to define which "jumpatble" you want to use. In Pre-OS4 libraries, jumptables where in front of the library base, and always fixed. We kept this for backward compatibility: 68k programs will find a 68k jump table where it always was.

PPC programs don't use this table. They use their own jump table (basically, a structure with function pointers). You have to specifically ask for this structure (or rely on the startup code to get it for you).

Of course, it would be completely braindead to use the same interface for the PPC, i.e have the PPC switch to emulation, execute the JMP instruction, and change back to PPC code. Therefore, the PPC uses it's own mechanics.

Quote:

n my view why should it matter what processor the code is running on, if a module runs on 68k and accepts parameter x in a certain format

Well, it's not that easy. The problem is that there is no ABI on 68k. Some functions use stack parameters, some use registers. Some use D0 for their first argument, some use D1.

However, the major point is that most calls between 68k and PPC are on well-defined boundaries: Libraries, Devices, Hooks, Interrupts and so on. Of these, libraries and devices are the most common part and the easiest to handle, since the 68k interface is a rigid jump table with fixed register mappings (per function), and the PPC side is using a different mechanism. In order to allow 68k to call PPC libraries, the 68k code needs to actually know the library, meaning that only things like intuition or exec are really affected, and these mimic the jump table of the old libraries and just escape to native code there.

> You basically call each library function through a function pointer.

Sounds like we need to do a bunch of search and replace to port code over to the new library API.

For example, from
#include "pragmas/intuition.h"
DisplayBeep();
to something like
IntuitionBase->DisplayBeep();

If true, I think that this will be much cleaner in the long run though but it will be a little painful. Hmmm. I betcha a guy could whip up a script to do this automagically...

_________________
ExecSG Team Lead

Quote:

What happens if the application (illegally) calls hook "by hand"?

Calling hooks directly cannot really be described as illegal,
IMO, considering amiga.lib itself does that, too (it
could theoritcally use utility.library/CallHookPkt(), but
the whole point of CallHook in amiga.lib, etc. is probably
that it doesn't require utility.library)Quote:

blub

Now this thread is more like it !!

I hardly understand a bloody word but its the

"meeting of minds for constructive comment" rather than

"Clashing of minds for destuctive (disruptive?) comment.

And it happened right here on AmigaWorld.net

_________________
******************************************
I dont suffer from Insanity - I enjoy it

******************************************

Calling hooks directly pretty much violates the reasoning behind it, but it doesn't pose a problem. Hooks that get called directly will be slightly slower because they'll hit an exception when they switch CPU's. Exec can find out if a code pointer is 68k or PPC, so using CallHookPkt in utility will find out without an exception and take appropriate measures.

Quote:

ssolie wrote: For example, from #include "pragmas/intuition.h" DisplayBeep(); to something like IntuitionBase->DisplayBeep(); If true, I think that this will be much cleaner in the long run though but it will be a little painful. Hmmm. I betcha a guy could whip up a script to do this automagically...

Actually, you don't have to do this. There are compatibility headers for all libraries that do a

#define DisplayBeep(screen) IIntuition->DisplayBeep(screen)

so you can still write DisplayBeep(NULL)...

In the long run, it's definitely better to fix the code, but for a first compile, it's not required. In fact, with a few points taken care you can compile the code out of the box. It mostly affects the opening of libraries.

Hey Hyperion guys,

I was just wondering... how does it feel to have this many people waiting with baited breath for you to finish your work?

Pressure or what?

_________________
www.amigaguru.com
www.dragons-fire.co.uk

Quote:

Pressure or what?

Pressure?? What pressure?