64 bit codes

64 bit codes

[Mok-Kong Shen]

The included gcc does not accept the -m64 option. Does this imply that
the ADA codes generated do not make full use of the 64 bit hardware?
(My PC runs Windows 7, 64 bit version.) Thanks.

M. K. Shen

Re: 64 bit codes

[Georg Bauhaus]

On 27.09.11 08:59, Mok-Kong Shen wrote:
> The included gcc does not accept the -m64 option.

Which one of the GNAT distributions for Windows(TM) do you have?

X:\> gcc -v
X:\> gnatls -v

are ways to learn about the compiler.

> Does this imply that
> the ADA codes generated do not make full use of the 64 bit hardware?

Does your GNAT accept

    type T is range 0 .. 2**40?

and does the generated code show use of the RAX registers
etc?

Side note: if GCC still does not permit switching the physical
size of pointers, then programs that use lots of pointers (in
the generated code, not necessarily in the Ada source text) might
be less efficient and waste CPU cache if all pointers are
64bit in size.

> (My PC runs Windows 7, 64 bit version.) Thanks.
>
> M. K. Shen

Re: 64 bit codes

[Mok-Kong Shen]

Am 27.09.2011 09:48, schrieb Georg Bauhaus:

> Which one of the GNAT distributions for Windows(TM) do you have?
>
> X:\> gcc -v
> X:\> gnatls -v
>
> are ways to learn about the compiler.

gcc -v gives among others:

COLLECT_LTO_WRAPPER=c:/gant/2011/bin/../libexec/gcc/i686-pc-mingw32/4.5.3/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with:  (lots of stuff, among them:)
     --build=i686-pc-mingw32  -enable-threads=win32
Thread model: win32
gcc version 4.5.3 20110428 for GNAT GPL 2011 <20110428> <GCC>

gnatls -v gives 2 paths:

C:/GNAT/2011/lib/gcc/i686-pc-mingw32/4.5.3/adainclude/

C:/GNAT/2011/lib/gcc/i686-pc-mingw32/4.5.3/adalib/

> Does your GNAT accept
>
> type T is range 0 .. 2**40?

yes (no complaint on compilation).

> and does the generated code show use of the RAX registers
> etc?

I am not familiar with how to examine the generated code. I should
be grateful, if you could further help me with the information above
in obtaining the answer to my question.

M. K. Shen



> Side note: if GCC still does not permit switching the physical
> size of pointers, then programs that use lots of pointers (in
> the generated code, not necessarily in the Ada source text) might
> be less efficient and waste CPU cache if all pointers are
> 64bit in size.
>
>> (My PC runs Windows 7, 64 bit version.) Thanks.

Re: 64 bit codes

[Ludovic Brenta]

Mok-Kong Shen wrote on comp.lang.ada:
> gcc -v gives among others:
[...]
> Target: i686-pc-mingw32
> Configured with:  (lots of stuff, among them:)
>      --build=i686-pc-mingw32  -enable-threads=win32
> Thread model: win32
> gcc version 4.5.3 20110428 for GNAT GPL 2011 <20110428> <GCC>

i686-pc-mingw32 means a strictly 32-bit compiler (specifically,
supporting all Intel processors since the Pentium II).  http://libre.adacore.com
does not seem to offer a 64-bit compiler for Windows.

--
Ludovic Brenta.
Our paradigm shifts boost a matrix.

Re: 64 bit codes

[Mok-Kong Shen]

Am 27.09.2011 11:14, schrieb Ludovic Brenta:
> Mok-Kong Shen wrote on comp.lang.ada:
>> gcc -v gives among others:
> [...]
>> Target: i686-pc-mingw32
>> Configured with:  (lots of stuff, among them:)
>>       --build=i686-pc-mingw32  -enable-threads=win32
>> Thread model: win32
>> gcc version 4.5.3 20110428 for GNAT GPL 2011<20110428>  <GCC>
>
> i686-pc-mingw32 means a strictly 32-bit compiler (specifically,
> supporting all Intel processors since the Pentium II).  http://libre.adacore.com
> does not seem to offer a 64-bit compiler for Windows.

Do you think it's appropriate to contact libre.adacore.com about that,
since 64-bit Windows systems is quite widespread now and it's thus
desirable that the hardware capability can be fully utilized with ADA
programming?

M. K. Shen

Re: 64 bit codes

[Ludovic Brenta]

