port of modules to os3/os4/mos

kas1e
2013-05-17
2013-05-31
  • kas1e

    kas1e - 2013-05-17

    After i port one of modules to all builds (filetype.module) in case of checking what going wrong with those -1 crashes, and while for os4 it fix problems and for mos still not (but thats discussed in another thread), i assume that its time to port all modules in native form.

    At least it in end forced to be pretty easy for most of them, and so far i already port: about, cleanup, filetype and almost done with os3 build of ftp.module (the hardest one), and its just can't links now because of some mess with amitcp hardcore linking/redefining.

    I create a directory in our branch called "ported_modules", and upload there 3 working ones, and that ftp one which currently didn't links, but everything compiles.

    To build any of module just go to ported_module/module_name/ and type "make -f makefile.xxx" and it will builds.

     
    Last edit: kas1e 2013-05-17
  • xenic

    xenic - 2013-05-20

    @all
    I had a little time to try the module compiles. Since we're adding modules to compile it is getting a little inconvenient to change directories for each compile when you are compiling from a shell. I've added a makefile in the branch_v1 root directory to compile everything with a single command. From the branch_v1 root directory use commands like:
    make os4
    make os3 clean
    make mos library
    etc.

    I also added a makefile to the ported modules directory to compile all the modules with a single command. It currently only compiles the 3 modules you have completed but it will be easy to add more modules as they are ported. From the ported modules directory use commands like:
    make os3
    make mos about
    make os4 cleanup
    make os3 filetype clean
    make mos clean
    etc.

    Due to the age of the GeekGadgets makefile, it just reports a generic error if you enter 2 platform args at once (like: os3 mos). Newer makes will report more specific errors if you enter multiple platform args or no platform args at all.

    I also commited minor changes to some makefile.objs files because they had linefeeds or spaces that caused make errors. The real problem is the outdated GeekGadgets "make" command but the changes should not affect newer "make" programs for OS4 & MOS. Committed revision 395.

     
  • kas1e

    kas1e - 2013-05-21

    @all

    I for now restructure ported_modules stuff: now there is "generic_files" dir, where we have all what is the same for all modules. So it looks clean, and no double-work need it (except the ConfigOpus module, which have more functions , and libinit and co will be different for, but other 19 modules are the same in that terms).

    Commit 396 with all new stuff

    @xenic
    Imho we need just one single "make clean" for modules, as all the objects in modules the same, + just rm -rf all *.o from generic_files directory. Its a bit harder to just remove everything when you just want to build something from scratch, so while for build its ok to have os3/os4/mos args, for clean imho there should be none and all will be easy and fast.

    I currently add line to delete objects from generic_files to root's makefile, but will be handy to make just one single make clean which will remove all the stuff and does not matter for what builds it was done.

    There is also something interesting happens with os4 modules, for example if i build about.module for os4 and use it as it: all is ok. If only i strip it via "ppc-amigaos-strip about.module", then dopus5 by some reasson fallback on some other "about" window, like about.module stop working or so .. Maybe some alignment issues again, dunno..

    And we also need to solve way of how we compile all the modules now with generic_files. Because some generic_files (like lsprinf.c and libinit.c) include specific to every module .h, so, for every new module to build, we need to delete previous *.o from generic files and build them again.

     
    Last edit: kas1e 2013-05-21
  • kas1e

    kas1e - 2013-05-21

    @all
    I also port diskinfo.module now, but it crashes when want to do "math" calculation. As i see in sasc makefile, there is how it builds:

    diskinfo.o: diskinfo.c
        sc $*.c math=ffp globalsymboltable=sas6:include30ffp.gst
    

    So it uses some math options, because of which something changes and it works. I am sure its something like -fmathbalbal i need to add to gcc build, just dunno what one exactly.

    More of it, when i tryed to build aos4 version of it, i have:

     error: #error mathffp.library and mathtrans.library are not supported on AmigaOS4
    

    Seems we need to get rid of them somehow or so.. And besides, that diskinfo.module was wrong by calculation anyway as i can see with original module.

    Functions which we need from math/mathtrace are:
    SPFlt, SPSub, SPFix, SPMul, SPDiv and SPSincos.

    I commit now (#398) diskinfo module code to ported_modules. Os3 version compiles fine, but crashes when it come to show graph in a window, and os4 version cry about those funcs from old math libs. So we need to get rid of them and it all should be ok for everything. All the related code in the diskinfo.c itself.

     
    Last edit: kas1e 2013-05-21
  • kas1e

    kas1e - 2013-05-21

    @all
    For diskinfo.module Thomas just help with stubs:

    float SPFlt(int inum) 
    { 
    return (inum); 
    } 
    
    int SPFix(float fnum) 
    { 
    return (fnum); 
    } 
    
    float SPSub(float fnum1, float fnum2) 
    { 
    return (fnum1 - fnum2); 
    } 
    
    float SPMul(float fnum1, float fnum2) 
    { 
    return (fnum1 * fnum2); 
    } 
    
    float SPDiv(float fnum1, float fnum2) 
    { 
    return (fnum1 / fnum2); 
    } 
    
    float SPSincos(float *pfnum2, float fnum1) 
    { 
    *pfnum2 = cos(fnum1);
    return (sin(fnum1)); 
    }
    

    Tested, all works. Through still can't get logic of how it shows graph even in original version. Its just sometime fill whole color-wheel by just one single color while there is different should be.

    Also i want to remove all those deps on mathtrans from all builds, not only from os4, but have some problems with os3 build when do linking (it want sin()/cos() which seems not avail in 68k gcc without those -lm which want mathtrans in end).

     
    Last edit: kas1e 2013-05-21
  • xenic

    xenic - 2013-05-21

    @kas1e
    I added some makefiles to simplify compiling Dopus5 and then you make it more complicated by adding this generic stuff. The files aren't "generic" if they need to be recompiled for every module.

     
    Last edit: xenic 2014-07-01
  • kas1e

    kas1e - 2013-05-21

    @xenic
    they generic,just i didnt finish everything. anyway, makefiles is no problems to be honest, bugs which still left are )

     
  • Ilkka Lehtoranta

    Also i want to remove all those deps on mathtrans from all builds, not only from os4, but have some problems with os3 build when do linking (it want sin()/cos() which seems not avail in 68k gcc without those -lm which want mathtrans in end).
    

    We could open math libraries manually in OS3 builds and use it directly. So we need two paths: one for CPUs with FPU (can be also 68k if correct flags are enabled) and another for 68k only using math libraries from the OS.

     
  • kas1e

    kas1e - 2013-05-21

    @ikka
    sounds like a mess ) why we need it at all if it all in c libs already..

    For now i fix everything in that module with help of thomas/salas00 : all functions replaced, and everything works (and os3, and os4 versions). For morphos just need to deal with alignment crap in one structure. It all works even better in compare with how original sasc module works on os4: its all was wrong (maybe those math libs on os4 suck some omiga1200, dunno). But for now everything right and as should be.

    I commit #399 with changes (also some fixes in commit #405/#406).

    There is thread with all details about:
    http://www.amigans.net/modules/xforum/viewtopic.php?topic_id=5936&forum=25

     
    Last edit: kas1e 2013-05-22
  • kas1e

    kas1e - 2013-05-22

    @all

    commit #400:

    ported diskcopy.module to all os3/os4/mos. works the same as original (because didn't have all those callbacks, alignment and co). through i not so understand how it supposed to works at all, as it allow me to only copy disk to the same disk even with original version, but that all we can investigate later.

    commit #401:

    ported fixicons.module to os3/os4 (for mos need to deal with __alignment crap, same as for os4 i assume anyway, just currently i use some ugly redefine from library). Not tested, as dunno how and where that module involved.

    commit #402:

    ported format.module to all builds. tested them all, seems to works ok with native libs/etc. have no callback or __alignment inside, so all should be fine.

    commit #403:

    ported icon.module to os4. for morphos need to take care about alignment in the icon_data.c at end. for os3 need to take care about WB_LaunchNotify(): it is inline with macro LP8A4, and by some reassons again fail. so for os3 need to rewrite that function on asm again.

    os4 buld not tested , as dunno how to do that.

    commit #404:

    ported join.module to os3/os4. not tested as dunno how and where it used in dopus5. for morphos need to take care for __alignment issues in the join.c

    commit #407

    ported listerformat.module to os3/os4/mos. Seems all works fine.

     
    Last edit: kas1e 2013-05-22
  • kas1e

    kas1e - 2013-05-23

    commit #408:

    misc.module and pathformat.module ported. not tested , as dunno where they involved. misc.module even didn't opens from dopus5 at all as far as i can see.

    Also in that commit i made fixes in ftp.module as well which allow now to build os4 native version. Its now just crashes when i even try to open "addressbook", so that all need fixing. Os3 version fails to build as it do not know all those send, connect, etc without ixemulbase, so i assume we will need there some inlines for or so.. For morphos need to deal with __alignment again. So firstly we need to make os4/mos versions works , and then we can worry about bsdsocket inlines for os3.

    commit #409:

    ported play.module to all builds: os3/os4/mos. Not tested.

    commit #410:

    print.module ported for all builds. can't test all functional, but config-print-window opens fine, so should works same as original.

    commit #411:

    read.module ported to os3/os4. tested, all works. for morphos needs deals with __alignment

    commit #413:

    register.module, show.module and themes.module ported.

    register.module: ported to os3/os4 - not tested. for morphos need to deal with __alignment

    show.module: ported to os3/os4/mos - not tested

    themes.module: ported to os3/os4 - not tested, mos need to deal with __alignment.

    commit #414-418

    ported configopus.module to os3

     
    Last edit: kas1e 2013-05-24
  • kas1e

    kas1e - 2013-05-24

    @All

    Massive commit #421, + small fix in #422

    In which:

    1. restructured ported_module once again: removed that general_files directory, and put all files related to init of library to "init" dir in root of all modules. That should be done like this because some modules still make some objects different, some modules just different at all and what is most important it all will now looks clean and logical. I hope it is last time when i restructure it, so makefiles will works.

    2. update xenic's makefile in root of ported_modules to build them all. Still, for "clean" option need to add deleting of all objects in the "init" dirs in module dirs.

    3. add pragmapacks2 for every struct in every single .h file in all modules.

    4. add to "amiga.h" the same allignment define for morphos as for os4 , so modules also compiles (we will see if we need to fix anything in that terms later).

    5. many small fixes there and there.

    In end of all what we have now:

    os3 : 18 modules builds, 2 fail (ftp.module because needs bsdsocket inlines for linking, and icon.module because it use some functions with LP8A4 which fail).

    os4: all modules builds and links.

    mos: 19 modules builds, 1 fail (ftp.module can't compile all objects)

     
    Last edit: kas1e 2013-05-24
  • xenic

    xenic - 2013-05-24

    @kas1e
    The reorganization was a good idea. Here is why:
    There is a dev kit for the modules so that programmers can write additional modules for Dopus5. A programmer can write code with "UserLibInit" and "UserLibCleanup" like the original dopus5.library before we combined init.c and libinit.c. Then he links it with module "init" files provided by the dev kit or dopus5 distribution. In order to retain the capability for other programmers to write new modules we will need to have a common set of module initialization files that don't need to be recompiled for for each module and that we can compile into a GCC link file (like modules.a) for programmers to link with their new modules.

    We will probably need to split the current libinit.c file back into a libinit.c and init.c so that we can create a common module intitialization file for developers to link against for new modules. Afer all porting is done and bugs fixed we can split out the common init code from the files in the "init" directories one module at a time until they are all done. So, for now porting and fixing can continue without the previous "generic" directory and files getting so complicated with cross-calls to the actual module code. All the cross calls would make it extremely difficult to make a "common" main module initialization that could be used by outside developers.

    For the next week I will not have access to an Amiga but after that I'll look at all the makefiles. If you really need to fix the "clean" for the modules, we shouldn't add anything that affects individual files to the "main" makefiles. Just change the "$(REMOVE) *.o" in each module makefile to "$(REMOVE) $(OBJS)" or in the case of MOS makefiles change "@$(REMOVE) *.db *.map *.o"
    to "@$(REMOVE) *.db *.map $(OBJS)".

     
  • kas1e

    kas1e - 2013-05-25

    @Xenic

    If you really need to fix the "clean" for the modules, we shouldn't add anything that affects individual files to the "main" makefiles. Just change the "$(REMOVE) .o" in each module makefile to "$(REMOVE) $(OBJS)" or in the case of MOS makefiles change "@$(REMOVE) .db .map .o" to "@$(REMOVE) .db .map $(OBJS)".

    Done! Commit #426

     
  • kas1e

    kas1e - 2013-05-28

    @all
    Now, when all models more or less ported, bug-hunting time.

    For first, easy one, but i didn't get how to fix it (seems all about callbacks and ABI anyway).

    So, it is register module: https://sourceforge.net/p/dopus5allamigas/code/HEAD/tree/branches/branch_v1/ported_modules/register_module/register.c

    When build it for os3, it works fine. When build it for ppc it just crashes like this:

    Stack trace:
    (0x659DCAC0) rego_callback_2()+0x0 (section 7 @ 0x4B1C)
    (0x659DCCA0) [register.c:63] L_Module_Entry()+0xd0 (section 1 @ 0x15F8)
    (0x659DCCB0) [main.c:988] startup_check_registration()+0xbc (section 1 @ 0x4268)
    (0x659DCCD0) [main.c:80] main()+0x88 (section 1 @ 0x77E4)
    (0x659DCD00) native kernel module newlib.library.kmod+0x000020a4
    (0x659DCD70) native kernel module newlib.library.kmod+0x00002d54
    (0x659DCF10) native kernel module newlib.library.kmod+0x00002ee8
    (0x659DCF50) _start()+0x170 (section 1 @ 0x16C)
    (0x659DCF90) native kernel module dos.library.kmod+0x00023434
    (0x659DCFC0) native kernel module kernel+0x0006ac70
    (0x659DCFD0) native kernel module kernel+0x0006acf0
    

    And one of registers have "DEADBEEF", dunno through if it related to anything.

    I tryed to swap for callback ax registers so to make it as ABI want : a0/a2/a1 , but that didn't helps.

    Seems its something like ikka do in library, REF_CALLBACK or so ..

     
  • Ilkka Lehtoranta

    Yes you must call those pointers using 68k emulation routine.

     
  • kas1e

    kas1e - 2013-05-29

    @ikka

    Yes you must call those pointers using 68k emulation routine.

    Why ? If my library and binary already in ppc and native, why i need to worry about any 68k emulation at all ?

     
  • Ilkka Lehtoranta

    Our Magellan main program cant know it. To stay on the safe side it provides 68k callback pointer to all external modules (they can be 68k or PPC). So all our modules ported to PPC must call pointers using EmulateTags() and EmulCallDirect68k(). Of course our Magellan is providing just a fake 68k pointer which in fact has a trap instruction inside to divert execution to PPC native code.

    Looks like I am away from the home little further so cant do coding until next week.

     
  • kas1e

    kas1e - 2013-05-30

    @Ikka

    Aha got it..

    What i trying to say, is that if 68k modules do not works in ppc version of lib/program sometime (that -1 crash), then if we will have it working only with native modules, then we also imho no need to support 68k modules from ppc code ? (and if so, no fake pointers need it as well) ?

     
  • Ilkka Lehtoranta

    Correct. If we remove support for 68k modules in the future than PPC native modules can call Magellan callback pointers directly.

    Now when we mixing 68k and PPC it must default to 68k and PPC code must assume it is 68k client working on the other side.

     
  • kas1e

    kas1e - 2013-05-30

    What you think can we deal with that -1 bug at all, or its something general which we can't fix for that 68k<->ppc mix ? Because if it something general, we can just drop support of 68k modules in ppc builds .. Or you think we can fix it now when we have all modules ported ?

    Anyway, morphos native version of filetype.module still crashes on running with -1, so should be something which can be fixed (as it works on os4). Maybe ABI again or so..

     
  • Ilkka Lehtoranta

    I want to keep M68K crosscalls in MorphOS builds because it is "preferred" way to do it.

    This -1 bug looks generic issue and I dont think it is due to 68k<-->PPC mixing. And most likely it is also affecting OS4 build but it just behaves differently.

    But I have to admit I have lost track of events now when I have been few weeks away from the development...

     
  • kas1e

    kas1e - 2013-05-30

    @ikka
    -1 bug happens only with ppc library. when library is 68k (gcc one), then all modules works ok when they in 68k. thats why i think its about 68k-ppc-callbacks problem.

    as for 68k callback in registr module: can you show code snippet of registr.c from portedmodules/registr.module, so i can check it and fix the same all others where callbacks is uses ?

     
  • kas1e

    kas1e - 2013-05-31

    @all

    Commit #436 : fixed all "warning: suggest parentheses around assignment used as truth value" in all the modules. That was pain for few hours, but in end warning-output start to looks much better without long boring lists with the same warnings.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks