home *** CD-ROM | disk | FTP | other *** search
/ Magazyn Exec 5 / CD_Magazyn_EXEC_nr_5.iso / Programy / MorphOS / morphosuser-150201.lha / notes / wosemuppc.notes < prev   
Encoding:
Text File  |  2001-02-14  |  6.6 KB  |  170 lines
  1. wosemuppc.notes
  2.  
  3.  o 16.1011
  4.    - Fixed GetCPU(), it returned an invalid value
  5.  
  6.  o 16.1010
  7.    - Added native GetSysTimePPC
  8.    - some cleanup of these notes.. :)
  9.  
  10.  o 16.1009
  11.    - cleanup
  12.    - added to the module.rom
  13.      (Ralph)
  14.  
  15.  o 16.1008
  16.    - Noticed that cli command "stack" doesn't affect PPC stack. doh.
  17.      Now RunPPC() allocates a bigger stack if current one is smaller
  18.      than 2*68k stack. This fixed rest of h2 probs.
  19.  
  20.  o 16.1007
  21.    - Just some debug info to see if AMP134 calls Run68k with positive
  22.      library offset... 
  23.  
  24.  o 16.1006
  25.    - Big changes in mem system. MEMF_CHIP allocs are allocated from
  26.      task's tc_MemEntry, other allocs from task's pool.
  27.  
  28.    - FreeAllMem() not called in ppctask cleanup, but the mem will get
  29.      freed when 68k task quits (because of the above). 
  30.  
  31.  o 16.1005
  32.    - Run68K works now if called with no library base in A6.....
  33.  
  34.  o 16.1004
  35.    - Heretic2 works! It calls FreeVecPPC for mem allocated with
  36.      exec AllocVec.. added a workaround
  37.  
  38.    - FreeVecPPC now also works for mem allocated from other tasks. 
  39.  
  40.  o 16.1003      
  41.    - No longer runs in Forbid! 
  42.       
  43.    - RunPPC does a cache flush only first time it is run per process.
  44.  
  45.    - FreeVecPPC bug fixed.. 
  46.  
  47.  o 16.1002
  48.    - CreatePPCTask and AllocXMsg were broken, work now
  49.       
  50.    - Implemented RawDoFmtPPC
  51.  
  52.    - Implemented DeleteTaskPPC(NULL). Not possible to allow deleting of
  53.      other tasks, because our wos tasks are really processes.. ugh.
  54.         
  55.    - TaskIDs are now assigned properly. IDs below 1000 match the CLI
  56.      number, if available.
  57.         
  58.    - GetInfo now returns correct bus clock.
  59.  
  60.    - Run68K works with stack parameters now.
  61.       
  62.  o 16.1001
  63.    - Fixed recursive RunPPC problem. TableTennis works now.
  64.  
  65.    - Always run in Forbid(), even for gcc-compiled programs. Fixes
  66.      problems with shared wos libraries that trash r2 even if the program
  67.      doesn't.
  68.  
  69.    - All wosemu functions now preserve CTR.. Some WOS programs seem to
  70.      assume this, although CTR is specified as volatile in PowerOpen ABI!
  71.  
  72.    - Unsupported functions now pop up a requester.
  73.  
  74.    - CreateTaskPPC and CreatePPCTask implemented. 
  75.  
  76.  
  77.  o 16.1000 
  78.    - first alpha
  79.  
  80.  
  81. ----
  82. Some general notes about emu and warpos in general.. During the programming
  83. i found some annoyances in wos design, which i try to list here. This is
  84. not ment to be "wos bashing", just some things which warpos developers will
  85. face too if they ever plan to have 68k emulation and/or native OS. Also
  86. this could be interesting reading for all wos developers.
  87.  
  88.  - Memory system is weird.. If you have a shell and launch ppcprog1 which
  89.    allocates mem and doesn't release it, then run ppcprog2 which calls
  90.    FreeAllMem() also the memory allocated by ppcprog1 is freed. :) This
  91.    is duplicated in the emu.
  92.  
  93.  - First wos program launched in a shell allocates signals and never
  94.    releases them. This confuses for example WShell. Not emulated.
  95.  
  96.  - All internal structures are public! User shouldn't need to know about 
  97.    the internal new fields in msgport and semaphore structures... Luckily, 
  98.    most software seem to ignore them, so i just used the exec equivalents
  99.    without the extra fields.
  100.  
  101.  - Above is much worse with TaskPPC.. TaskPPC is an exec task with some
  102.    new fields appended. Sounds nice, but how can i call dos.library with a
  103.    task? Wosemu allocates TaskPPC for each warpos process, and tries to
  104.    keep that in sync with the real process struct.. Would be a lot easier
  105.    if we could just define struct TaskPPC == struct Process. I tried that
  106.    actually, it was quite ok but showtasks and similar programs show funny
  107.    values.. :) and taskid's are random. So it's not a very good solution,
  108.    but might be in the future when we have native dos.library..
  109.  
  110.  - According to wos history.txt, it is possible to signal a ppc task by
  111.    using exec/Signal().. What's the point in this? Now, if wos tasks were 
  112.    processes, this would work automatically, but with the current system
  113.    it requires an exec patch. Real wos does this patch, wosemu doesn't. No 
  114.    software seems to use it and imho it's dirty.
  115.  
  116.  - WOS is documented as using PowerOpen ABI, yet even some wos example
  117.    programs (WarpRace) violates this by expecting library functions to
  118.    preserve CTR register.. I had to add CTR store/restore to each library
  119.    function to make it work properly. Annoyance and unnecessary slowdown.
  120.  
  121.  - WarpOS allows user programs to enter supervisor mode and access MMU
  122.    tables. This is a big no-no in any modern os, and is not (can't be
  123.    and shouldn't be and won't be) emulated. Most software doesn't use
  124.    these anyway.
  125.  
  126.  - Run68k and RunPPC have way too many methods to pass arguments.. Float
  127.    arguments are almost never used, yet they take a lot of time to
  128.    initialize. Also stack arguments are useless, user can pass a pointer
  129.    to stack in some register if that's needed.. Currently, wosemu supports
  130.    all argument types in RunPPC, and only integer/stack in Run68k. I doubt
  131.    that ppc code calls 68k fpu code very often..
  132.  
  133.  - Run68k autodoc doesn't specify if you are supposed to initialize A6
  134.    or not, when calling OS functions. And of course some programs don't
  135.    initialize it. So I just copy the base to A6 before calling..
  136.  
  137.  - WOS gcc startup code relocates the code, then calls RunPPC. This is ok
  138.    in real wos because RunPPC always flushes all caches, but in wosemu
  139.    i had to add extra (unnecessary) cache flush there. That's why RunPPC
  140.    results in WarpRace are not so brilliant as you might expect.
  141.  
  142.  - WOS has some PPC library functions that are documented to preserve all
  143.    registers.. Weird stuff.
  144.  
  145.  - WOS has alignment emulation for FPU. PPC can only access longword
  146.    aligned memory when loading/storing float registers. If unaligned memory
  147.    is addressed, an "illegal alignment exception" is thrown. In warpos, the
  148.    exception handler then does the memory access, and returns back to the
  149.    program.. This gives the programmer the impression that everything is
  150.    working fine, which really isn't the case.. Emulated access is probably
  151.    over 100 times slower than regular mem access, so by simply fixing the 
  152.    alignment the program could be much faster. This is similar to using 
  153.    the 64bit math instructions in 060, they are emulated too and clever
  154.    programmers avoid them. 
  155.    Morphos currently doesn't have alignment emulation, so any program that
  156.    uses this will fail. Even in the future when alignment emulation
  157.    probably is implemented, it will still output a full debug dump so the
  158.    programmer can immediately notice that something is wrong.
  159.    So far, only program affected this is the "DeathTrial" demo by Mankind.
  160.    However, they have already created a fixed version.
  161.  
  162. -Zui (zu@iki.fi)
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.