| [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 22 of 28 | ANN.lu |
| Posted by whoosh on 02-Feb-2004 20:18 GMT | In reply to Comment 21 (Sigbjørn Skjæret):
========================================
"@Sigbjørn said: (I've figured out how to write your name, it requires alt-o!)"
Congratulations, that's better than most... ;)
========================================
does anyone know how to do accent marks (looks like ' above a vowel)?
========================================
"Pth seems so robustly written that I can believe that it wont!"
Well, just because there is a check in configure doesn't mean
the result is used .. usually authors just grab
the full generic configure that checks for a ton of useless things
(and often several times). :P
==========================================
I wish they wouldnt do this, there must be a simpler alternative
to configure's, why cant they just get gcc to go through all
header files, gcc would then know exactly where each
type etc is defined. It would be much faster (100 x ) and contain
more info than configure scripts,
I noticed that if I halt a configure via control-C, its alway sed
that is interrupted (twice in fact:
Interrupt - sed
Interrupt - sed
Interrupt - sh
$
)
So I thought to speed up configures I would
try and recompile my own sed via gcc -m68020 -O2. I attempted this
today, sed is approx 50k, but the current configure for sed is 300k.
I attempted configuring for sed today, and after a few hours
of waiting I quit it. I know it is doing something because
configure.lineno is continously changing size.
I decided then to generate the boot sed, configuring sed
requires sed so they provide a way to generate an initial sed directly
without pre-requiring sed, bootstrap.sh,
I did this as gcc -m68020 -O2 and it took less than 15 minutes,
you are then supposed to use this boot sed to configure for the
proper sed.
Its quite absurd, I think it would be faster for me to
hand configure sed than use their script on my system.
==============================================
"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?"
Yes, though you should build for all cpu targets and put them
where appropriate (yes, I know, it can be tiresome ;) ) ..
also you should perhaps use usr:lib instead
(or gg:m68k-amigaos/lib if you have multiple target compilers)...
==================================================
ok, so there is more than one way to do it,
currently there are no libs in gg:m68k-amigaos/lib on my setup
only a subdirectory ldscripts/,
I have found there is also:
gg:lib/gcc-lib/m68k-amigaos/2.95.3/libm020/
a readme file in each gg: subdirectory would be very helpful :(
you think gg:m68k-amigaos/lib/libm020/libm881 would be the
most correct place then? (this directory path doesnt
currently exist on my Geek setup)
for 68k I think there are only 2 worthwhile compiles:
68020 no fpu and 68020 fpu, some 68040s cannot use an FPU
so you need a 68020 no fpu to run on all systems.
=================================================
"I dont know if gcc's 68000 no fpu compile will detect and
make use of a FPU if present??"
No it will not, but both libnix and ixemul will use the
mathXXXX.libraries for their math functions...
=================================================
so eg with double f( double x , double y ){return( x / (y + 1.0));}
would the fpu not be used in a 68000 no fpu compile?
(with gcc ... -lm ).
(thinking here of ordinary floating point maths, + - / * )
======================================
- CISC
======================================
complex instruction set chip? |
|
| 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.
|