Mok-Kong Shen wrote comp.lang.ada:
> Do you think it's appropriate to contact libre.adacore.com about that,
> since 64-bit Windows systems is quite widespread now and it's thus
> desirable that the hardware capability can be fully utilized with ADA
> programming?

You could always ask but, if history is any indication of the future,
I don't anticipate any changes before GNAT GPL 2012.

Out of curiosity, why do you need 64-bit support?  Does your program
require more than 2 GB of memory?  If so and if this is urgent, you
can use the 64-bit version of GNAT on another 64-bit operating system
such as Debian on your hardware...

--
Ludovic Brenta.
The customers culturally optimize a successful execution.

Re: 64 bit codes

[Mok-Kong Shen]

Am 27.09.2011 12:08, schrieb Ludovic Brenta:

> You could always ask but, if history is any indication of the future,
> I don't anticipate any changes before GNAT GPL 2012.
>
> Out of curiosity, why do you need 64-bit support?  Does your program
> require more than 2 GB of memory?  If so and if this is urgent, you
> can use the 64-bit version of GNAT on another 64-bit operating system
> such as Debian on your hardware...

I have some computations that would be much more efficient, if done
with 64-bit arithmetics ("natively") than with 32-bit arithmetics
and I don't like to take the trouble/"risk" of having a 2nd OS on my
PC (I don't think currently to possess even the proper knowledge to
do that at all).

On the other hand, as outsider I surmise that providing a 64-bit
Windows version doesn't involve much work, since there is already a
32-bit version. It's essentially just a replacement of the included
gcc from the 32-bit version to the 64-bit version, isn't it?

M. K. Shen

Re: 64 bit codes

[Ludovic Brenta]

Mok-Kong Shen wrote on comp.lang.ada:
> I have some computations that would be much more efficient, if done
> with 64-bit arithmetics ("natively") than with 32-bit arithmetics
> and I don't like to take the trouble/"risk" of having a 2nd OS on my
> PC (I don't think currently to possess even the proper knowledge to
> do that at all).

I'm not sure what you mean exactly by "64-bit arithmetic".  If you
require 64-bit addresses, then yes you need a 64-bit compiler.  But if
you only need 64-bit floating point numbers, the 32-bit compiler can
provide them just fine.  In fact, on Intel hardware, Long_Floats are
normally 80 bits wide IIRC.  Similarly, I think Long_Long_Integer is
64 bits wide even with a 32-bit compiler.

> On the other hand, as outsider I surmise that providing a 64-bit
> Windows version doesn't involve much work, since there is already a
> 32-bit version. It's essentially just a replacement of the included
> gcc from the 32-bit version to the 64-bit version, isn't it?

No, there is more to it than that.  Given that most of GNAT is written
in Ada, one requires a 64-bit Ada compiler to produce the first 64-bit
Ada compiler; that's the classic catch-22 aka bootstrapping process.
In the case of GNAT, this problem is exacerbated by the requirement to
also bootstrap the run-time library.

I see that GNAT Pro[1] supports 64-bit Windows; this means that they
have completed the bootstrapping process already.  So, if AdaCore tell
you that the GPL 2011 Edition simply won't support 64-bit, and you are
impatient, and really need a 64-bit version of GNAT, you should ask
AdaCore to provide GNAT Pro to you.

[1] http://www.adacore.com/home/products/gnatpro/supported_platforms/

--
Ludovic Brenta.

Re: 64 bit codes

[Georg Bauhaus]

On 27.09.11 15:09, Ludovic Brenta wrote:

> No, there is more to it than that.  Given that most of GNAT is written
> in Ada, one requires a 64-bit Ada compiler to produce the first 64-bit
> Ada compiler;

This will make the compiler itself be 64bit executables;
If I just want a compiler to produce 64bit executables,
any compiler will do:

$ arch
i386
$ file $(which gcc-4.0)
/usr/bin/gcc-4.0: Mach-O universal binary with 2 architectures
/usr/bin/gcc-4.0 (for architecture i386):	Mach-O executable i386
/usr/bin/gcc-4.0 (for architecture ppc7400):	Mach-O executable ppc
$ gcc-4.0 -m64 foo.c
$ file a.out
a.out: Mach-O 64-bit executable x86_64
$ ./a.out
-bash: ./a.out: Bad CPU type in executable

