20-Apr-2024 03:21 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 28 items in your selection
[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

POSIX threads ported to 68k Amiga : Comment 1 of 28ANN.lu
Posted by Golem on 29-Jan-2004 00:47 GMT
I this different from the geekgadgets port?
POSIX threads ported to 68k Amiga : Comment 2 of 28ANN.lu
Posted by Anonymous on 29-Jan-2004 08:28 GMT
Non pre-emptive ? Who wants to use non pre-emptive threads in system like Amiga which multitasking is pre-emptive ? That would be crazy.
POSIX threads ported to 68k Amiga : Comment 3 of 28ANN.lu
Posted by Anonymous on 29-Jan-2004 08:35 GMT
"Even though it is only 1 days work I thought it was worth an announce as people always say the classic Amiga cant thread,"

Those people don't know what they are talking about. If they talked about POSIX threads then that's ok.

" well it can thread! "

Every Amiga application can have multiple tasks/processes which are one type of thread.
POSIX threads ported to 68k Amiga : Comment 4 of 28ANN.lu
Posted by Kjetil on 29-Jan-2004 10:44 GMT
In reply to Comment 3 (Anonymous):
Non pre-emptive ? Who wants to use non pre-emptive threads in system like Amiga which multitasking is pre-emptive ? That would be crazy.

forks() and clones() are not the same as multitasking, and yes 68k task can’t tread,
Inn fact treads are one of the new features of AmigaOS4.0,

Every Amiga application can have multiple tasks/processes which are one type of thread.

Correction task/processes are not treads or forks or clones, task processes/processes are external and they can not automatically share variable space, open files etc, treads are internal, child clone, fork and treads can share resources whit main tread, type of shared resources can be variable space, memory space, open files, etc.

fork() will duplicate your program at location in your program it’s executed, variable space is copied as well, the level of shard recourses can be defined inn forks() argument

clone() will convert a function space to an task, memory space is not duplicated, memory is shared whit the child task,

Treads are better then fork(), due to communication I think.

Treads are not needed to write efficient programs (if you have on CPU computer system), Treads do not make your programme use less CPU (It’s easier to let multitasking to deal whit it).

Divide the program allowing you to, use less time dreaming up tables and structures to deal whit separate operation, example of usage web server whit different clients connected, simultaneous operation that need to be synchronized, that can not be effected by bad programming style/lazy programming.
POSIX threads ported to 68k Amiga : Comment 5 of 28ANN.lu
Posted by Thematic on 29-Jan-2004 11:50 GMT
If I only remembered which ones of my (short) porting experiments stumbled on threads...
POSIX threads ported to 68k Amiga : Comment 6 of 28ANN.lu
Posted by whoosh on 29-Jan-2004 16:53 GMT
@Golem,


why is it in the alpha directory?


and its been there for 2 years,


if all the test progs function then it should
never have even entered the alpha directory,


the fact its there suggests why,


rpm4.0 was also in the alpha
directory and totally malfunctioned. Thats why
I had to do my own port, my port is fully functioning
but has database support disconnected.


Anyway its too late now, I have ported a fully
functioning version,
I would never dream of putting my port in the
alpha directory,


alpha directory == problem directory,


Regarding pthread which is also in the above alpha directory,
well I have also generated a binary for pthread, but it crashes
on exit if any stdio function such as printf is used,
so *all* the test programs fail currently,
thats why I havent announced it and it would go into an alpha directory.


Its one thing to generate a binary, its quite another for it to
function.


@Kjetil quite!


threads share resources whereas tasks + processes dont,


so threads are analogous to say 3 people living in 1 house,


vs tasks and processes are analogous to 3 people living in
3 houses.


In a shared house you share resources such as bathroom and kitchen,
mutual exclusion can be done via keys. In separate houses the
entire house becomes a mutually excluded resource via a key.


If a program uses threads you cant just replace the thread calls
with CreateTask(), if only!


Re: why have non pre-emptive? if it satisfies the specification
for libpthread.a then what does it matter?


:non-pre-emptive doesnt need any platform specific code so
its going to be more safe as the same code will be tested
on all platforms.


Also non-pre-emptive is less fiddly so more likely to be safe,


I would like it to be pre-emptive, but so far there is some
impossible to find bug in the pre-emptive version. The pre-emptive
version needs a lot of tricky platform specific code and there
is no explanation of how to generate this.


BTW I have put some 7 example threaded programs on the site


http://www.whoosh777.pwp.blueyonder.co.uk/threaded_68kprograms.lha


so you can verify that its not an alpha,


whoosh
POSIX threads ported to 68k Amiga : Comment 7 of 28ANN.lu
Posted by whoosh on 29-Jan-2004 18:39 GMT
In reply to Comment 6 (whoosh):
hnl_dk has pointed out to me that the most
current version of pth is 2.0.0,

so when time permits I may attempt that,

for the moment I think I will make use of
this 1.4.0 version,

worrying about 1.4.0 vs 1.4.1 is really
a storm in a teacup!


:the port was so clean and smooth that I
think 1.4.0 is all that is needed.

(the configuring of the port OTOH was a
total pain and exposed even an error
in the Geekgadget includes, first ever
error I have found in GG:include !)

I will make one last attempt at the
pre-emptive implementation tonight
POSIX threads ported to 68k Amiga : Comment 8 of 28ANN.lu
Posted by Fabio Alemagna on 29-Jan-2004 19:51 GMT
In reply to Comment 6 (whoosh):
> Anyway its too late now, I have ported a fully
> functioning version, I would never dream of putting my port in the
> alpha directory,

Not to push you down, but correct me if I'm wrong: "ported" here simply means "recompiled", doesn't it? Pth has always supported AmigaOS, all you had to do was grab the sources and compile.
POSIX threads ported to 68k Amiga : Comment 9 of 28ANN.lu
Posted by MarkTime on 29-Jan-2004 21:49 GMT
In reply to Comment 7 (whoosh):
is storm in a teacup similar to tempest in a teapot.

just curious.
POSIX threads ported to 68k Amiga : Comment 10 of 28ANN.lu
Posted by whoosh on 30-Jan-2004 01:23 GMT
In reply to Comment 8 (Fabio Alemagna):
I said:


>> Anyway its too late now, I have ported a fully


>> functioning version, I would never dream of putting my port in the


>> alpha directory,


Fabio Alemagna said:


>Not to push you down, but correct me if I'm wrong:


>"ported" here simply means "recompiled", doesn't it?


Not my port, recompile is not enough,
my port==configure+recompile+binary runs correctly,
when I say binary runs correctly I mean that the 8 relevant example
test programs linked with the binary library run correctly.
You can download and try on 68k 7 of those example programs:


threaded_68kprograms.lha from the above website.


With my port of Pth all the example test programs run correctly
thus not only is the binary generated ie successful recompile
but also said binary runs correctly.


Contrast with pthreads-1_60_beta6 which I have recompiled + generated binaries
but when you run, it functions correctly but crashes on exit if you
use any of their replacement stdio functions (printf() and write()
in particular),


Thus my pthreads-1_60_beta6 can join their one in the alpha directory,
a port which crashes or otherwise malfunctions is fairly useless.


With Pth 1.4.0 in particular, the configure script (168774 byte
unix shell script, not as big as rpm4.2 which has a 732365 byte script
but big nonetheless) crashes at many places. Debugging it is
going to take weeks and a thorough command of the unix shell.
So you cannot even configure the port,
the problem being that the script cannot cope with the
specific problems of the GG Amiga environment, I use an
untampered with Geek environment. The docs claim its tested on AmigaOS,
so how come the script crashes again and again and again on AmigaOS.


Most of the work of the port is in engineering the configure
script to complete mainly by using devious trickery.


Example of a thing the configure script cannot cope with is to determine
direction of stack growth. So if you get that wrong the port is
going to nose dive into the abyss by setting the thread stack pointers
to the wrong end! One problem is the configure script is making
all sorts of assumptions which sadly dont hold on AmigaOS GG.


A specific technical bug in the configure script is it
determines if SYS_read is defined thus:


#include <sys/syscall.h>


#ifdef SYS_read


yes SYS_read is defined!


#endif


sadly this trick fails on AmigaOS because on AmigaOS SYS_read is defined
in sys/syscall.def via the above #include,
but the above trick tells you it isnt defined, ie the above trick is bugged.
I think the trick fails because for AmigaOS SYS_read is defined by
sys/syscall.def via an enum, unfortunately things defined via enum
fail the #ifdef test, an annoying subtlety of c. I think #ifdef is only
true in c for things defined via #define, things defined by other means
such as enum's and eg "int x;" fail the #ifdef test.


>Pth has always supported AmigaOS,


it claims to support AmigaOS, and after a lot of brute force
fixing of the configure script it does, but not AS-IS.


And if it supports AmigaOS why does the configure script crash
in so many places on AmigaOS?? Their documentation is not being
entirely truthful. The problems are entirely at the configure stage,


>all you had to do was grab the sources and compile.


If only! before you compile you have to configure and
the configure (could take an hour to execute on my 68030 setup)
crashes repeatedly. Eg the configure attempts to extract all sorts of
info such as obscure system specific types using sed,
and evidently it does this wrongly.


Before you configure there is no makefile, the configure
generates right at the very end the makefiles so if the
configure crashes you have no makefiles so you cannot compile.


So by hook or by crook you have to get the configure script to complete,
which I managed. I begun the evening before the announce and the next
evening the automatically executed test procedure successfully completed
(test_std) followed by an automatically generated "Good luck!" message!


You cannot simply do eg "gcc #?.c", its a bit more complicated than that!


With pthreads-1_60_beta6 (and all other versions of pthreads),
things are more tricky because when you
configure it tells you that amigaOS is unsupported, bye!


:So the first challenge is to get around this, you also need to supply
a handful of system specific source files, with scant info on how
to generate these. Anyway as far as I can see I have supplied the
correct system specific files, but the example test progs all
crash on exit. If I dont use their replacement stdio functions
but instead just directly use ixemul then there is no crash on exit
but also the POSIX specification of libpthread.a is flouted so
the example progs generate error messages (but dont crash).


So I can currently generate pre-emptive threading,
its just not POSIX threading though!
POSIX threads ported to 68k Amiga : Comment 11 of 28ANN.lu
Posted by Sigbjørn Skjæret on 30-Jan-2004 01:49 GMT
In reply to Comment 10 (whoosh):
Humm, I configured Pth 1.4.0 (or was it 1.4.1?) eons ago on AmigaOS, it didn't crash, and the final built product even passed all the tests, so maybe, just maybe, you have a messed up GG setup?


- CISC
POSIX threads ported to 68k Amiga : Comment 12 of 28ANN.lu
Posted by Oppressor on 30-Jan-2004 01:56 GMT
I was using the PTH package once, and it was amazing how well it could replace code that was previously using preemptive threads. In the server software domain, there is an ongoing discussion about explicit multithreaded vs. explicit singlethreaded designs. Interesting in this context is that PTH can be both, as it makes it transparent to the application. The application as a whole remains single-threaded, but parts of the code are "logically" threaded. This is achieved by implicit context changes at all kinds of synchronization points.

If your application is strictly event-driven and operates on short jobs per thread, then this approach is worth a look, because it can outperform preemptive threads, especially on operating systems with expensive kernel context switches (the AmigaOS does NOT belong to this category, though). You can also switch between cooperative and preemptive threads by simply linking against a different pthreads implementation. If you are interested, test your application regularly with both PTH and regular pthreads implementations. If this works, then your overall design is probably good. :)

