Hi,
ok, this time I redid the patch to make paflof sane on 64bit platforms in a cleaner way, using abstracted defines that are dependent on certain platform specifics. As this is platform dependent stuff which has basically nothing to do with paflof itself, I moved it to a new file: machdep.h. I moved the sanity check out of paflof.c into machdep.c, which we will probably not need to link in case we know an architecture/compiler combination is sane.
We really need to make sure we are 64bit clean from the beginning so we recognize early what problems we might have to face getting paflof portable.
Segher, is this ok to check in from your side? If so, please do!
Stefan
Thank you for this.
I think I'll make it more general, though, with some perl script to test what sizes are available etc., and generating a header file from that info.
Don't be alarmed by the "cruft" in paflof.c anyway; it's just the unix-specific userland version; it is _allowed_ to contain filthy debugging stuff ;)
Btw, paflof compiles cleanly both on 32 and 64 bit systems now. Oh, and the 128-bit type is only needed on 64-bit hosts if double cell arithmetic is needed, and then only if that arithmetic _actually_ uses "big" values (i.e., we don't really have a problem here now :) )
I'll look into this some more...
Segher
Stefan Reinauer wrote:
Hi,
ok, this time I redid the patch to make paflof sane on 64bit platforms in a cleaner way, using abstracted defines that are dependent on certain platform specifics. As this is platform dependent stuff which has basically nothing to do with paflof itself, I moved it to a new file: machdep.h. I moved the sanity check out of paflof.c into machdep.c, which we will probably not need to link in case we know an architecture/compiler combination is sane.
We really need to make sure we are 64bit clean from the beginning so we recognize early what problems we might have to face getting paflof portable.
Segher, is this ok to check in from your side? If so, please do!
Stefan
-- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994)
paflof-machdep2.diffName: paflof-machdep2.diff Type: Plain Text (text/plain)
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
* Segher Boessenkool segher@chello.nl [020606 15:58]:
I think I'll make it more general, though, with some perl script to test what sizes are available etc., and generating a header file from that info.
Urghs. This develops autobuild like intelligence ;) Be aware that you can test machine specifics, not necessarily specifics of the same compiler. Though this could be done as well.
I had something in mind which does not need any external functionality but put everything to a seperate file so we don't need to mix forth implementation and platform adoptions.
Don't be alarmed by the "cruft" in paflof.c anyway; it's just the unix-specific userland version; it is _allowed_ to contain filthy debugging stuff ;)
ack. I guess I just like painting. ;)
Btw, paflof compiles cleanly both on 32 and 64 bit systems now. Oh, and the 128-bit type is only needed on 64-bit hosts if double cell arithmetic is needed, and then only if that arithmetic _actually_ uses "big" values (i.e., we don't really have a problem here now :) )
I know. But if we want to support IEEE 1275-1994 completely we will need this anyways and it might be worth it having this stuff working as soon as we have the compiler and fcode engine up and running. (which is probably not that far from now)
Stefan
I had something in mind which does not need any external functionality but put everything to a seperate file so we don't need to mix forth implementation and platform adoptions.
Unfotunately, we can't; we need to find out if the libgcc contains functions to divide TImode numbers, for example. So it'll have to be done outside of the normal compile.
I know. But if we want to support IEEE 1275-1994 completely we will need this anyways and it might be worth it having this stuff working as soon as we have the compiler and fcode engine up and running. (which is probably not that far from now)
Not far at all, not far at all... :)
Segher
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
* Segher Boessenkool segher@chello.nl [020607 02:25]:
I had something in mind which does not need any external functionality but put everything to a seperate file so we don't need to mix forth implementation and platform adoptions.
Unfotunately, we can't; we need to find out if the libgcc contains functions to divide TImode numbers, for example. So it'll have to be done outside of the normal compile.
Except we rely on compiler defines and prerequisites to get towards a defined build set (which probably sucks). If we have to use this functionality anyways, it might be interesting to look at autoconf. But then again we won't get rid of all perl stuff, so using autoconf just adds another player to the game. Just a dumb idea, could we rewrite the preprocessing and testing completely in C? I know that there are a lot of issues with perl on newer platforms, which could make it hard to get paflof running on new machines, even if we already have a gcc. Ugly though. If this is considerable, we don't want it before we have some systems actually booting.
I know. But if we want to support IEEE 1275-1994 completely we will need this anyways and it might be worth it having this stuff working as soon as we have the compiler and fcode engine up and running. (which is probably not that far from now)
Not far at all, not far at all... :)
Great work!
Stefan
Stefan Reinauer wrote:
- Segher Boessenkool segher@chello.nl [020607 02:25]:
I had something in mind which does not need any external functionality but put everything to a seperate file so we don't need to mix forth implementation and platform adoptions.
Unfotunately, we can't; we need to find out if the libgcc contains functions to divide TImode numbers, for example. So it'll have to be done outside of the normal compile.
Except we rely on compiler defines and prerequisites to get towards a defined build set (which probably sucks). If we have to use this functionality anyways, it might be interesting to look at autoconf. But then again we won't get rid of all perl stuff, so using autoconf just adds another player to the game.
Please let's not use autotools :)
Just a dumb idea, could we rewrite the preprocessing and testing completely in C? I know that there are a lot of issues with perl on
Nope, cpp can't do all that's necessary. Btw, once we have a working Forth compiler, we can use that to bootstrap itself :)
newer platforms, which could make it hard to get paflof running on new machines, even if we already have a gcc. Ugly though. If this is
Cross-compilers save the day :)
considerable, we don't want it before we have some systems actually booting.
I know. But if we want to support IEEE 1275-1994 completely we will need this anyways and it might be worth it having this stuff working as soon as we have the compiler and fcode engine up and running. (which is probably not that far from now)
Not far at all, not far at all... :)
Great work!
I hope to finish the "Forth command group" today :)
Segher
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..
-
Segher Boessenkool -
Stefan Reinauer