A 64bit compiler is not needed, just as none needs to run on a JVM
in order to produce Java byte code.
OTOH, I understand that the GNAT front end interact with the GCC
internals in non-trivial ways.

Re: 64 bit codes

[Mok-Kong Shen]

Am 27.09.2011 15:25, schrieb Georg Bauhaus:
> On 27.09.11 15:09, Ludovic Brenta wrote:
>
>> No, there is more to it than that.  Given that most of GNAT is written
>> in Ada, one requires a 64-bit Ada compiler to produce the first 64-bit
>> Ada compiler;
>
> This will make the compiler itself be 64bit executables;
> If I just want a compiler to produce 64bit executables,
> any compiler will do:
>
> $ arch
> i386
> $ file $(which gcc-4.0)
> /usr/bin/gcc-4.0: Mach-O universal binary with 2 architectures
> /usr/bin/gcc-4.0 (for architecture i386):	Mach-O executable i386
> /usr/bin/gcc-4.0 (for architecture ppc7400):	Mach-O executable ppc
> $ gcc-4.0 -m64 foo.c
> $ file a.out
> a.out: Mach-O 64-bit executable x86_64
> $ ./a.out
> -bash: ./a.out: Bad CPU type in executable
>
> A 64bit compiler is not needed, just as none needs to run on a JVM
> in order to produce Java byte code.
> OTOH, I understand that the GNAT front end interact with the GCC
> internals in non-trivial ways.

I tried the option -m64 on the gcc that is included in the ADA package,
but failed.

M. K. Shen

Re: 64 bit codes

[Mok-Kong Shen]

Am 27.09.2011 15:51, schrieb Mok-Kong Shen:

> I tried the option -m64 on the gcc that is included in the ADA package,
> but failed.

A related question: Could anyone tell how to install the gnu gcc as 
such? I see there is only one single file "gcc-4.6.1.tar" on the
download sites and everything, in particular modules specific for all
possible kinds of hardware, must therefore be in there and presumably
it would consequently be very difficult to figure out how to properly
proceed in order to obtain a compiler running on one's computer.

M. K. Shen

Re: 64 bit codes

[Ludovic Brenta]

Mok-Kong Shen wrote on comp.lang.ada:
>> I tried the option -m64 on the gcc that is included in the ADA package,
>> but failed.
>
> A related question: Could anyone tell how to install the gnu gcc as
> such? I see there is only one single file "gcc-4.6.1.tar" on the
> download sites and everything, in particular modules specific for all
> possible kinds of hardware, must therefore be in there and presumably
> it would consequently be very difficult to figure out how to properly
> proceed in order to obtain a compiler running on one's computer.

If you're going to build gnat for yourself, you should read [1].  In
summary: the "gcc" executable is only the "compiler driver"; it calls
the actual compiler for each source file, choosing the actual compiler
based on:

- the source language (Ada, C, C++, Fortran, Objective-C, Go, Java,
etc.)
- the target platform as specified with -m64 or other options

Hence the name "GNU Compiler Collection".

Therefore, for one host you can have M*N compilers, where M is the
number of programming languages supported and N is the number of
target platforms supported.  Georg happens to have 3 Ada compilers
installed on his Mac OS X machine (and probably as many C, C++ and
Objective-C compilers) but you're not so lucky.  GNAT GPL Edition only
comes with native compilers for C, Ada and possibly C++.

In theory, it should be possible to rebuild a 64-bit GNAT GPL Edition
from source by following the given instructions.  You'd first build a
cross-compiler (from 32-bit to 64-bit, making the -m64 option work)
then possibly a native 64-bit compiler.  That requires time and skills
because of all the needed tools.  If you succeed, I'd recommend
sharing the results of your work through the GNU Ada Project[2] on
SourceForge, which does not provide a 64-bit GNAT for Windows yet.
But I still think that installing a secondary operating system such as
Debian in a virtual machine would be less difficult than building GNAT
from source, especially on Windows.

[1] http://gcc.gnu.org/install/
[2] http://sourceforge.net/projects/gnuada/

--
Ludovic Brenta.

Re: 64 bit codes

[Mok-Kong Shen]