One possible benefit of PTH on the Amiga may be that you can possibly zap/kill threads at cooperation points (I didn't look into your port, though). This is otherwise not cleanly possible on the Amiga.
POSIX threads ported to 68k Amiga : Comment 13 of 28ANN.lu
Posted by Golem on 30-Jan-2004 04:45 GMT
In reply to Comment 6 (whoosh):
>why is it in the alpha directory?

Because that's were all new submissions are put, if you want a recent
version of gcc that is where you find it.

>and its been there for 2 years,

The latest geekgadget snapshot is from '99.

>if all the test progs function then it should
>never have even entered the alpha directory,

Read above.

>the fact its there suggests why,

Read above.

>rpm4.0 was also in the alpha
>directory and totally malfunctioned.

So because one package is broken you assumed they all were?

>Anyway its too late now, I have ported a fully
>functioning version,
>I would never dream of putting my port in the
>alpha directory,

You'd better not upload it geekgadgets then.

>alpha directory == problem directory,

So you say...

>Its one thing to generate a binary, its quite another for it to
>function.

Of course, did you try pth from geekgadgets?

Regards
POSIX threads ported to 68k Amiga : Comment 14 of 28ANN.lu
Posted by Anonymous on 30-Jan-2004 09:10 GMT
No wonder nobody wants to write software for Amiga these days...
POSIX threads ported to 68k Amiga : Comment 15 of 28ANN.lu
Posted by Anonymous on 30-Jan-2004 12:47 GMT
In reply to Comment 10 (whoosh):
Anything # in c is not c but cpp (c preprocessor),
and all preprocessing is done before the compile (usually).

gcc --help
...
-E Preprocess only; do not compile, assemble or link
...
POSIX threads ported to 68k Amiga : Comment 16 of 28ANN.lu
Posted by whoosh on 30-Jan-2004 21:23 GMT
@Sigbjorn said:

>Humm, I configured Pth 1.4.0 (or was it 1.4.1?) eons ago on AmigaOS,
>it didn't crash,


68k AmigaOS or other?


did you enable pthread?


did you make it available by any means?


only the configure crashed, nothing else. with pthreads-#? AmigaOS
is not supported and all the tests crash. pthreads-#? is a totally
different implementation of libpthread.a,


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,


>and the final built product even passed all the tests,


so does this one, pthreads OTOH fails all tests I have tried
eg test_sleep,


So far until this day I have never heard mention that
threading on 68k was possible, in fact lack of threading
is one of the usual criticisms levelled at 68k Amiga.


>so maybe, just maybe, you have a messed up GG setup?


possibly, I think I installed some alpha directory stuff
at some point, I will have to go through my install log
to remove all traces of Geeks alpha.


nonetheless that configure is bugged,


@Golem,


er, rpm is right at the centre of Linux, if they have a screwball version
of something so central anywhere on Geek then something sux.


If some obscure port sux thats ok but not rpm,


they cant let something that sux remain on their site, whats the point?


After that experience I wont touch anything in Geeks alpha directory
with a bargepole.


You say the last snapshot is 1999, 5 years,
a real go getting site, eh, sounds like nothing will ever
leave the alpha directory then,


BTW if there are so many who claim libpthread.a exists
why didnt you point it out to me when I ported rpm4.0 and
said databases were disconnected due to no libpthread?


Is it really so hard to create some new subdirectory and
move reasonably tested ports to it?


You are blowing all your energy yelling at me why not
blow that energy more constructively and type a few


"mv alpha/xyz seems_fine_as_far_as_we_can_see/xyz"


commands??


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.
POSIX threads ported to 68k Amiga : Comment 17 of 28ANN.lu
Posted by Sigbjørn Skjæret on 31-Jan-2004 00:05 GMT
In reply to Comment 16 (whoosh):
>68k AmigaOS or other?

Humm, I didn't know AmigaOS ran on anything else eons ago... ;)

>did you enable pthread?

..if by that you mean Pth's pthread emulation, yes.

>did you make it available by any means?

Nope, it was for personal porting use.

>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?

>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

..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... ;)


- CISC
POSIX threads ported to 68k Amiga : Comment 18 of 28ANN.lu
Posted by Oppressor on 31-Jan-2004 03:56 GMT
In reply to Comment 14 (Anonymous):
> No wonder nobody wants to write software for Amiga these days...

Agreed. Given the amount of debates and worshipping around a single GNU
package, maintenance, compiling and porting for the sheer sake of it,
and not to forget the vast number of new applications that will be
built on it. :/

Ahh, Amiga. I'm off for lunch now.
POSIX threads ported to 68k Amiga : Comment 19 of 28ANN.lu
Posted by Kolbjørn Barmen on 31-Jan-2004 16:49 GMT
In reply to Comment 16 (whoosh):
rpm is not even of the slightest importance for Linux.
On contrarary.. good riddance!
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.
POSIX threads ported to 68k Amiga : Comment 21 of 28ANN.lu
Posted by Sigbjørn Skjæret on 01-Feb-2004 23:30 GMT
In reply to Comment 20 (whoosh):
"@Sigbjørn said: (I've figured out how to write your name, it requires alt-o!)"

Congratulations, that's better than most... ;)

"I think it would have been worth you announcing that threads were possible on 68k, to me at least this fact is newsworthy."

It didn't occur to me that it would be newsworthy as there already was a port in the gg archives...

