Regina rexx as PPC ARexx replacement ?
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    Hello,

    Iggy (Jim) on amiga.org some time ago asked for progammers and projects for MorphOS that could be sponsored by some hardware able to run MorhpOS.
    I replied I would be interested to be able to run MorphOS at home.

    In light of full disclosure I have to admit I am mainly an AROS developer at the moment. In the past I also did the ScalOS port to OS4 until Jurgen Lachmann took over.

    After some discussion with Jim and Simon (Oepabakkes) I said as a short(er) term project I could maybe port the Regina Rexx we use in AROS for ARexx replacement to MorphOS. Simon proposed to discuss this idea on Morphzone so here I am :-) Let your feedback come.
    I implemented all ARexx specific functions I could find documentation for in regina and it was integrated in upstream. The major missing functions is the implementation of the OPTIONS RESULTS and the other ARexx specific OPTIONS. After I did a bug fix end of last year regina is now used in AMC on AROS for driving the ARexx port of mplayer for video playback.
    I know there is a bounty for a closed source version for PPC Arexx and I don't want to interfere with that. If that project is still on, it is normal that that would be preferred for MorphOS. Regina Rexx would be LGPL open source.

    My long term multi-year project is to develop a SDK and/or dev environment that would be able to ...
    ... compile programs for all Amiga(-like) OSes.
    ... not need #ifdefs nor complicated Makefiles.
    ... run on all Amiga like OSes and the cross-compilers even on Linux, MacOS, Windows etc.
    ... be able to remove most of the boiler plate code for making:
    - amiga style shared libraries
    - devices
    - handlers
    - BOOPSI classes
    - MUI classes
    - ...
    But like said before, it will be a multi-year (or even multi-decennium) project ...

    greets,
    Staf.


    [ Edited by Fats on 2011/2/4 19:22 ]
    Trust me ...
    I know what I am doing
  • »03.02.11 - 19:01
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Simon
    Posts: 809 from 2008/7/6
    From: Antwerp, Belgium
    I honestly do not know anything about these "things" ... but development is development. I can source you a machine as said before.

    Apart from that, I would like to see some -constructive- discussion about this. I know there is some AREXX closed source development ... but choice isn't a bad thing.

    [ Edited by Oepabakkes on 2011/2/4 7:58 ]
    Proud member of the Belgian Amiga Club since 2003

  • »03.02.11 - 21:27
    Profile Visit Website
  • jPV
  • Yokemate of Keyboards
    Yokemate of Keyboards
    jPV
    Posts: 2096 from 2003/2/24
    From: po-RNO
    Any working native AREXX implementation would be welcome. Even better if it could be included on the ISO, but how do those licenses apply...

    And would it be possible to add that OPTIONS RESULTS? It is a major function as you said. Used on the most of the scripts which interact with other programs.
  • »04.02.11 - 06:57
    Profile Visit Website
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 12157 from 2003/5/22
    From: Germany
    > Even better if it could be included on the ISO, but how do those licenses apply...

    There's already many LGPL software contained in the MorphOS ISO (AHI, Ixemul, XAD-Master etc.), so it should be no problem.
  • »04.02.11 - 17:17
    Profile
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    Quote:


    jPV wrote:
    And would it be possible to add that OPTIONS RESULTS? It is a major function as you said. Used on the most of the scripts which interact with other programs.


    Sure, this is the least I could do if I get access to an MorphOS dev machine (and it was in the plans anyway to make AROS fully ARexx compatible :-) )

    Something I forgot to mention is that the ARexx tracing functions and commands are not implemented and I don't plan to do them. Would that be a compatibility problem for user scripts, e.g. when not needing to do debugging.

    greets,
    Staf.
    Trust me ...
    I know what I am doing
  • »04.02.11 - 18:19
    Profile
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    Sprocki
    Posts: 128 from 2005/2/23
    From: Berlin - Germany
    Regarding your SDK/DevEnv plans there is already something being worked on. You might want to take a look at Coriolis Framework: http://sourceforge.net/projects/coriolis-framew/ and talk to Joachim. Even though there is not much information on the SF page he would be happy for someone to join forces. He might also hand the presentations out to you which he held at http://www.amigameeting.de in 2008 and 2009.
  • »12.02.11 - 10:26
    Profile
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    Quote:


    Sprocki wrote:
    Regarding your SDK/DevEnv plans there is already something being worked on. You might want to take a look at Coriolis Framework: http://sourceforge.net/projects/coriolis-framew/ and talk to Joachim. Even though there is not much information on the SF page he would be happy for someone to join forces. He might also hand the presentations out to you which he held at http://www.amigameeting.de in 2008 and 2009.


    Thanks for the link, I was not aware of the project. I found a presentation in the CVS repository. Joachim certainly seems to solve a big part of the puzzle and will see how to cooperate in the future.

    greets,
    Staf.
    Trust me ...
    I know what I am doing
  • »12.02.11 - 13:22
    Profile
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    Quote:

    ... as a short(er) term project I could maybe port the Regina Rexx we use in AROS for ARexx replacement to MorphOS.


    I have a first question.
    I compile regina to a shared library regina.library.
    Internally regina uses standard C IO functions (e.g. fprintf etc.) to get input and do output in rexx scripts.
    On amiga when you start a script RexxMast is notified which script to execute. If the scripts wants to output something it is supposed to output it to the output of where the script was started.
    When my RexxMast receives a message to start a script is gets the standard output, input and error filehandles of the process that send the message, and makes them the standard output, input and error of the current process. It then calls the regina function to start the script. The IO function of AROS' C library then does the right thing when one of the standard handles is used.
    My question is if there is a C library for MorphOS where I can do the same. And if so how to handle it.

    greets,
    Staf.
    Trust me ...
    I know what I am doing
  • »09.04.11 - 16:58
    Profile
  • MorphOS Developer
    itix
    Posts: 1520 from 2003/2/24
    From: Finland
    Quote:


    When my RexxMast receives a message to start a script is gets the standard output, input and error filehandles of the process that send the message, and makes them the standard output, input and error of the current process. It then calls the regina function to start the script.


    This wont work. There is no such library and if there was existing software would know nothing about it.

    The best solution probably would be writing wrappers using DOS file handles.

    But I wonder, doesnt this mean Regina is single threaded without chance to run two scripts simultaneously?
    1 + 1 = 3 with very large values of 1
  • »09.04.11 - 20:18
    Profile
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    itix,
    Quote:

    But I wonder, doesnt this mean Regina is single threaded without chance to run two scripts simultaneously?


    Not on AROS. There the C library generates a libbase for each process. If the C library is opened from different places in the same Process they will share the same standard file handles. So if your program opens C library and regina.library opens it they will share the file handles. regina.library itself has a per opener libbase.
    The disadvantage for the C library is that it is more difficult to support threads as the C library will normally not share info between two Tasks. There are solutions but they are not currently implemented in AROS so we get remarks as some programs - like YAM - seem to depend on using C lib functions from different Tasks.

    What C libraries are available for MOS ? libnix & ixemul ?

    greets,
    Staf.
    Trust me ...
    I know what I am doing
  • »10.04.11 - 13:00
    Profile
  • MorphOS Developer
    itix
    Posts: 1520 from 2003/2/24
    From: Finland
    Quote:


    Not on AROS. There the C library generates a libbase for each process. If the C library is opened from different places in the same Process they will share the same standard file handles. So if your program opens C library and regina.library opens it they will share the file handles. regina.library itself has a per opener libbase.



    I didnt mean the C library but regina.library itself. From your explanation I got impression regina.library was single threaded.

    Quote:


    The disadvantage for the C library is that it is more difficult to support threads as the C library will normally not share info between two Tasks. There are solutions but they are not currently implemented in AROS so we get remarks as some programs - like YAM - seem to depend on using C lib functions from different Tasks.



    Makes me wonder why they didnt use native API in the first place... but it is not my project.

    Quote:


    What C libraries are available for MOS ? libnix & ixemul ?



    Libnix and ixemul and libnix is of course used for the native software. Libnix is thread safe but to use C I/O you must include constructor/destructor code to your library. The linker will tell you if it is needed (it wont link).


    [ Edited by itix 10.04.2011 - 17:02 ]
    1 + 1 = 3 with very large values of 1
  • »10.04.11 - 14:00
    Profile
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    First step has been taken:
    - The regina version for AROS has been upgraded to version 3.5.
    - The usage of packets/messages to the do shild/parent IO communication has been removed. I rely on PIPE: handler being asynchronous.
    - Implemented OPTIONS RESULTS.

    Next step is to get a statically linked rexx command going on MOS that includes the ARexx entensions. I have some questions:
    - AROS PIPE handler is based on Ed Puckett's pipe-handler (v 1.2.1 if I'm correct). This has the following features: named pipes which are asynchronous. Enforcement of one writer and one reader per pipe. Does MOS pipes work the same ?
    - Is there i386 or AMD64 linux-> MOS gcc cross-compiler available ? Did a search but could not find a good setup, zerohero does not seem to provide it anymore.
    The last thing I saw was a message from Piru that he had to solve some problem to get a cross-compiler going for PFS3 open-source release but finally succeeded. Don't seem to find the result though. Is it accessible somewhere ?

    greets,
    Staf.
    Trust me ...
    I know what I am doing
  • »01.10.11 - 13:57
    Profile
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    Quote:

    Next step is to get a statically linked rexx command going on MOS that includes the ARexx entensions.


    Next baby step taken, I could run a first rexx script on MOS with the statically linked executable. Still had to disable some task creation and library function calling code. Work for the coming days/weeks.

    Thanks to vbcc I can now also cross-compile from my linux machine. No support was found yet for a recent gcc cross-compiler.

    greets,
    Staf.


    [ Edited by Fats 15.11.2011 - 21:33 ]
    Trust me ...
    I know what I am doing
  • »15.11.11 - 21:32
    Profile
  • Butterfly
    Butterfly
    munk
    Posts: 94 from 2006/3/27
    Quote:

    No support was found yet for a recent gcc cross-compiler.

    What is a recent GCC? IMHO, for development the compiler version doesn't matter. It is much more important to have a working development environment.
  • »16.11.11 - 07:20
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    Samurai_Crow
    Posts: 161 from 2009/12/10
    From: Minnesota, USA
    @munk

    IIRC, GCC versions 4.2 and newer are required to build AROS software. If you get much older than that, some attributes are missing or implemented in a buggy fashion.
  • »16.11.11 - 14:57
    Profile
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    Fats,
    Quote:

    Next baby step taken, I could run a first rexx script on MOS with the statically linked executable. Still had to disable some task creation and library function calling code. Work for the coming days/weeks.


    I have now a version with some of the problems fixed. If anybody wants to test this (pre-)alpha version you can download it here. If you test it let me know your experience but I do expect nothing to work except some trivial pure rexx scripts.

    Now the hard part begins, getting the shared library version going and doing it in a way so that the C I/O routines in the library are happy.

    greets,
    Staf.
    Trust me ...
    I know what I am doing
  • »04.12.11 - 12:56
    Profile
  • MorphOS Developer
    itix
    Posts: 1520 from 2003/2/24
    From: Finland
    Is your library using globals? If not then standard library model using sysv ABI should work. AFAIK this is not emulating any existing Amiga APIs?

    To use C I/O you "only" have to run C library constructors and destructors. I can provide source code to executor constructors/destructors in your libopen()/libclose() vectors.
    1 + 1 = 3 with very large values of 1
  • »04.12.11 - 14:52
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    Minuous
    Posts: 161 from 2010/2/12
    Why not just ask William Hawes for the proper ARexx source...?
  • »04.12.11 - 15:42
    Profile Visit Website
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    itix,
    Quote:

    To use C I/O you "only" have to run C library constructors and destructors. I can provide source code to executor constructors/destructors in your libopen()/libclose() vectors.


    That would save me a lot of time. I was diving myself already in the ixemul startup code to see how I could do this.

    greets,
    Staf.

    PS: you can mail me: staf at stafverhaegen dot be
    Trust me ...
    I know what I am doing
  • »05.12.11 - 19:42
    Profile
  • MorphOS Developer
    Henes
    Posts: 507 from 2003/6/14
    Check SDK:Examples/Library/nixskeleton/ as it contains what you want and shows how to use libnix's printf() from a shared library.
  • »05.12.11 - 21:45
    Profile Visit Website
  • Just looking around
    Fats
    Posts: 19 from 2011/2/3
    Henes,
    Quote:

    Check SDK:Examples/Library/nixskeleton/ as it contains what you want and shows how to use libnix's printf() from a shared library.


    Will do ! Thanks.

    Now time to get under my rock again ... :-)

    Staf.
    Trust me ...
    I know what I am doing
  • »06.12.11 - 18:48
    Profile