Am 27.09.2011 15:09, schrieb Ludovic Brenta:
> Mok-Kong Shen wrote on comp.lang.ada:
>> I have some computations that would be much more efficient, if done
>> with 64-bit arithmetics ("natively") than with 32-bit arithmetics
>> and I don't like to take the trouble/"risk" of having a 2nd OS on my
>> PC (I don't think currently to possess even the proper knowledge to
>> do that at all).
>
> I'm not sure what you mean exactly by "64-bit arithmetic".  If you
> require 64-bit addresses, then yes you need a 64-bit compiler.  But if
> you only need 64-bit floating point numbers, the 32-bit compiler can
> provide them just fine.  In fact, on Intel hardware, Long_Floats are
> normally 80 bits wide IIRC.  Similarly, I think Long_Long_Integer is
> 64 bits wide even with a 32-bit compiler.

On 32-bit gcc, arithmetic operations (+, *, etc.) on "unsigned long
long int" certainly all work, but it's inefficient. Anyway the runtime,
as I have observed in the past, is much higher than I would expect.
For lack of knowledge I have not attempted to see the actual code
generated, but I suppose that's done with the help of some low-level
macros. (By definition, there aren't 64-bit arithmetic instructions on
32-bit hardware.) For on 64-bit hardware a native 64-bit arithmetic
operation shouldn't last very much longer than a corresponding 32-bit
opeartion, I would think.

M. K. Shen

Re: 64 bit codes

[Ludovic Brenta]

Mok-Kong Shen wrote on comp.lang.ada:
> For on 64-bit hardware a native 64-bit arithmetic
> operation shouldn't last very much longer than a corresponding 32-bit
> opeartion, I would think.

Only a benchmark can tell.  It is true that individual 64-bit machine
instructions are usually just as fast as their 32-bit counterparts but
64-bit words use up twice as much memory and, especially, cache memory
as 32-bit words.  The 64-bit ISA has 16 extra registers that may or
may not compensate for the increased cache pressure and decreased code
locality in your particular case.

--
Ludovic Brenta.

Re: 64 bit codes

[Bill Findlay]

On 27/09/2011 15:50, in article
cec56016-8606-484b-810b-3cdf1e0fcc48@v9g2000vbp.googlegroups.com, "Ludovic
Brenta" <ludovic@ludovic-brenta.org> wrote:

> Mok-Kong Shen wrote on comp.lang.ada:
>> For on 64-bit hardware a native 64-bit arithmetic
>> operation shouldn't last very much longer than a corresponding 32-bit
>> opeartion, I would think.
> 
> Only a benchmark can tell.  It is true that individual 64-bit machine
> instructions are usually just as fast as their 32-bit counterparts but
> 64-bit words use up twice as much memory and, especially, cache memory
> as 32-bit words.  The 64-bit ISA has 16 extra registers that may or
> may not compensate for the increased cache pressure and decreased code
> locality in your particular case.

My KDF9 emulator is speeded up by a factor of *more than* two by 64-bit
mode.  This is because its integer and logical operands are predominantly
more than 32 bits in size.  Pointers are used, but form a negligible part of
the storage space and computational effort.

So, while your caveats are of course valid, there certainly are workloads
that benefit greatly from working in 64 bits.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: 64 bit codes

[Georg Bauhaus]

On 27.09.11 17:49, Bill Findlay wrote:

> So, while your caveats are of course valid, there certainly are workloads
> that benefit greatly from working in 64 bits.

IBM confirms:

"64 bit register use in 32 bit applications: GCC will exploit the
 availability of 64 bit registers in 32 bit applications when compiling
 with -m31 -mzarch. This provides a significant performance gain for 32
 bit applications built this way. The versions of the Linux Kernel,
 GNU Binutils, GNU C Library and GDB as documented here provide the
 support required by this GCC feature."

http://www.ibm.com/developerworks/linux/linux390/toolchain.html

I hadn't known that there are 31-bit systems and correspondingly,
a -m31 switch for GCC. Wow.

Re: 64 bit codes

[Ludovic Brenta]

Georg Bauhaus wrote on comp.lang.ada:
> On 27.09.11 17:49, Bill Findlay wrote:
>> So, while your caveats are of course valid, there certainly are workloads
>> that benefit greatly from working in 64 bits.
>
> IBM confirms:
>
> "64 bit register use in 32 bit applications: GCC will exploit the
>  availability of 64 bit registers in 32 bit applications when compiling
>  with -m31 -mzarch. This provides a significant performance gain for 32
>  bit applications built this way. The versions of the Linux Kernel,
>  GNU Binutils, GNU C Library and GDB as documented here provide the
>  support required by this GCC feature."
>
> http://www.ibm.com/developerworks/linux/linux390/toolchain.html
>
> I hadn't known that there are 31-bit systems and correspondingly,
> a -m31 switch for GCC. Wow.

