david@doe.utoronto.ca (David Megginson) (09/26/90)
Maybe what we need most of all for MiNT is a reasonably good clone of the Unix system library for Gnu. If someone rewrites gnu.olb to recognise and use MiNT, porting programs will be a cinch. Perhaps CRT0 should check whether MiNT is present, and set a global variable _mint to TRUE or FALSE (and do the same for _rtx, of course). Then the library can use these variables to decide how to execute system functions. Anyone willing to give it a shot? I'm too busy, since my TAL (Text Analysis Language) is weeks away from release. David Megginson -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
hyc@math.lsa.umich.edu (Howard Chu) (09/27/90)
In article <1990Sep25.175226.6410@doe.utoronto.ca> david@doe.utoronto.ca (David Megginson) writes: >Maybe what we need most of all for MiNT is a reasonably good >clone of the Unix system library for Gnu. If someone rewrites >gnu.olb to recognise and use MiNT, porting programs will be >a cinch. Perhaps CRT0 should check whether MiNT is present, >and set a global variable _mint to TRUE or FALSE (and do the >same for _rtx, of course). Then the library can use these >variables to decide how to execute system functions. >Anyone willing to give it a shot? I'm too busy, since my >TAL (Text Analysis Language) is weeks away from release. Sounds like a very good idea. Actually, how 'bout creating an array of function pointers and letting crt0 initialize it to the appropriate calls... That would prevent wasting time testing variables all the time... I've been working on this sort of thing for RTX and MWC, but it's kind of slow work, figuring out all the routines you want to change and such. (But now I have the Beckemeyer Software Development System, and expect that things will go much more quickly from there...) -- -- Howard Chu @ University of Michigan one million data bits stored on a chip, one million bits per chip if one of those data bits happens to flip, one million data bits stored on the chip...
muts@fysaj.fys.ruu.nl (Peter Mutsaers /100000) (09/27/90)
In article <1990Sep25.175226.6410@doe.utoronto.ca> david@doe.utoronto.ca (David Megginson) writes: >Maybe what we need most of all for MiNT is a reasonably good >clone of the Unix system library for Gnu. If someone rewrites >gnu.olb to recognise and use MiNT, porting programs will be Yes, a good UNIX clone library. But why alone for gnu? I'd really like to see one for Turbo C. It would be nice for the extra speed and smaller binaries (and because I have TC, but cannot run gnu in 1 Mb). When I have time, I'll try to port the MinT sources to TC. -- Peter Mutsaers email: muts@fysaj.fys.ruu.nl Rijksuniversiteit Utrecht nmutsaer@ruunsa.fys.ruu.nl Princetonplein 5 tel: (+31)-(0)30-533880 3584 CG Utrecht, Netherlands
ericco@stew.ssl.berkeley.edu (Eric C. Olson) (09/28/90)
In article <1990Sep26.220620.27988@math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: >In article <1990Sep25.175226.6410@doe.utoronto.ca> david@doe.utoronto.ca (David Megginson) writes: >>Maybe what we need most of all for MiNT is a reasonably good >>clone of the Unix system library for Gnu. If someone rewrites >>gnu.olb to recognise and use MiNT, porting programs will be >>a cinch. Perhaps CRT0 should check whether MiNT is present, >>and set a global variable _mint to TRUE or FALSE (and do the >>same for _rtx, of course). Then the library can use these >>variables to decide how to execute system functions. > >Sounds like a very good idea. Actually, how 'bout creating an >array of function pointers and letting crt0 initialize it to the >appropriate calls... That would prevent wasting time testing >variables all the time... Shared libraries would handle this quite neatly. The basic concept is to edit the programs runtime binding so that function calls are made directly to the library functions (ie, without indirection or table lookup). Another possibility is a GNUware program I got off the net, called dld, a dynamic loader. Eric Eric ericco@ssl.berkeley.edu
david@doe.utoronto.ca (David Megginson) (09/28/90)
In article <1583@ruunsa.fys.ruu.nl> muts@fysaj.fys.ruu.nl (Peter Mutsaers /100000) writes: > >When I have time, I'll try to port the MinT sources to TC. > An excellent idea. I have heard that TC produces _much_ faster code than any other compiler, and that the speed difference is almost like a chip upgrade. Also, TC's code is supposed to be about 1/3 smaller than other compilers. MiNT would probably be blindingly fast compiled with TC. David Megginson -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
7103_2622@uwovax.uwo.ca (Eric Smith) (09/30/90)
In article <1990Sep25.175226.6410@doe.utoronto.ca> david@doe.utoronto.ca (David Megginson) writes: >Maybe what we need most of all for MiNT is a reasonably good >clone of the Unix system library for Gnu. If someone rewrites >gnu.olb to recognise and use MiNT, porting programs will be >a cinch. Perhaps CRT0 should check whether MiNT is present, >and set a global variable _mint to TRUE or FALSE (and do the >same for _rtx, of course). Then the library can use these >variables to decide how to execute system functions. Not much sooner said than done; I just sent the modified source code for the GCC library to atari.archive (the file is called mintlib.zoo; check for it in the newitems directory, it should be there soon). The library is optimized for MiNT, in the sense that I didn't bother trying to emulate things like fork() and vfork() under TOS (as in previous versions of the library, there's a spawnve() call to emulate fork/exec/wait in TOS; under MiNT you can also use spawnve() to start things in the background). The external variable __mint is set to the MiNT version we're running under, or 0 for TOS. This library can compile the Sun version of bash with 0 changes (well, if you're doing it on an ST instead of a Sun you'll have to rename "y.tab.c" and "y.tab.h" to "y,tab.c" and "y,tab.h", or whatever the names are that your Yacc clone outputs). This is not to say that bash has been ported to MiNT. The path code should be changed to accept commas instead of colons, and the startup file names should be modified (to "bash.pro" instead of ".bash-profile", etc.); and it would be nice to be able to type "ls" instead of ls.ttp. I hope someone can do this polishing; I haven't got a whole lot of time. I don't know RTX well enough to try to write a library for it; also, my primary interest is in compiling Unix (BSD flavor) software, and MiNT is (by design) better suited to this than RTX. (Conversely, RTX is better at lightweight processes than MiNT is; a cthreads library for RTX would be almost trivial). So the MiNT library doesn't support RTX at all. Since everything is in source form, you can add this support if you want. It would probably be worthwhile, since lots of people use RTX. -- Eric R. Smith email: Dept. of Mathematics ersmith@uwovax.uwo.ca University of Western Ontario ersmith@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638