From: Frank Klemm <pfk@fuchs.offl.uni-jena.de>
To: gcc@gcc.gnu.org
Subject: Proposal
Date: Sat, 15 Sep 2001 11:45:00 -0000 [thread overview]
Message-ID: <200109151841.UAA04064@fuchs.offl.uni-jena.de> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6778 bytes --]
I propose a websites with the following contents:
- gcc language extentions
- possible performance enhancements 2)
- warnings of the compiler 3)
- libc related issues
- gcc language extentions (future) 1)
- possible performance enhancements (future)
- warnings of the compiler (future)
- libc related issues (future)
- gcc language extentions (decline)
- possible performance enhancements (decline)
- warnings of the compiler (decline)
- libc related issues (decline)
Every proposal is discussed in the mailing list and is classified into:
- should be done in the next time
- future improvement, useful, but too difficult to implement in the next time
- decline, not so useful, too many problems, too difficult to implement
- gcc language extentions: Extention of the language C or C++
- where are performance improvements possible
- additional or superfluous warnings (or errors)
- libc related issues, missing library function, problems,
bugs and flaws
Performance test suite
- list of small *.inc files containing a small piece of code 4)
- a body function which does all the rest
- a table for the Duron/Athlon family, for the PII/PIII/Celeron family and
one for the P4 family
- a table for -O, -O2 and for -O3
- task is to show improvements and deterioration in the compilers code
Test# Description operations/µs
2.95.2 3.00 3.01 3.02
-------------------------------------------------------------
137 round test (int)floor() 11.5 11.9 11.8 191
138 foobar 91 75 75 92
1) ******************************************************************************
Separator for long number
~~~~~~~~~~~~~~~~~~~~~~~~~
The bigger the number the more difficult is it to decipher large numbers:
0xFFFFFFFFFFFFFFFC
1000000000000
0x0FFFFFFFFFFFFFFC
10000000000000
3.14159265358979
12768487.0
Ada 83 and Ada 95 allows '_' in numbers to separate groups of numbers:
0xFFFF_FFFF_FFFF_FFFC
1_000_000_000_000
0x0FFF_FFFF_FFFF_FFFC
10_000_000_000_000
3.14159_26535_8979
12_768_487.0
The '_' is allowed at every position between digits, but it is recommend to use
it in the way above.
integral hexadecimal numbers: 4 digits
decimal integral part of numbers: 3 digits
fractional part of numbers: 5 digits
May be we should introduce this is C too.
It is not allowed to compose numbers with '_' inside of macros.
#define MILLION _MERGE5 ( 1, _, 000, _, 000 )
This allows easily to write a filter to generate C89 or C99 files.
Problems
~~~~~~~~
The are no problems with foreward compatibilty, syntax always generates a syntax error on standard C99 compilers.
Programs are not backward compatible at all.
gcc should contain a filter to convert files with '_' inside of numbers into
C89 or C99 files.
gcc -_ program.c > filtered/program.c
Pros
~~~~
It makes C and C++ programs easier to read
It is easier to find errors.
Cons
~~~~
Bad backward compatibility.
There are other writing possible:
1000000000000 = 1_000_000_000_000 = 1000 * 1000 * 1000 * 1000
0xFFFFFFFFFFFFFF00 = 0xFFFF_FFFF_FFFF_FF00 = ~0x100
But it is easy to introduce other bugs with these writings
2 ****************************************************************************
Command line ----------------------------------------
gcc302 -O3 -fomit-frame-pointer
C code ----------------------------------------------
unsigned long long x;
void
main ( void )
{
x >>= 32;
return 0;
}
Assembler code ---------------------------------------
main: pushl %ebp <------
movl %esp, %ebp <------
subl $8, %esp <------
movl x+4, %eax
xorl %edx, %edx
andl $-16, %esp <------
movl %edx, x+4
movl %eax, x
movl %ebp, %esp <------
xorl %eax, %eax
popl %ebp <------
ret
Suggested optimized Assembler code: ------------------------------
// -O2
main: movl x+4, %eax
xorl %edx, %edx
movl %eax, x
movl %edx, x+4
xorl %eax, %eax
ret
// -Os
main: movl $x, %ecx
xorl %edx, %edx
movl 4(%ecx), %eax
movl %edx, 4(%ecx)
movl %eax, (%ecx)
xorl %eax, %eax
ret
// -Oss
main: movl $x+4, %ecx
xorl %eax, %eax
movl (%ecx), %edx
movl %eax, (%ecx)
movl %edx, -4(%ecx)
ret
Current version: 33 byte
proposed -O2: 21 byte
proposed -Os: 18 byte
proposed -Oss: 15 byte
Remarks ----------------------------------------------
Stack alignment of gcc 3.02 is really a nasty thing.
It blows up code, it slows down code. It is really a pain.
Before doing alignment on stack there should be clarified:
- who is responsable for aligning (caller / called)
- when it have a chance to speed up code (you need at least 64 bit items)
- what other conditions are needed to speed up code
(manipulating %esp decreases speed of push/pop/mov)
Proposal ------------------------------------------------
- A caller should never align the stack
- A function aligns the stack if there are arrays of 64 bit local
variables on the stack
- If there are many 64 bit local variables on stack the function may align
the stack
- functions arguments can be copied to such a local place if the variable
is often used and not copied to a FPU register.
3 ***************************************************************
Problem
~~~~~~~
Using of operator <=, >= or != although only one of the two partial conditions
is possible:
unsigned int x;
if ( x <= 0 ) {
...
}
unsigned char c;
if ( c != 255 ) {
...
}
This is often a hint that the code is wrong.
It should be possible to genarte a warning for such code.
4 *******************************************************************
/*
* Rounding floats to integers, always rounding to -inf.
*/
/* Argument is the ca. execution time on a 1 GHz computer in milliseconds */
float test0137_float [1000];
int test0137_int [1000];
struct result
test0137_run ( unsigned int ms )
{
struct result ret;
unsigned int i;
unsigned int j;
unsigned int k;
for ( k = 0; k < ms; k++ )
for ( i = 0; i < 200000; i++ )
for ( j = 0; j < 1000; j++ )
test0137_int [j] = (int) floor (test0137_float [j]);
ret.name = "round test (int)floor()";
ret.ops = 200.e6 * ms;
return ret;
}
void
test0137_init ( void )
{
}
/* The rest will be done by the program around */
--
Mit freundlichen GrüÃen
Frank Klemm
eMail | pfk@uni-jena.de home: pfk@schnecke.offl.uni-jena.de
| fingerprint: CDBB D7AE 0488 96B2 E0F9 98C2 1441 051C
phone | +49 (3641) 64-2721 home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
next reply other threads:[~2001-09-15 11:45 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-15 11:45 Frank Klemm [this message]
2001-09-15 12:15 ` Proposal Gerald Pfeifer
2001-09-17 16:00 ` Proposal Neil Booth
2001-09-18 2:30 ` Proposal Joseph S. Myers
2001-09-18 10:21 ` Proposal Zack Weinberg
2001-09-18 11:14 ` Proposal Joseph S. Myers
2001-09-18 22:20 ` Proposal Zack Weinberg
2001-09-19 1:14 ` Proposal Joseph S. Myers
2001-09-18 12:23 ` Proposal Frank Klemm
2001-09-18 22:37 ` Proposal Zack Weinberg
2001-09-19 0:02 ` Proposal Neil Booth
2001-09-19 2:23 ` Proposal Tim Hollebeek
2001-09-19 2:41 ` Proposal Richard Earnshaw
2001-09-19 13:38 ` Proposal Joe Buck
2001-09-18 15:35 ` Proposal Robert Lipe
2001-09-18 16:59 ` Proposal Russ Allbery
2001-09-20 11:17 ` Proposal Kai Henningsen
2001-09-20 12:34 ` Proposal Russ Allbery
2001-09-18 9:48 ` Proposal Frank Klemm
2001-09-18 11:06 ` Proposal Neil Booth
2001-09-18 11:37 ` Proposal Kevin Handy
2001-09-18 15:48 ` Proposal Neil Booth
2001-09-18 15:55 ` Proposal Toon Moene
2001-09-27 5:39 ` Proposal Alexandre Oliva
2001-09-27 7:09 ` Proposal Frank Klemm
2001-09-27 16:22 ` Proposal Zack Weinberg
2001-09-29 15:45 ` Proposal Frank Klemm
2001-09-30 9:35 ` Proposal Zack Weinberg
2001-09-27 16:36 ` Proposal Neil Booth
2001-09-29 15:45 ` Proposal Frank Klemm
2001-09-29 17:22 ` Proposal Daniel Jacobowitz
2001-09-29 18:32 ` OT: Proposal Michael Matz
2001-10-03 3:52 ` Proposal Fergus Henderson
2001-09-17 8:55 Proposal Thomas R. Truscott
2001-09-18 9:32 Proposal dewar
2001-09-18 12:30 Proposal dewar
2001-09-18 23:01 ` Proposal Zack Weinberg
2001-09-19 0:06 Proposal dewar
2001-09-19 2:34 Proposal dewar
2001-09-19 2:44 Proposal dewar
2012-09-03 15:16 Proposal Afeez Basit
2012-09-03 18:35 Proposal Afeez Basit
2013-06-26 17:41 Proposal Barrister David Lopez Esq
2013-06-26 18:15 ` Proposal Paolo Carlini
2013-06-26 18:40 ` Proposal Daniel Santos
2013-06-26 17:47 Proposal Barrister David Lopez Esq
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200109151841.UAA04064@fuchs.offl.uni-jena.de \
--to=pfk@fuchs.offl.uni-jena.de \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).