From: "Etienne Lorrain" <etienne_lorrain@yahoo.fr>
To: gcc@gcc.gnu.org
Subject: RE: Big-endian Gcc on Intel IA32
Date: Thu, 20 Dec 2001 05:36:00 -0000 [thread overview]
Message-ID: <20011220131814.8116.qmail@web11805.mail.yahoo.com> (raw)
Just a (maybe meaningless) comment on attributes:
When you begin to describe your variables with __attribute__(()),
for instance to optimise code size or speed, you also feel a need
to test if the variable as such or such attributes, for instance in
inline functions/macro. Let's take the example of align/alignof:
struct longstruct mydata __attribute__((aligned(16)));
static const struct longstruct emptydata = {};
void init_mydata (struct longstruct *mydataptr)
{
if (alignof (emptydata) > 4)
fast_memcpy(...);
else
slow_memcopy(...);
}
Maybe a more generic way to define and test attributes, at least
for structure types, would be something like:
typedef struct {
unsigned field1, field2;
char field3;
const unsigned __aligned__ = 16; /* not counted in sizeof() */
} an_aligned_16_type;
an_aligned_16_type data;
{ if (data.__aligned__ == 16) {} else {} }
In the same spirit:
typedef struct {
const unsigned __packed__ = 1;
unsigned short d1;
unsigned long d2;
}
typedef struct {
const unsigned __segment__ = __segment_gs;
unsigned char red;
unsigned char green;
unsigned char blue;
} what_I_need_for_another_project;
void fct (void)
{
const unsigned __aligned__ = 64;
....
}
The programmer could also define his own attributes.
Would also not break too much "indent" and "lint" kind of software.
No, I do not have the time to implement, sorry.
Etienne.
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Courrier : http://courrier.yahoo.fr
next reply other threads:[~2001-12-20 13:19 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-20 5:36 Etienne Lorrain [this message]
2001-12-20 6:27 ` force instruction Dmitry
-- strict thread matches above, loose matches on Subject: below --
2001-12-23 7:26 Big-endian Gcc on Intel IA32 dewar
2001-12-23 7:06 dewar
2001-12-23 7:08 ` Florian Weimer
2001-12-19 11:47 Bernard Dautrevaux
2001-12-19 13:09 ` Linus Torvalds
2001-12-18 11:41 Morten Welinder
2001-12-18 11:42 ` Phil Edwards
2001-12-18 14:48 ` Linus Torvalds
2001-12-18 3:49 dewar
2001-12-23 6:59 ` Florian Weimer
2001-12-17 18:39 dewar
2001-12-17 18:59 ` Per Bothner
2001-12-17 13:14 dewar
2001-12-17 13:42 ` guerby
2001-12-17 13:43 ` Linus Torvalds
2001-12-17 14:22 ` guerby
2001-12-17 14:52 ` Linus Torvalds
2001-12-17 15:01 ` Richard Henderson
2001-12-17 15:12 ` Linus Torvalds
2001-12-17 15:54 ` Richard Henderson
2001-12-17 17:43 ` Linus Torvalds
2001-12-17 18:12 ` Richard Henderson
2001-12-18 11:55 ` Jason Riedy
2001-12-17 16:43 ` Ross Smith
2001-12-18 1:28 ` Florian Weimer
2001-12-17 12:08 dewar
2001-12-17 13:10 ` Linus Torvalds
2001-12-17 14:00 ` Alan Lehotsky
2001-12-17 12:00 Ghanta, Bose
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=20011220131814.8116.qmail@web11805.mail.yahoo.com \
--to=etienne_lorrain@yahoo.fr \
--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).