28-Mar-2024 16:46 GMT.
UNDER CONSTRUCTION
[News] POSIX threads ported to 68k AmigaANN.lu
Posted on 28-Jan-2004 22:27 GMT by whoosh28 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
Sorted by date, most recent at bottom
Comment 1Golem29-Jan-2004 00:47 GMT
Comment 2Anonymous29-Jan-2004 08:28 GMT
Comment 3Anonymous29-Jan-2004 08:35 GMT
Comment 4Kjetil29-Jan-2004 10:44 GMT
Comment 5Thematic29-Jan-2004 11:50 GMT
Comment 6whoosh29-Jan-2004 16:53 GMT
Comment 7whoosh29-Jan-2004 18:39 GMT
Comment 8Fabio AlemagnaRegistered user29-Jan-2004 19:51 GMT
Comment 9MarkTime29-Jan-2004 21:49 GMT
Comment 10whoosh30-Jan-2004 01:23 GMT
Comment 11Sigbjørn Skjæret30-Jan-2004 01:49 GMT
Comment 12Oppressor30-Jan-2004 01:56 GMT
Comment 13Golem30-Jan-2004 04:45 GMT
Comment 14Anonymous30-Jan-2004 09:10 GMT
Comment 15Anonymous30-Jan-2004 12:47 GMT
Comment 16whoosh30-Jan-2004 21:23 GMT
Comment 17Sigbjørn Skjæret31-Jan-2004 00:05 GMT
Comment 18Oppressor31-Jan-2004 03:56 GMT
Comment 19Kolbjørn Barmen31-Jan-2004 16:49 GMT
POSIX threads ported to 68k Amiga : Comment 20 of 28ANN.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.
Jump...
#21 Sigbjørn Skjæret
TopPrevious commentNext commentbottom
List of all comments to this article (continued)
Comment 21Sigbjørn Skjæret01-Feb-2004 23:30 GMT
Comment 22whoosh02-Feb-2004 20:18 GMT
Comment 23Sigbjørn Skjæret02-Feb-2004 20:39 GMT
Comment 24whoosh02-Feb-2004 20:59 GMT
Comment 25whoosh02-Feb-2004 21:32 GMT
Comment 26whoosh04-Feb-2004 18:08 GMT
Comment 27whoosh04-Feb-2004 20:50 GMT
Comment 28whoosh05-Feb-2004 17:36 GMT
Back to Top