"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

"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)...

"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...


- CISC
POSIX threads ported to 68k Amiga : Comment 22 of 28ANN.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?
POSIX threads ported to 68k Amiga : Comment 23 of 28ANN.lu
Posted by Sigbjørn Skjæret on 02-Feb-2004 20:39 GMT
In reply to Comment 22 (whoosh):
"does anyone know how to do accent marks (looks like ' above a vowel)?"

Sure, either use the deadkey beside Enter, or use alt-f to k, then press the appropriate vowel (alt-f==´ g==` h==^ j==~ k==¨)...

"Its quite absurd, I think it would be faster for me to hand configure sed than use their script on my system."

Yes, you're not the only one to think configure is overkill .. a quick google will confirm that... ;)

"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)"

If you have or plan to have other targets (like PPC) it is, otherwise you can just use usr:lib for clarity...

"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 )."

Usually no, but it might (don't remember for sure) incur math-emulation functions which are usually covered by libgcc.a (horribly slow (there might be a replacement which uses mathlibs though, dunno)), but libnix has these builtin (which does use mathlibs)...

"complex instruction set chip?"

No.


- CISC
POSIX threads ported to 68k Amiga : Comment 24 of 28ANN.lu
Posted by whoosh on 02-Feb-2004 20:59 GMT
In reply to Comment 22 (whoosh):
I think I've found out why the sed configure lasts forever,
I decided to put in some echo statements in, and the
following shows there is some kind of infinite loop,
shell output:


Be Bourne compatible

Support unset when possible.

Work around bugs in pre-3.0 UWIN ksh.

NLS nuisances.

Required to use basename.

Name of the executable.

PATH needs CR, and LINENO needs CR and PATH.

Avoid depending upon Character Ranges.

The user is always right.

Be Bourne compatible

Support unset when possible.

Work around bugs in pre-3.0 UWIN ksh.

NLS nuisances.

Required to use basename.

Name of the executable.

PATH needs CR, and LINENO needs CR and PATH.

Avoid depending upon Character Ranges.

The user is always right.

Be Bourne compatible

Support unset when possible.

Work around bugs in pre-3.0 UWIN ksh.

NLS nuisances.

Required to use basename.

Name of the executable.

PATH needs CR, and LINENO needs CR and PATH.

Avoid depending upon Character Ranges.

The user is always right.




another bugged configure it seems,
POSIX threads ported to 68k Amiga : Comment 25 of 28ANN.lu
Posted by whoosh on 02-Feb-2004 21:32 GMT
In reply to Comment 22 (whoosh):
GOTCHA!!!

I've found the configure bug, its either a bug
with GG /bin/sh or with the configure:

the archive is:

http://ftp.gnu.org/gnu/sed/sed-4.0.9.tar.gz

and line 90 of configure says:


echo "#! /bin/sh" >conf$$.sh


what it should say is:

echo "#!/bin/sh" >conf$$.sh


ie there shouldnt be a space between !
and the shell name,

GG sh at least doesnt like a space there,


I think this same bug is all over the place,
this space is causing an infinite loop in the
configure,

as soon as I removed the space the configure
stopped looping,
POSIX threads ported to 68k Amiga : Comment 26 of 28ANN.lu
Posted by whoosh on 04-Feb-2004 18:08 GMT
In reply to Comment 23 (Sigbjørn Skjæret):
@Sigbjørn said:

============================================================

"does anyone know how to do accent marks (looks like ' above a vowel)?"

Sure, either use the deadkey beside Enter, or use alt-f to k,
then press the appropriate vowel (alt-f==´ g==` h==^ j==~ k==¨)...

========================================================

I have selotaped this info now to my monitor!

áèîõü

=========================================================

"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)"

If you have or plan to have other targets (like PPC) it is,
otherwise you can just use usr:lib for clarity...

====================================================

ok, in future I will rename installed libraries to the appropriate
subdirectory of gg:m68k-amigaos

============================================================

"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 )."

Usually no, but it might (don't remember for sure) incur
math-emulation functions which are usually covered by libgcc.a
(horribly slow (there might be a replacement which uses mathlibs though, dunno)),
but libnix has these builtin (which does use mathlibs)h
..

================================================

I dont mind so much if floating point stuff is done by a subroutine
which uses the FPU if present, but if it ignores the FPU then
an fpu version of a program should be done if the program uses
floating point numbers (many wont).

BTW with the sed configure I ran into another infinite loop later on,
I think the problem is not a sed problem but a /bin/sh problem,

as a result I have temporarily stopped looking at sed and instead
am looking at the shell. I cant find sh anywhere on the internet,
I looked at ash-linux but immediately ran into a problem.


I then attempted a non recent version of bourne again but this
requires external stuff eg ucblib eg tgetstr and tputstr,

I will have a look at the Geek helpsite to see if it has any
info on eg tputstr otherwise I will have another attempt at ash-linux,

maybe I will also try using pdksh from Geek snapshots,
if configures happen correctly via pdksh then I will look no further,
POSIX threads ported to 68k Amiga : Comment 27 of 28ANN.lu
Posted by whoosh on 04-Feb-2004 20:50 GMT
In reply to Comment 26 (whoosh):
ok, pdksh has configured sed (as an experiment) without hitch,
(compared to /bin/sh which breaks repeatedly),

so it seems Geeks boot /bin/sh is now obsolete (cannot cope with current
configures) and pdksh of Geek snapshots is the shell to use,

the above sed 4.0.9 is of January 2004 ie using a totally current
bloated configure,


BTW the sed configure supports the following languages:


ca cs da de el eo es et fi fr ga
gl he hr hu id it ja ko nl pl pt_BR ro ru sk sl sr sv tr zh_CN

trying to keep just one of those languages current and
correctly translated is going to be a challenge,


TBH I wish they would get on and sort out the english docs
for Unix in a way which is even half as useful as the Amiga docs,
rather than time-wasting converting unusable docs to
a zillion and one languages. So the whole world may know
what useless documents *nix has.
POSIX threads ported to 68k Amiga : Comment 28 of 28ANN.lu
Posted by whoosh on 05-Feb-2004 17:36 GMT
In reply to Comment 26 (whoosh):
Well, with my new pdksh shell, I decided to attempt pth-2.0.0,

It was a straight configure, however the SYS_read bug is still there:

checking for define SYS_read in sys/syscall.h... no

except for a few minor glitches the port was straight.

However, I got malfunction with the supplied examples eg with test_misc
the shell stopped receiving keyboard input.

So I forced the configure to take the correct info on SYS_read,
this time everything was fine till I tried test_sig which caused a crash.
So I rebooted, this time no crash from test_sig, however I couldnt exit the shell.

I am going to reinstate some further differences with the "straight"
pth-2.0.0 configure and my hacked pth-1.4.0 configure,
perhaps then it may run.

It has just occurred to me that there may also be pdksh bugs,
so I will also try the examples via the original shell as well
as the AmigaOS shell. Perhaps I should just use pdksh for configuring
but then revert to the other shell?


I will put further developments on the pthreads.html URL given earlier.
Anonymous, there are 28 items in your selection
Back to Top