[News] POSIX threads ported to 68k Amiga | ANN.lu |
Posted on 28-Jan-2004 22:27 GMT by whoosh | 28 comments View flat View list |
straight clean port of Ralf S Engelschall's pth-1.4.0 a
non pre-emptive implementation of POSIX threads
to 68k Amiga. This is 2 gcc linker libraries to
enable porting + writing of threaded programs to 68k Amiga.
http://www.whoosh777.pwp.blueyonder.co.uk/pthreads.html
To see a threaded program run on 68k Amiga download and run
"the 5 philosophers":
http://www.whoosh777.pwp.blueyonder.co.uk/test_philo
(requires just ixemul.library),
:this example program uses libpth.a,
The port itself is 2 gcc linker libraries: libpthread.a and libpth.a,
Last December I ported rpm4.0 with databases disconnected
as database support required libpthread.a . So now I
should be able to generate a full port of rpm4.0
(or higher) to 68k,
(its not at the top of my to-do list)
This port took only one day to do,
an attempt at a totally
different pre-emptive implementation of libpthread.a
took well over a week before I gave up.
Anyway the consequence of this port of pth-1.4.0 is
that it will enable porting of threaded programs.
Probably noixemul progs will also be ok.
Even though it is only 1 days work I thought it
was worth an announce as people always say the
classic Amiga cant thread, well it can thread!
The most difficult thing was locating pth-1.4.0 as
I didnt know it existed till I found it, I was
only searching for libpthread.a
No idea if the example program will run on PPC or
Amithlon, email me if you try it on such.
The advantage of being non-pre-emptive is that it
is much more portable and clean.
And if it implements POSIX threading (nightmare specification)
it implements POSIX threading! (non-pre-emption notwithstanding)
The source + necessary fixes to quite bugged configure
are on http://www.whoosh777.pwp.blueyonder.co.uk/pthreads.html
|
|
List of all comments to this article |
POSIX threads ported to 68k Amiga : Comment 20 of 28 | ANN.lu |
Posted by whoosh on 01-Feb-2004 20:33 GMT | In reply to Comment 19 (Kolbjørn Barmen): I've got myself into a lot of trouble here!
anyway I've learnt a lot of things though,
@Anonymous said:
================================================
Anything # in c is not c but cpp (c preprocessor),
and all preprocessing is done before the compile (usually).
================================================
yes, you are right, so #ifdef is entirely at the
pre-processor stage so cannot "see" things like int x;
its a good way to remember things: if it begins
with # its preprocessor,
gcc Question:
is there any way to make a file of global functions
eg
void f(){}
void g(){}
compile so that it is treated as 1 file per function,
ie the linker will only link in referenced functions.
eg if only f is referenced I dont want g linked in,
@Sigbjørn said: (I've figured out how to write your name,
it requires alt-o!)
====================================================
>68k AmigaOS or other?
Humm, I didn't know AmigaOS ran on anything else eons ago... ;)
========================================
was wondering if you were cross compiling or something,
=======================================
>did you enable pthread?
..if by that you mean Pth's pthread emulation, yes.
==================================
its possible that 1.4.1 is different from 1.4.0,
so maybe you compiled 1.4.1 and I compiled 1.4.0?
Having done 1.4.0 I dont think its worth the effort to do
1.4.1,
==========================================
>did you make it available by any means?
Nope, it was for personal porting use.
=========================================
I think it would have been worth you announcing that
threads were possible on 68k, to me at least
this fact is newsworthy.
=================================================
>er, take a look at what I said about SYS_read, that proves the
>configure is incorrect. Perhaps the port will still happen despite
>this specific bug. But a bug it is,
True, but does it have any impact on the port?
=================================================
Pth seems so robustly written that I can believe that it wont!
=======================================================
>If malfunctioning ports are thrown in with reasonable ones
>then chaos will ensue. One of the nice things about
>the Geek snapshot directories is they are so reliable,
>ie if you download something from there then you are
>quite certain it will function.
I guess that's why they are in the alpha dir, so you can find out for yourself. :P
=======================================================
from Golems post I see that the alpha dir has good and bad,
I think they should subdivide it into author_thinks_its_fine
and author_knows_its_not_fine.
=======================================================
..anyway, I never really trusted any binaries
(ok, a select few in the beginning to get going),
I always compile everything myself, possibly checking the diffs
if they have something interesting to contribute... ;)
===========================================================
that is a tough approach, probably you need a faster machine
than my 68030 to indulge in such a luxury.
I suppose that if you download
from Geek then you know it should be a straight compile,
(ie the port has been "debugged" and the difficult parts
have been dealt with).
With Linux this approach happens, however note that with
Linux its not really porting but recompiling. Porting ==
bringing it to the platform for the first time. When
people build on Linux all the problems have already
been ironed out for them,
What do you download to create Boot.lha, eg sh?
I have only looked at things not on Geek, ie I have downloaded
cross platform sources where often Amiga is not mentioned.
So here anything can go wrong and sometimes does. Some things
are straight ports like bzip2,
Question: with something like bzip2, where would I put
libbz2.a for eg a 68020 fpu compile?
would it be:
gg:lib/libm020/libm881/libbz2.a?
One disadvantage of Geek, is that I think most things are
the default compile which is 68000 no fpu,
really the default compile ought to change to 68020 no fpu
at least.
I dont know if gcc's 68000 no fpu compile will
detect and make use of a FPU if present??
@Kolbjørn said
=========================================
rpm is not even of the slightest importance for Linux.
On contrarary.. good riddance!
=========================================
I am not a Linux user so I dont know!
However everything seems to be available in #?.rpm
format?
Linux and Unix seem to take pleasure in
adding never ending amounts of organisational
clutter. This is what I like about the Amiga,
everything is so direct.
With the Amiga I can obtain any info I need
from the RKMs and autodocs, with Unix things
I could spend days trying to figure something out,
eg I found I needed sbrk(), its not in ixemul
at least not as an explicit function,
what on earth is sbrk()?
Google brings me to some manual pages on this,
which are utterly useless. Eventually on a Geek
help site (innoidea) I obtain a code fragment.
From the code fragment I understand that
sbrk() is a 1 way memory allocation stack,
essentially:
sbrk(incrs){ ret = space ; space = space + incrs ; return( ret ) ; }
The Unix page on sbrk() explained zilch,
Geeks code fragment didnt get past the linker,
a few changes got it through.
Lastly what happens when sbrk() runs out of space,
I was worrying about this eg should I use an exit(),
till I saw that the code that called sbrk()
expected -1 as error,
So at last I fully understood sbrk(),
its actually very simple, (pop requested quantity
of space off if you can else return -1),
but you would think its very complicated
if you look it up from Unix docs via Google. |
|
List of all comments to this article (continued) |
|
- User Menu
-
- About ANN archives
- The ANN archives is powered by #AmigaZeux. It was updated daily (news last: 22-Oct-2004; comments last: 18-May-2005).
ANN.lu was created, previously owned and maintained by Christian Kemp, www.ckemp.com.
- Contribute
- Not possible at this time!
- Search ANN archives
- Advanced search
- Hosting
- ANN.lu was hosted by Dreamhost. Sign up through this link, mention "ckemp" as referrer and he will get a 10% commission on any account you purchase.
Please show your appreciation for any past, present and future work on ANN.lu by making a contribution via PayPal.
|