Cross-compiler

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Cross-compiler

Tim Maxwell
Hi,

Attached are modified versions of ldump.c, lundump.h, and luac.c to allow for cross-compilation. They should work as drop-in replacements. I've done some basic testing, but I only have access to one architecture so I can't test endianness.

This code lets you specify:
* the endianness of the target platform
* the size of int as 8, 16, or 32 (no 64-bit support right now)
* lua_Number as an int (8, 16, or 32 bits) or a float (32 or 64 bits)

ldump.c exports a new function called "luaU_dump_crosscompile" that works like luaU_dump except that it takes a DumpTargetInfo structure.

luaU_dump_crosscompile supports different sizes of size_t but luac does not allow it to be set from the command line. Are there any targets where sizeof(int) is different from sizeof(size_t)?

This code assumes that 'float' is a standard 32-bit float and 'double' is a standard 64-bit double. It will trip a lua_assert if lua_Number is not integer but sizeof(lua_Number) is not 32 or 64. Is that portable enough?

Tim Maxwell

Attachment: ldump.c
Description: Binary data

Attachment: luac.c
Description: Binary data

Attachment: lundump.h
Description: Binary data

Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

Luiz Henrique de Figueiredo
> Attached are modified versions of ldump.c, lundump.h, and luac.c to  
> allow for cross-compilation.

I haven't tested it but it's nice to see actual code...

> This code lets you specify:
> * the endianness of the target platform
> * the size of int as 8, 16, or 32 (no 64-bit support right now)
> * lua_Number as an int (8, 16, or 32 bits) or a float (32 or 64 bits)

When I thought once about adding support for cross-compilation in luac,
I intended to do it via a string like this one:
          "I2,S4,NR4,EB"
which means that the target machine has 2-byte integers, 4-byte size_t,
number is 4-byte real, endianness is big-endian. A 32-bit machine with
longs could be
          "I4,S4,NI4,EN"
Endianness here is "native", but any omitted spec means "native".
You get the idea...

This would simplify the interface between luac.c and ldump.c because luac.c
could simply hand that string to ldump.c and the DumpTargetInfo would not
have to be exposed. The DumpState would contain all that info.

Furthermore, we'd be able to collect a list of cross-compilation strings
for common platforms. And the strings are self-documented.

Now, do you intend to be able to load cross-compiled chunks in luac as
well, so that luac could output native chunks from those?

> ldump.c exports a new function called "luaU_dump_crosscompile" that  
> works like luaU_dump except that it takes a DumpTargetInfo structure.

I'd call it luaU_xdump...
 
> luaU_dump_crosscompile supports different sizes of size_t but luac  
> does not allow it to be set from the command line. Are there any  
> targets where sizeof(int) is different from sizeof(size_t)?

Old DOS compilers used to have medium and large models, in which
sizeof(int) was different from sizeof(size_t), I guess, because
in large models one would be able to address "far" data.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

Tim Maxwell
When I thought once about adding support for cross-compilation in luac,
I intended to do it via a string like this one:
          "I2,S4,NR4,EB"
which means that the target machine has 2-byte integers, 4-byte size_t,
number is 4-byte real, endianness is big-endian. A 32-bit machine with
longs could be
          "I4,S4,NI4,EN"
Endianness here is "native", but any omitted spec means "native".
You get the idea...

This would simplify the interface between luac.c and ldump.c because luac.c could simply hand that string to ldump.c and the DumpTargetInfo would not
have to be exposed. The DumpState would contain all that info.

I don't like this because ldump.c would have to parse the string. What if there were syntax errors in the string? If ldump's parser had good error handling, it would be bulkier than the current system. If it didn't, then compiler users would have to deal with cryptic "bad target machine info" messages. The current system builds a DumpTargetInfo from command-line arguments to luac, which works very well. The option parser is only about twenty lines long and it produces informative error messages. I don't see how it could be done so easily if ldump.c parsed format strings. ldump would have to hand parse error codes back to luac, which would be messy. Furthermore, when the parser is in luac the Lua core doesn't have to carry the extra code.

I don't think it's a bad thing for DumpTargetInfo to be exposed. Like luaU_print, it's only exposed to luac. Perhaps it should be called "lua_DumpTargetInfo"?

Furthermore, we'd be able to collect a list of cross-compilation strings
for common platforms. And the strings are self-documented.

The same works for command-line flags. The default build on Mac OS Intel is "-cci 32 -ccn float 64 -cce little".

Now, do you intend to be able to load cross-compiled chunks in luac as
well, so that luac could output native chunks from those?

That would only be useful if people had compiled binaries but no source code for some reason. I don't think that's a very common use case.

I'd call it luaU_xdump...

Sure.

Old DOS compilers used to have medium and large models, in which
sizeof(int) was different from sizeof(size_t), I guess, because
in large models one would be able to address "far" data.

Are we supporting cross-compilation to old DOS compilers? That's the only case where it would make a difference. If luac itself is running on the old DOS compiler it will produce the correct code. In any case, a "-ccs" flag could be added in about five lines of code.

Tim


Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

KHMan
Tim Maxwell wrote:
[snip snip]
Old DOS compilers used to have medium and large models, in which
sizeof(int) was different from sizeof(size_t), I guess, because
in large models one would be able to address "far" data.

Are we supporting cross-compilation to old DOS compilers? That's the only case where it would make a difference. If luac itself is running on the old DOS compiler it will produce the correct code. In any case, a "-ccs" flag could be added in about five lines of code.

Wouldn't the assumption sizeof(int)==sizeof(size_t) fail on LP64 and LLP64 models?

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

David Jones-2
In reply to this post by Tim Maxwell

On 12 Aug 2008, at 02:38, Tim Maxwell wrote:

Hi,