S/370-XA (introduced 1983) and subsequent IBM mainframes had 31-bit
address and 32-bit data buses.  The addresses were really 32-bit, of
course, but one bit is reserved to distinguish 31-bit addresses from
24-bit (!) addresses for compatibility with the earlier S/360 and S/
370 architectures.  Each process thus has a 2 GiB address space.  The
entire system can have much more than that in physical RAM, of course.

The mainframes moved to full 64-bit support (z/Architecture) in 2000
but the 31-bit/24-bit mode still exists for backward compatibility.
The quote from IBM clearly applies only to these later (current)
mainframes, as the earlier ones did not even have 64-bit registers.
Hence the requirement for "-mzarch" in addition to the "-m31".

BTW, I never disputed that the use of 64-bit registers improved
performance.  What I claimed was this performance gain might be
offset, in whole or in part, by losses in cache hit rates and higher
memory bandwidth requirements.  Sun Microsystems moved to full 64-bit
support as early as 1995 but used to recommend that applications be
compiled in 32-bit mode, unless they required more than 4 GiB of
memory, for this reason.  The kernel was of course 64-bit.

--
Ludovic Brenta.

Re: 64 bit codes

[Rugxulo]

Hi,

On Sep 27, 8:48 am, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>
> On 32-bit gcc, arithmetic operations (+, *, etc.) on "unsigned long
> long int" certainly all work, but it's inefficient. Anyway the runtime,
> as I have observed in the past, is much higher than I would expect.
> For lack of knowledge I have not attempted to see the actual code
> generated, but I suppose that's done with the help of some low-level
> macros. (By definition, there aren't 64-bit arithmetic instructions on
> 32-bit hardware.) For on 64-bit hardware a native 64-bit arithmetic
> operation shouldn't last very much longer than a corresponding 32-bit
> opeartion, I would think.

So you want better speed? Well, assuming it's even possible and you
haven't reached a dead end, I imagine you have several realistic
options:

* use different compiler switches
* use faster algorithms
* use "better" (supported) compiler
* use vectorization
* use (tiny bits of) assembly
* use "better" (supported) OS
* use "better" (supported) language

(I'm not being facetious here, I'm really trying to help. But this is
a bit too naive an attempt I suppose.)

* -mtune=native -O3
* http://seed7.sourceforge.net/algorith/index.htm
* http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/
(or) http://www.atego.com/support/eval-aonix-objectada/
* -ftree-vectorize
* http://board.flatassembler.net/topic.php?t=7852&start=9
* https://fedorahosted.org/liveusb-creator/
(or) https://www.virtualbox.org/
* http://sourceforge.net/projects/freepascal/files/Win32/2.4.4/fpc-2.4.4.x86_64-win64.exe/download

P.S. I'm not on Win64 right now, so I can't honestly say I've tested
MinGW-64 / Ada there (assuming it exists, oops). But here's
hoping.  ;-)

Re: 64 bit codes

[Rugxulo]

Hi again,

On Sep 27, 7:38 pm, Rugxulo <rugx...@gmail.com> wrote:
>
> On Sep 27, 8:48 am, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
>
> > On 32-bit gcc, arithmetic operations (+, *, etc.) on "unsigned long
> > long int" certainly all work, but it's inefficient. Anyway the runtime,
> > as I have observed in the past, is much higher than I would expect.
> > For lack of knowledge I have not attempted to see the actual code
> > generated, but I suppose that's done with the help of some low-level
> > macros. (By definition, there aren't 64-bit arithmetic instructions on
> > 32-bit hardware.) For on 64-bit hardware a native 64-bit arithmetic
> > operation shouldn't last very much longer than a corresponding 32-bit
> > opeartion, I would think.
>
> So you want better speed? Well, assuming it's even possible and you
> haven't reached a dead end, I imagine you have several realistic
> options:
>
> * use "better" (supported) compiler
>
> *http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetti...
>
> P.S. I'm not on Win64 right now, so I can't honestly say I've tested
> MinGW-64 / Ada there (assuming it exists, oops). But here's
> hoping.  ;-)

