| From: | Paul Heams |
| Date: | 16 Feb 2001 at 18:47:01 |
| Subject: | Morph into Warp |
Hello All,
Well things on this mailing list appear a little quiet as of late. So I
thought I'd mail a copy of some notes I found about WarpOS emulation in
MorphOS. - Thats right, for those of you that don't already know the
latest version of MorphOS contains WOS emulation.
Unfortuantely, I was unable to test the emulation as the latest version
of MorphOS refuses to run on my machine (previous versions of MOS have run
without problems). So instead I looked through the "wosemulation" notes and
came accross the following which may be interesting for some (especially the
creators of WarpOS), and may also add a bit of discussion here:
Extract below taken from "wosemuppc.notes" in the latest MorphOS archive.
BFN,
Paul.
** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
Some general notes about emu and warpos in general.. During the programming
i found some annoyances in wos design, which i try to list here. This is
not ment to be "wos bashing", just some things which warpos developers will
face too if they ever plan to have 68k emulation and/or native OS. Also
this could be interesting reading for all wos developers.
- Memory system is weird.. If you have a shell and launch ppcprog1 which
allocates mem and doesn't release it, then run ppcprog2 which calls
FreeAllMem() also the memory allocated by ppcprog1 is freed. :) This
is duplicated in the emu.
- First wos program launched in a shell allocates signals and never
releases them. This confuses for example WShell. Not emulated.
- All internal structures are public! User shouldn't need to know about
the internal new fields in msgport and semaphore structures... Luckily,
most software seem to ignore them, so i just used the exec equivalents
without the extra fields.
- Above is much worse with TaskPPC.. TaskPPC is an exec task with some
new fields appended. Sounds nice, but how can i call dos.library with a
task? Wosemu allocates TaskPPC for each warpos process, and tries to
keep that in sync with the real process struct.. Would be a lot easier
if we could just define struct TaskPPC == struct Process. I tried that
actually, it was quite ok but showtasks and similar programs show funny
values.. :) and taskid's are random. So it's not a very good solution,
but might be in the future when we have native dos.library..
- According to wos history.txt, it is possible to signal a ppc task by
using exec/Signal().. What's the point in this? Now, if wos tasks were
processes, this would work automatically, but with the current system
it requires an exec patch. Real wos does this patch, wosemu doesn't. No
software seems to use it and imho it's dirty.
- WOS is documented as using PowerOpen ABI, yet even some wos example
programs (WarpRace) violates this by expecting library functions to
preserve CTR register.. I had to add CTR store/restore to each library
function to make it work properly. Annoyance and unnecessary slowdown.
- WarpOS allows user programs to enter supervisor mode and access MMU
tables. This is a big no-no in any modern os, and is not (can't be
and shouldn't be and won't be) emulated. Most software doesn't use
these anyway.
- Run68k and RunPPC have way too many methods to pass arguments.. Float
arguments are almost never used, yet they take a lot of time to
initialize. Also stack arguments are useless, user can pass a pointer
to stack in some register if that's needed.. Currently, wosemu supports
all argument types in RunPPC, and only integer/stack in Run68k. I doubt
that ppc code calls 68k fpu code very often..
- Run68k autodoc doesn't specify if you are supposed to initialize A6
or not, when calling OS functions. And of course some programs don't
initialize it. So I just copy the base to A6 before calling..
- WOS gcc startup code relocates the code, then calls RunPPC. This is ok
in real wos because RunPPC always flushes all caches, but in wosemu
i had to add extra (unnecessary) cache flush there. That's why RunPPC
results in WarpRace are not so brilliant as you might expect.
- WOS has some PPC library functions that are documented to preserve all
registers.. Weird stuff.
- WOS has alignment emulation for FPU. PPC can only access longword
aligned memory when loading/storing float registers. If unaligned memory
is addressed, an "illegal alignment exception" is thrown. In warpos, the
exception handler then does the memory access, and returns back to the
program.. This gives the programmer the impression that everything is
working fine, which really isn't the case.. Emulated access is probably
over 100 times slower than regular mem access, so by simply fixing the
alignment the program could be much faster. This is similar to using
the 64bit math instructions in 060, they are emulated too and clever
programmers avoid them.
Morphos currently doesn't have alignment emulation, so any program that
uses this will fail. Even in the future when alignment emulation
probably is implemented, it will still output a full debug dump so the
programmer can immediately notice that something is wrong.
So far, only program affected this is the "DeathTrial" demo by Mankind.
However, they have already created a fixed version.
** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **