Contributed by marco on from the hppa-is-weird dept.
The first part, getting the _atomic_lock.c file in was simple (and wrong as I found out later, but that's for another time). So now I am feeling all 1337 to find out that it needs another piece called rfork_thread. Crap, that one is actually hard so I decided that it was great for someone else. Needless to say that by midday the itch *had* to be scratched so I started looking at various implementations (macppc, i386, amd64). The i386 one was simple enough so I decided to *only* have a look.
Hours later...
I am still wading through the hppa documentation. Wow this is not CISCy at all. This is some crazy ass assembly. For example, one branches and the stupid cpu executes one more instruction regardless of hitting it or not. That's stupid! well at least on first sight it is. Now that I have seen it in action it is actually quite clever.
Check this out:
#include#include int moo(int i) { i++; printf("%d\n", i); return (i); } int main(int argc, char *argv[]) { int i = 0; for (i = 0; i < 10; i++) { printf("%d\n", i); } moo(15); return (0x0a); } Compile this like so: # cc moo.c -Wall -ggdb3 -O2 And lets look at it: # objdump -S a.out > a && vim a ... ... 00001694 : #include #include int moo(int i) { 1694: 6b c2 3f d9 stw rp,-14(,sp) 1698: 6f c4 00 80 stw,ma r4,40(,sp) i++; 169c: 37 44 00 02 ldo 1(r26),r4 printf("%d\n", i); 16a0: 23 41 00 00 ldil 2000,r26 16a4: 37 5a 0e a8 ldo 754(r26),r26 16a8: e8 5f 1a b5 b,l 1408 <__init+0x24>,rp 16ac: 08 04 02 59 copy r4,r25 return (i); } 16b0: 4b c2 3f 59 ldw -54(,sp),rp 16b4: 08 04 02 5c copy r4,ret0 16b8: e8 40 c0 00 bv r0(rp) 16bc: 4f c4 3f 81 ldw,mb -40(,sp),r4 000016c0 : int main(int argc, char *argv[]) { 16c0: 6b c2 3f d9 stw rp,-14(,sp) 16c4: 6f c4 00 80 stw,ma r4,40(,sp) int i = 0; for (i = 0; i < 10; i++) { 16c8: 20 81 00 00 ldil 2000,r4 16cc: 6b c3 3f 89 stw r3,-3c(,sp) 16d0: 34 03 00 00 ldi 0,r3 printf("%d\n", i); 16d4: 08 03 02 59 copy r3,r25 16d8: 34 9a 0e a8 ldo 754(r4),r26 16dc: e8 5f 1a 4d b,l 1408 <__init+0x24>,rp 16e0: 34 63 00 02 ldo 1(r3),r3 16e4: 8c 72 5f dd cmpib,>= 9,r3,16d8 16e8: 08 03 02 59 copy r3,r25 } moo(15); 16ec: e8 5f 1f 45 b,l 1694 ,rp 16f0: 34 1a 00 1e ldi f,r26 Ha look at this right here ^^^^^^^^^ The 15 parameter gets loaded right here, after the branch! Crazy return (0x0a); } 16f4: 4b c2 3f 59 ldw -54(,sp),rp 16f8: 4b c3 3f 89 ldw -3c(,sp),r3 16fc: 34 1c 00 14 ldi a,ret0 1700: e8 40 c0 00 bv r0(rp) 1704: 4f c4 3f 81 ldw,mb -40(,sp),r4 Here it goes again ^^^^^^^^^^^^^^^^^^ one more instruction after the branch.
I'll leave it to the reader to find the others.
pid_t
rfork_thread(int flags, void *stack, int (*func)(void *arg), void *arg);
Now I *only* need to figure out the following (give or take):
* function prologue * replace current stack with the one provided by rthread_fork * setup the rfork call on the new stack * call rfork * for the parent: - fix stack - function epilogue - return to caller * for the child - jump into thread - upon return call _exit()
Sometimes an itch should remain unscratched...
(Comments are closed)
By Anonymous Coward (134.58.253.131) on
Comments
By Anonymous Coward (195.224.109.30) on
By Anonymous Coward (64.180.110.15) on
By Anonymous Coward (212.99.198.91) on
By anon et al (80.213.134.72) on
What's needed is a proper thread implementation for the hppa,
Comments
By Marco Peereboom (67.64.89.177) wbx@openbsd-geek.de on http://openbsd-geek.de
By Ober (67.79.5.180) ober@linbsd.org on
By sand (80.181.228.129) daniel@spatof.org on http://www.spatof.org