Well, they (MinGW-w64) do mention Ada on their website, but apparently
the only Ada toolset(s) from them are Cygwin-hosted (i.e., installed
via Cygwin's setup.exe) and apparently rarely used by them. So the
Win64-targeted version (GCC 4.5.3-3) doesn't work (fails to link,
undefined reference to gnat_eh_blahblah in libgnat.a), yet the i686
(32-bit) one works fine (only tested simple "hello world"). I've filed
a bug report on SourceForge.

Not exactly what you wanted to hear, but better than nothing.   ;-)

Re: 64 bit codes

[Pascal Obry]

Le 29/09/2011 19:08, Rugxulo a �crit :
> Not exactly what you wanted to hear, but better than nothing.   ;-)

So at this stage I would follow Ludovic advice, format your hard drive, 
wipe-out Windows and install GNU/Debian. From there a simple apt-get 
will install the compiler for you.  Live Free!

Pascal.
   PS: I understand that this message is a bit provocative :)

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: 64 bit codes

[Ludovic Brenta]

Pascal Obry writes on comp.lang.ada:
> Le 29/09/2011 19:08, Rugxulo a écrit :
>> Not exactly what you wanted to hear, but better than nothing.   ;-)
>
> So at this stage I would follow Ludovic advice, format your hard
> drive, wipe-out Windows and install GNU/Debian. From there a simple
> apt-get will install the compiler for you.  Live Free!
>
> Pascal.
>   PS: I understand that this message is a bit provocative :)

Pascal and I are radicals :) the only time I ever bought a Windows
license was as part of OS/2 3.0 in 1994 or so.  Since then I've only
ever bought computers without an operating system installed :)

Anyway, you can install Debian on Windows, see Cooperative Linux[1] and
various virtual machine solutions.  You do not need to wipe out your
hard drive.

[1] http://www.colinux.org/

-- 
Ludovic Brenta.

Re: 64 bit codes

[Pascal Obry]

Ludovic,

> Pascal and I are radicals :) the only time I ever bought a Windows
> license was as part of OS/2 3.0 in 1994 or so.  Since then I've only
> ever bought computers without an operating system installed :)

I did had a refund for a Windows on a Dell computer some years ago :)

I must admit that I still have a dual boot with a windows partition on 
one of my computers just for running Lightroom. As a photographer I 
can't find an attractive solution on GNU/Linux. I would pay twice the 
price to have Lightroom on GNU/Linux, but Adobe still ignore this 
platform. I'm following closely Darktable which is very promising. 
Anyway, this is OT :)

> Anyway, you can install Debian on Windows, see Cooperative Linux[1] and
> various virtual machine solutions.  You do not need to wipe out your
> hard drive.
>
> [1] http://www.colinux.org/

This is a very nice project, I did run Colinux on a Windows machine at 
some point. But, last time I looked, this was only supported with a x86 
kernel, no x86_64.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: 64 bit codes

[Pascal Obry]

Le 29/09/2011 21:35, Pascal Obry a écrit :
> This is a very nice project, I did run Colinux on a Windows machine at
> some point. But, last time I looked, this was only supported with a x86
> kernel, no x86_64.

And also only on Windows 32bits and not on Windows 64bits. So even on 
Windows 64bits you could not run Colinux with an x86 kernel.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: 64 bit codes

[mjamesb]

>> P.S. I'm not on Win64 right now, so I can't honestly say I've tested
>> MinGW-64 / Ada there (assuming it exists, oops). But here's
>> hoping.  ;-)
>
> Well, they (MinGW-w64) do mention Ada on their website, but apparently
> the only Ada toolset(s) from them are Cygwin-hosted (i.e., installed
> via Cygwin's setup.exe) and apparently rarely used by them. So the
> Win64-targeted version (GCC 4.5.3-3) doesn't work (fails to link,
> undefined reference to gnat_eh_blahblah in libgnat.a), yet the i686
> (32-bit) one works fine (only tested simple "hello world"). I've filed
> a bug report on SourceForge.
>
> Not exactly what you wanted to hear, but better than nothing.   ;-)

MinGW-w64 "Ada support" thread at:

  http://sourceforge.net/projects/mingw-w64/forums/forum/723797/topic/4368923

has follow-up pointing to:

  http://ya-mingw64.sourceforge.net/

With this, gnatmake compiles HelloWorld which executes successfully as 64-bit on 64-bit Win7.

Yay!

  - mjamesb

