Re: Probing for Configurations
Thomas Seiler wrote: Couldn't we split the probing into two phases ? Let's asume for a moment that it's easy to build a miniparrot for ethier the host or the target. The first phase would run on the host and prepare the tests and a miniparrot for the target, but not run them. The seconde phase would run on the target and run the actual test, while populating a Configuration file. Host Phase: - Build host version of miniparrot - Build target version of miniparrot (use cross compiler) - Build all probing programms and test cases (use cross-compiler) - Populate a sub-directory with target miniparrot and the remaining test programms Target Phase: - Copy that directory to the target - Run the configuration phase and get the Config file The challange would be to get the miniparrot running on the target. All the rest should be covered by the normal Parrot Configuration Probing. This is about as general as it can get, or am I missing something ? The problem is that getting stuff on and off your target host is not always trivial. Typically, if you can do what you describe, you don't need to perform cross compilation: you can simply compile on your target (not always, sometimes you may want to build a couple different architectures at once, even if they are all unixy, or you may not have a compiler on the target (think Windows)). It is especially not true in the embedded world. Until I have parrot IO libraries, I am not going to be getting a whole lot out of the target. You could write the results in memory and then dump it, but ... well, it seems simpler to hand supply the config information. Trying to get answers from an embedded target is tricky and sometimes even potentially dangerous. Gregory Keeney Thomas Seiler
Re: Probing for Configurations
Gregory Keeney wrote: Thomas Seiler wrote: Couldn't we split the probing into two phases ? The problem is that getting stuff on and off your target host is not always trivial. [...] It is especially not true in the embedded world. Until I have parrot IO libraries, I am not going to be getting a whole lot out of the target. Yeah, thats true. I haven't tought about that because all the embedded systems we have touched in school had at least a serial port for debugging purposes, and it was a simple library call away. But I suppose that the serial port was part of the reason why they had chosen them... You could write the results in memory and then dump it, but ... well, it seems simpler to hand supply the config information. Trying to get answers from an embedded target is tricky and sometimes even potentially dangerous. You have convinced me that this is not going to work, too bad... Thanks, Thomas Seiler Gregory Keeney
Re: Probing for Configurations
On Thursday 09 September 2004 08:32 am, Gregory Keeney wrote: I don't think Parrot's probe system can help us here. Autoconf (as described above) uses the target architecture compiler's knowledge of the target system. We don't have anything equivalent, as we want to bootstrap the cross compiler through Parrot, not the C compiler. I suppose it depends upon what you mean by cross-compilation: (a) compiling the C parts of parrot on platform A so it can run on platform B, to JIT and run platform-independent bytecode. (b) compiling the C parts of parrot to run on platform A, but when run the parrot engine generates platform-dependent code for platform B. The autoconf thing I described helps with (a), but maybe not (b). I had assumed that you meant (a). Apologies if I was mistaken. Cheers, Rhys.
Re: Probing for Configurations
At 3:32 PM -0700 9/8/04, Gregory Keeney wrote:
Rhys Weatherley wrote:
What autoconf database? Autoconf uses probing for cross-compilation as well.
i.e. it runs the cross-compiler and sees what succeeds and what
fails. Some things are tricky, like detecting type sizes and
endianness, because you cannot run a program to printf the answer.
But there are ways around that described in the autoconf macro
archive:
http://www.gnu.org/software/ac-archive/
As an example, the size of a type can be determined by
cross-compiling several test programs that contain this:
switch (0)
{
case 0: case (sizeof ($type) == $size):;
}
where $size is iterated over 1 2 4 8 16, etc. All compilations
will fail with a duplicate case error except the size you are
looking for. Essentially, you use the cross-compiler's knowledge
of the platform to act as the database. You just need to be
clever in how you format the query.
Just an FYI. It's possible that Parrot's probe system could use a
similar mechanism for cross-compilation to avoid the need for
platform databases.
I don't think Parrot's probe system can help us here. Autoconf (as
described above) uses the target architecture compiler's knowledge
of the target system. We don't have anything equivalent, as we want
to bootstrap the cross compiler through Parrot, not the C compiler.
Right, but we'll be using the C compiler. The only way to probe for
this sort of stuff is to emit little test programs and compile them.
(Which can be problematic when cross-compiling, thought the tricks in
the archive are pretty nifty)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Probing for Configurations
Gregory Keeney wrote: Rhys Weatherley wrote: What autoconf database? Autoconf uses probing for cross-compilation as well. Essentially, you use the cross-compiler's knowledge of the platform to act as the database. You just need to be clever in how you format the query. I don't think Parrot's probe system can help us here. Autoconf (as described above) uses the target architecture compiler's knowledge of the target system. We don't have anything equivalent, as we want to bootstrap the cross compiler through Parrot, not the C compiler. Couldn't we split the probing into two phases ? Let's asume for a moment that it's easy to build a miniparrot for ethier the host or the target. The first phase would run on the host and prepare the tests and a miniparrot for the target, but not run them. The seconde phase would run on the target and run the actual test, while populating a Configuration file. Host Phase: - Build host version of miniparrot - Build target version of miniparrot (use cross compiler) - Build all probing programms and test cases (use cross-compiler) - Populate a sub-directory with target miniparrot and the remaining test programms Target Phase: - Copy that directory to the target - Run the configuration phase and get the Config file The challange would be to get the miniparrot running on the target. All the rest should be covered by the normal Parrot Configuration Probing. This is about as general as it can get, or am I missing something ? Thomas Seiler