Attached are modified versions of ldump.c, lundump.h, and luac.c to allow for cross-compilation. They should work as drop-in replacements. I've done some basic testing, but I only have access to one architecture so I can't test endianness.

This code lets you specify:
* the endianness of the target platform
* the size of int as 8, 16, or 32 (no 64-bit support right now)
* lua_Number as an int (8, 16, or 32 bits) or a float (32 or 64 bits)

ldump.c exports a new function called "luaU_dump_crosscompile" that works like luaU_dump except that it takes a DumpTargetInfo structure.

luaU_dump_crosscompile supports different sizes of size_t but luac does not allow it to be set from the command line. Are there any targets where sizeof(int) is different from sizeof(size_t)?

Plenty.

Almost every C compiler for processors where a 16-bit int made sense (PDP, MC68000, Intel) had a 16-bit int and a 32-bit size_t. Some C compilers for 64-bit processors have 32-bit int and 64-bit size_t. Quite possibly some embedded ARMs have compiler modes where int is 16- bit because it fits better with an external RAM bus and it feels more "embedded".

All the world's a VAX.


This code assumes that 'float' is a standard 32-bit float and 'double' is a standard 64-bit double. It will trip a lua_assert if lua_Number is not integer but sizeof(lua_Number) is not 32 or 64. Is that portable enough?

Probably.  For now.

drj

Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

Tony Finch
In reply to this post by Tim Maxwell
On Mon, 11 Aug 2008, Tim Maxwell wrote:
>
> This code assumes that 'float' is a standard 32-bit float and 'double' is a
> standard 64-bit double. It will trip a lua_assert if lua_Number is not integer
> but sizeof(lua_Number) is not 32 or 64. Is that portable enough?

Older ARMs that use the FPA instructions store doubles with the most
significant word at the lower address even when running in little-endian
mode (i.e. they are middle-endian). In more recent VFP ARMs the word order
of doubles follows the machine's endianness.

Tony.
-- 
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
FAIR ISLE FAEROES: EASTERLY 4 BACKING NORTHERLY 5 TO 7. MODERATE OR ROUGH.
OCCASIONAL RAIN. MODERATE OR GOOD.

Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

Tim Maxwell
Tony Finch wrote:
Older ARMs that use the FPA instructions store doubles with the most
significant word at the lower address even when running in little- endian mode (i.e. they are middle-endian). In more recent VFP ARMs the word order
of doubles follows the machine's endianness.

How can I detect if the running machine has middle-endian floats?

Which of the following byte orders do you mean?
A: 5 6 7 8   1 2 3 4
B: 7 8 5 6   3 4 1 2

Tim Maxwell



Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

Javier Guerra Giraldez
On Tue, Aug 12, 2008 at 2:35 PM, Tim Maxwell <[hidden email]> wrote:
> Which of the following byte orders do you mean?
> A: 5 6 7 8   1 2 3 4
> B: 7 8 5 6   3 4 1 2

I'd rule out B, since that would come out of a 16-bit little-endian
CPU with big-endian arrangement of words.  AFAIK, ARM switches
endianness on 32-bit longs: 1234 - 4321, so the non-unreasonable
orders would be:

BB: 8765-4321
LB: 5678-1234
BL: 4321-8765
LL: 1234-5678

where BB means BE-CPU, BE-software; LB is LE-CPU, BE-software; etc.

both LB and BL could be called 'middle endian'


-- 
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

Jerome Vuarand
In reply to this post by KHMan
2008/8/12, KHMan <[hidden email]>:
> Tim Maxwell wrote:
> > [snip snip]
> >
> > > Old DOS compilers used to have medium and large models, in which
> > > sizeof(int) was different from sizeof(size_t), I guess, because
> > > in large models one would be able to address "far" data.
> > >
> >
> > Are we supporting cross-compilation to old DOS compilers? That's the only
> case where it would make a difference. If luac itself is running on the old
> DOS compiler it will produce the correct code. In any case, a "-ccs" flag
> could be added in about five lines of code.
> >
>
> Wouldn't the assumption sizeof(int)==sizeof(size_t) fail on LP64 and LLP64
> models?

Windows x64 have a 32 bits int and a 64 bits size_t. I don't remember
if it's LP64 or LLP64 though.

Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

Tony Finch
In reply to this post by Tim Maxwell
On Tue, 12 Aug 2008, Tim Maxwell wrote:
>
> How can I detect if the running machine has middle-endian floats?

Store a floating point number and analyse the byte string.
For example, the laout of 1.0 can be:

byte   LE   BE   ARM FPA
   0 : 00 : 3F : 00
   1 : 00 : F0 : 00
   2 : 00 : 00 : F0
   3 : 00 : 00 : 3F
   4 : 00 : 00 : 00
   5 : 00 : 00 : 00
   6 : F0 : 00 : 00
   7 : 3F : 00 : 00


> Which of the following byte orders do you mean?
> A: 5 6 7 8   1 2 3 4

This one.

Tony.
-- 
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
LUNDY FASTNET: WESTERLY 5 TO 7, OCCASIONALLY GALE 8 AT FIRST, DECREASING 4 OR
5. ROUGH OR VERY ROUGH, BECOMING MODERATE OR ROUGH. SQUALLY SHOWERS. GOOD.

Reply | Threaded
Open this post in threaded view
|

Re: Cross-compiler

Dave Dodge
In reply to this post by Jerome Vuarand
On Wed, Aug 13, 2008 at 01:42:03AM +0200, Jerome Vuarand wrote:
> Windows x64 have a 32 bits int and a 64 bits size_t. I don't remember
> if it's LP64 or LLP64 though.

Win64 is LLP64.  In comparison, 64-bit Unix is pretty much entirely LP64.

                                                  -Dave Dodge