Quote:

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

They should all get a looooong vacation (holiday for those across the pond) once OS4 is finished!

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

We have "compatibility headers" which are able to compile OS3 source code without the need for changes. So in the first instance, you don't need to change your source code.

Of course, to make use of new features, you'll have to change the code. It's not possible to use old and new schemes in the same file (it's possible to compile one file with compatibility headers, and another one without).

Quote:

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)

Actually, it *is* illegal. Amiga.lib does it, yes, but that's also illegal. Hooks should be called by CallHookPkt, and the only reason they are called directly by amiga.lib is because of speed. Of course, it was time safed on the completely wrong end, because hook calling frequency is generally low compared to the time added by an additional function call.

So they gained effectively nothing. Unfortunately, we had to find a solution for that. That's one of the reasons OS4.0 already has the full virtual addressing. With this, we can quickly identify if a code pointer is 68k or PPC, and act accordingly...

Quote:

Pressure or what?

High pressure, yes.

Quote:

They should all get a looooong vacation (holiday for those across the pond) once OS4 is finished!

YES!!!!!!

Quote:

EntilZha wrote: Quote: They should all get a looooong vacation (holiday for those across the pond) once OS4 is finished! YES!!!!!!

Well, you definitely deserve it guys. I don't think anyone can doubt that.

Have one from me...

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

So in summary ( modules == AmigaOS modules ):

1. Modules that stay in 68k but make calls to modules that are now PPC do not need to be modified, addressability is managed under the covers and connection between modules is a function pointer. Visa-versa is also true.

2. ASM based modules in 68k that are ported to PPC will need to be grunt-ported to PPC. Work.

3. C based modules that are ported to PPC will/may hit the following difficulties if any:
3.a Compiler syntax and semantic differences.

4. Applications that access modules through a pragma style interface will just use the same way they did before.

5. Non AmigaOS applications ported to PPC will have to consider the usual porting suspects when coming from another platform:
5.a Are there any algorithms that rely on the byte order being little endian? If so either you will have to change the algorithm or transform the byte order on the fly or store the data in little endian.
5.b Are there any ISC components that use say sockets that do not use NBO for communication? If so you may have to translate the byte order on the fly.

Otherwise its just

gcc -g3 -o ....

all the way ( debug on for first time around please ) on a cross compiler.

Sweeeeet.

> all the way ( debug on for first time around please ) on a cross compiler.

I believe we should be getting a native GCC 2.95.3 and a GCC 3.2.x cross compiler for Linux (which one?).

I just saw GCC 3.3 was released yesterday with lots and lots of C++ bug fixes (yes, I like C++). Looks like a nice solid release for PowerPC targets as well. Let's hope we can create a native version of the GCC 3.x series soon to make life easier for the developers.

_________________
ExecSG Team Lead

Quote:

Actually, it *is* illegal. Amiga.lib does it, yes, but that's also illegal. Hooks should be called by CallHookPkt, and the only reason they are called directly by amiga.lib is because of speed. Of course, it was time safed on the completely wrong end, because hook calling frequency is generally low compared to the time added by an additional function call.

Well, looking at utility.library/CallHookPkt() it doesn't
suggest that calling hooks directly is illegal:

-->8--
Performs the callback standard defined by a Hook structure.
This function is really very simple; it effectively performs
a JMP to Hook->h_Entry.

It is probably just as well to do this operation in an
assembly language function linked in to your program, possibly
from a compiler supplied library or a builtin function.
-->8--

Beside, some extend hooks so that the functions
get automatically passed some more param (MUI
classes -> A0/A2/A1/A6. A6 = hook->h_Data ==
libbase for custom classes, IIRC). For convenience.
CallHookPkt() wouldn't work there if you wanted to
fix such code.

Quote:

So they gained effectively nothing. Unfortunately, we had to find a solution for that. That's one of the reasons OS4.0 already has the full virtual addressing. With this, we can quickly identify if a code pointer is 68k or PPC, and act accordingly...

Reserve a big chunk of virtual address space for loadseg'd
68k code?

@ Dave_P

Yes, it sums it up nicely :)

@ ssolie

We have a native 2.95.3 (with the very latest binutils), and a cross gcc 3.2. Of course, 3.3 is on my wish list... For now, 2.95.3 will have to do.

(I also like C++, btw )

Quote:

Well, looking at utility.library/CallHookPkt() it doesn't suggest that calling hooks directly is illegal:

It would seem so. However, I find it extremely braindead to supply a function and in it's documentation say something in the lines of "This function is useless". The programmer doesn't have to know what the function does. He only has to know that it's used to call a hook. In other words, he has to use the stupid function, and everything else is wrong.

Unfortunately, this is a stupid practice a lot of Amiga programmers think is OK to do. It isn't. Calling hooks directly is against the programmin guidelines. It's illegal code. As easy as that. You could with the same reasoning use Allocate() directly on an exec memory list. That's also common practice, and it's equally stupid.

This kind of thinking got us a lot of headaches in OS4. Sticking to the Allocate example, we had to provide for some faked memory list so that programs unsing Allocate directly wouldn't fail. The real memory lists are no longer kept where they used to be...

You should ask yourself: Why do you have something like a hook if you can just as well supply a simple function pointer ? A hook is an abstract function pointer. The stress is on abstract. This means that you have to keep your fingers off this.

Quote:

Beside, some extend hooks so that the functions

Hmm, extend ? It's called misuse. A hook is a hook as defined by the system. That means A0-A2 are preset with specific values. The rest of the registers have undefined values. Assuming anything else is going to get your task killed.

Quote:

Reserve a big chunk of virtual address space for loadseg'd68k code?

Actually, it's the other way round. There's a virtual segment for PPC code. The PPC can only grant execute permission on a per-segment basis. So one or more segments have execute permission.
Note, though, that virtual here means virtually addressed, not swapped out to disk. Code is never swapped.

OT, but I've got to say it's incredibly pleasant to read an OS4 thread which doesnt contain 90% trolling/flames!



A breath of fresh air - well done guys!

Ian

_________________
Life starts at 030, is fun at 040 and causes impotence at x86.