[CFARM] New AMD donated Magny-Cours system with 24 1.5 GHz cores and 64 GB RAM
Hi, I'm pleased to announce that AMD (1) donated two 12-cores Magny-Cours processors running at 1.5 GHz to the GCC Compile Farm project (2) and that FSF France (3) funded the purchase of the rest of the machine, including 64GB of RAM, 2TB of disk and 80 GB of SSD. The machine, named gcc10, has been running fine for over a month now, about 50 users of the farm have logged in at least once on the machine. Many thanks to the following people and organisation who made this possible: - Sebastian Pop, Christophe Harle and David Harmon of AMD for donating the two processors. - FSF France for approving the funding of the rest of the machine, providing the hosting and doing the paperwork. - Maxence Dunnewind for machine install and maintenance. AMD already donated two years ago two bi-quad core machines (4), gcc16 and gcc17, so let me thank AMD again for the continued support of the farm project as its user base grows, now nearing 200 accounts. Sincerely, Laurent (1) http://www.amd.com/ (2) http://gcc.gnu.org/wiki/CompileFarm (3) http://fsffrance.org/ (4) http://gcc.gnu.org/news.html (May 22, 2008)
Help for target with BITS_PER_UNIT = 16
Hello all,
I am trying to port GCC 4.5.1 for a processor that has the following
addressing capability:
The data memory address space of 64K bytes is represented by a total
of 15 bits, with each address selecting a 16-bit element. When using
the address register, the LSB of address reg (AD) points to a 16-bit
field in data memory. If a data memory line is 128 bits there are 8,
16-bit elements per data memory line. We use little endian addressing,
so
if AD=0, bits [15:0] of data memory line address 0 would be selected.
If AD=1, bits [31:16] of data memory line address 0 would be selected.
If AD=9, bits [31:16] of data memory line address 1 would be selected.
So if i have the following program
short arr[5] = {11,12,13,14,15};
int foo ()
{
short a = arr[0] + arr[3];
return a;
}
Assume that short is 16bits and short address is 2byte aligned.Then I
expect the following code to get generated:
mov a0,#arr // Load the address
mov a1, a0 // Copy the address
add a1, 1 // Increment the location by 1 so that the address
points to arr[1]
ld.16 g0, (a1) // Load the value 12 into g0
mov a1, a0 // Copy the address
add a1, 3 // Increment the location by 3 so that the address
points to arr[3]
ld.16 g1, (a1) // Load the value 14 into g0
add g1, g1, g0 // Add 12 and 14
For the following code:
short arr[5] = {11,12,13,14,15};
int foo ()
{
short a,b;
a = (short) (&arr[3] - &arr[1]); // a is 2 after this operation
b = (short) ((char*)&arr[3] - (char*)&arr[1]); // b is 4 after this operation
return a;
}
My question is should i set the macro BITS_PER_UNIT = 16 to get a code
generated like this? From IRC chat i realize that BITS_PER_UNIT != 8
is seriously rotten. If that is the case how can i proceed to port
this target?
Regards,
Shafi
Re: Help for target with BITS_PER_UNIT = 16
Hi,
On Mon, 16 Aug 2010, Mohamed Shafi wrote:
> Hello all,
>
> I am trying to port GCC 4.5.1 for a processor that has the following
> addressing capability:
>
> The data memory address space of 64K bytes is represented by a total
> of 15 bits, with each address selecting a 16-bit element. When using
> the address register, the LSB of address reg (AD) points to a 16-bit
> field in data memory. If a data memory line is 128 bits there are 8,
> 16-bit elements per data memory line. We use little endian addressing,
> so
> if AD=0, bits [15:0] of data memory line address 0 would be selected.
bits [15:0] are 16 bits, not 15 bits.
> If AD=1, bits [31:16] of data memory line address 0 would be selected.
> If AD=9, bits [31:16] of data memory line address 1 would be selected.
>
> So if i have the following program
>
> short arr[5] = {11,12,13,14,15};
>
> int foo ()
> {
> short a = arr[0] + arr[3];
> return a;
> }
>
> Assume that short is 16bits and short address is 2byte aligned.Then I
> expect the following code to get generated:
>
> mov a0,#arr // Load the address
>
> mov a1, a0 // Copy the address
> add a1, 1 // Increment the location by 1 so that the address
> points to arr[1]
I assume that your source example above should have read "arr[1] + ..."
then.
> short arr[5] = {11,12,13,14,15};
>
> int foo ()
> {
> short a,b;
>
> a = (short) (&arr[3] - &arr[1]); // a is 2 after this operation
> b = (short) ((char*)&arr[3] - (char*)&arr[1]); // b is 4 after this operation
Nope, with BITS_PER_UNIT=16 also b would be 2. The reason is that the
number of bits in 'char' is BITS_PER_UNIT by default (you can define it
yourself to something else, but that would be even more bit-rotten than
BITS_PER_UNIT=16 support itself). Therefore
sizeof(short)==sizeof(char)==1 and both types would have 16 bits.
And yes, that has implications on memory use for e.g. ASCII strings.
> My question is should i set the macro BITS_PER_UNIT = 16 to get a code
> generated like this? From IRC chat i realize that BITS_PER_UNIT != 8
> is seriously rotten. If that is the case how can i proceed to port
> this target?
You could do like the alpha port does when BWX instructions aren't
available (in which case the alpha can only load/store whole words), using
aligned loads/stores, bit extraction/insertion, and a store back. I don't
know if that would be efficiently possible on your hardware.
Ciao,
Michael.
Re: Help for target with BITS_PER_UNIT = 16
On Mon, Aug 16, 2010 at 2:10 PM, Mohamed Shafi wrote:
> Hello all,
>
> I am trying to port GCC 4.5.1 for a processor that has the following
> addressing capability:
>
> The data memory address space of 64K bytes is represented by a total
> of 15 bits, with each address selecting a 16-bit element. When using
> the address register, the LSB of address reg (AD) points to a 16-bit
> field in data memory. If a data memory line is 128 bits there are 8,
> 16-bit elements per data memory line. We use little endian addressing,
> so
> if AD=0, bits [15:0] of data memory line address 0 would be selected.
> If AD=1, bits [31:16] of data memory line address 0 would be selected.
> If AD=9, bits [31:16] of data memory line address 1 would be selected.
>
> So if i have the following program
>
> short arr[5] = {11,12,13,14,15};
>
> int foo ()
> {
> short a = arr[0] + arr[3];
> return a;
> }
>
> Assume that short is 16bits and short address is 2byte aligned.Then I
> expect the following code to get generated:
>
> mov a0,#arr // Load the address
>
> mov a1, a0 // Copy the address
> add a1, 1 // Increment the location by 1 so that the address
> points to arr[1]
> ld.16 g0, (a1) // Load the value 12 into g0
>
> mov a1, a0 // Copy the address
> add a1, 3 // Increment the location by 3 so that the address
> points to arr[3]
> ld.16 g1, (a1) // Load the value 14 into g0
>
> add g1, g1, g0 // Add 12 and 14
>
> For the following code:
>
> short arr[5] = {11,12,13,14,15};
>
> int foo ()
> {
> short a,b;
>
> a = (short) (&arr[3] - &arr[1]); // a is 2 after this operation
> b = (short) ((char*)&arr[3] - (char*)&arr[1]); // b is 4 after this operation
>
> return a;
> }
>
> My question is should i set the macro BITS_PER_UNIT = 16 to get a code
> generated like this? From IRC chat i realize that BITS_PER_UNIT != 8
> is seriously rotten. If that is the case how can i proceed to port
> this target?
You should set BITS_PER_UNIT to 16 if a byte has 16 bits when
looking at the definition of byte in the C99 standard (3.6). That is,
when
int foo()
{
unsigned char c = 0x8000;
return c >> 15;
}
should return 1 (instead of 0 when a char only has 8 bits).
Richard.
> Regards,
> Shafi
>
Re: Help for target with BITS_PER_UNIT = 16
On 16/08/2010 14:16, Michael Matz wrote: > Hi, > > On Mon, 16 Aug 2010, Mohamed Shafi wrote: > >> Hello all, >> >> I am trying to port GCC 4.5.1 for a processor that has the following >> addressing capability: >> >> The data memory address space of 64K bytes is represented by a total >> of 15 bits, with each address selecting a 16-bit element. When using >> the address register, the LSB of address reg (AD) points to a 16-bit >> field in data memory. If a data memory line is 128 bits there are 8, >> 16-bit elements per data memory line. We use little endian addressing, >> so >> if AD=0, bits [15:0] of data memory line address 0 would be selected. > > bits [15:0] are 16 bits, not 15 bits. The 15 is the number of address lines, not the size of the addressable unit. cheers, DaveK
Re: GFDL/GPL issues
On Sun, 15 Aug 2010 04:45:53 -0400 Robert Dewar wrote: > I think there is a difference between a novel you can hold and > read, and computer documentation. My question was not whether > anyone reads books any more, it was whether people read computer > manuals in this form any more. Just as a random data point, I've been surprised at how well sales of Linux Device Drivers have held up, despite (1) the book being freely available online, and (2) the fact that it's hopelessly obsolete. I don't know how long it's going to last, but, for now, there is still interest in this kind of information on dead trees. jon
Re: GFDL/GPL issues
Quoting Miles Bader : With elisp, I've found that in practice I usually start by copying the docstring (the "in code doc") to the manual (the "doc doc"), but almost always end up largely rewriting to fit the context in the manual better, and to explain things in more detail (modern docstrings tend to be rather verbose compared to docstrings-of-old, but they're still generally more terse than the manual). Still, if anything copyrightable is left of the copied text, you need license compatibility (or full copyright to the original text) in order to be able to publish the result. I find that a similar process is also often natural with going from code comments to gcc internals documentation, but if I don't have copyright to the comment, I don't want to deal with the license problems, so I rather leave the documentation for someone else (or nobody...) to write.
Re: GFDL/GPL issues
> > With elisp, I've found that in practice I usually start by copying the > > docstring (the "in code doc") to the manual (the "doc doc"), but almost > > always end up largely rewriting to fit the context in the manual better, > > and to explain things in more detail (modern docstrings tend to be > > rather verbose compared to docstrings-of-old, but they're still > > generally more terse than the manual). > > Still, if anything copyrightable is left of the copied text, you need > license compatibility (or full copyright to the original text) in order > to be able to publish the result. Unless one can claim "fair use". But the above procedure is also likely to result in taking nothing copyrightable from the original text anyway.
Re: GFDL/GPL issues
Quoting Richard Kenner : Unless one can claim "fair use". But the above procedure is also likely to result in taking nothing copyrightable from the original text anyway. But fair use does not apply here (geographically), and I don't want to have to consult a copyright lawyer to verify if I can safely submit my patch. Plus, even if there was a cheap and quick test to find out if the result is publishable, there is the hazard that you end up with something you can't publish, and it's one more piece of unpublished non-mainline code that makes it more complicated recall what really is in mainline and in the set of submitted-but-not-yet-reviewed patches.
Re: x86 assembler syntax
James Dennett writes: > Apart from using the name gcc@gcc.gnu.org for the help list, and > gcc-...@gcc.gnu.org for developers (who should be able to find the > right list)? I tend to agree that we should change the name of the gcc@gcc.gnu.org mailing list. Ian