Re: 64 bit codes

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> No, there is more to it than that.  Given that most of GNAT is written
> in Ada, one requires a 64-bit Ada compiler to produce the first 64-bit
> Ada compiler; that's the classic catch-22 aka bootstrapping process.
> In the case of GNAT, this problem is exacerbated by the requirement to
> also bootstrap the run-time library.

I built an x86_64 compiler for Darwin using an i386 (32-bit) compiler;
no trouble at all.

Not going to try it for Windows, though!

Re: 64 bit codes

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> I built an x86_64 compiler for Darwin using an i386 (32-bit) compiler;
> no trouble at all.

That would be exaggerating. I had quite a few problems, though my log
seems to indicate that things were worse when I said
--target=x86_64-apple-darwin10.2.0 (for cross-compilation) rather than
just --build=x86_64-apple-darwin10.2.0.

I see I built a 32-bit GNAT GPL 2009 for the GNU Ada Sourceforge project
as well as a 64-bit one; I can't now recall why I did the first (I
suspect because Tk was only supported in 32-bit), and I think I did the
second because AdaCore's didn't work on Snow Leopard because of an Apple
change to exception unwinding.

So I just now d/l'd the 2009 32-bit compiler and used it to build GCC
4.6.1, configuring like so:

  ./gcc-4.6.1/configure \
    CC="gcc -D_FORTIFY_SOURCE=0" \
    --prefix=/opt/gcc-4.6.1 \
    --disable-multilib \
    --enable-languages=c,ada \
    --build=x86_64-apple-darwin11

(gmp, mpfr, mpc are symlinked from the GCC tree; the setting of CC is
because of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342)

and sure enough pointers are now 64-bit, as expected.

I'm pretty sure this only works because Apple's binutils are 32- and
64-bit capable.

Re: 64 bit codes

[Georg Bauhaus]

On 27.09.11 21:13, Simon Wright wrote:

> I see I built a 32-bit GNAT GPL 2009 for the GNU Ada Sourceforge project
> as well as a 64-bit one; I can't now recall why I did the first

A 32-bit GNAT works on older Macs that don't have a 64 bit CPU,
such as a Core Solo or Core Duo.  Good to have one.

Re: 64 bit codes

[Fritz Wuehler]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:

> A 32-bit GNAT works on older Macs that don't have a 64 bit CPU,
> such as a Core Solo or Core Duo.  Good to have one.

As far as I know, all the Core Duos are 64 bit. I have several Core Duo
boxes all running 64 bit OS. Never heard of Core Solo though.

Re: 64 bit codes

[Yannick Duchêne (Hibou57)]

Le Wed, 28 Sep 2011 14:26:25 +0200, Fritz Wuehler  
<fritz@spamexpire-201109.rodent.frell.theremailer.net> a écrit:
> As far as I know, all the Core Duos are 64 bit. I have several Core Duo
> boxes all running 64 bit OS. Never heard of Core Solo though.

At least, mine is 32 bits only (DELL Inspiron 9400 with Intel Core Duo)


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: 64 bit codes

[Georg Bauhaus]

On 28.09.11 14:26, Fritz Wuehler wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:
> 
>> A 32-bit GNAT works on older Macs that don't have a 64 bit CPU,
>> such as a Core Solo or Core Duo.  Good to have one.
> 
> As far as I know, all the Core Duos are 64 bit. I have several Core Duo
> boxes all running 64 bit OS. Never heard of Core Solo though.

No, the Core 2 Duos are 64 bit, the Core Duos aren't.

http://en.wikipedia.org/wiki/Intel_Core#Enhanced_Pentium_M_based


$ /opt/gnat.2009/bin/gcc
-bash: /opt/gnat.2009/bin/gcc: Bad CPU type in executable


$ file /opt/gnat.2009/bin/gcc
/opt/gnat.2009/bin/gcc: Mach-O 64-bit executable x86_64


$ system_profiler -detailLevel mini SPHardwareDataType
Hardware:

    Hardware Overview:

      Model Name: Mac mini
      Model Identifier: Macmini1,1
      Processor Name: Intel Core Duo
      Processor Speed: 1,66 GHz
      Number Of Processors: 1
      Total Number Of Cores: 2
      L2 Cache: 2 MB
      Memory: 2 GB
      Bus Speed: 667 MHz
      Boot ROM Version: MM11.0055.B08
      SMC Version (system): 1.3f4


ioreg then shows

"firmware-abi" = <"EFI32">