Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > register

Reply
Thread Tools

register

 
 
Tim Rentsch
Guest
Posts: n/a
 
      11-11-2005
Keith Thompson <(E-Mail Removed)> writes:

> Simon Biber <(E-Mail Removed)> writes:
> > Keith Thompson wrote:

> [...]
> >> 6.5.4.2 says you can't apply unary "&" to a register-qualified
> >> object.
> >> 6.3.2.1 says that the implicit conversion of an array expression to a
> >> pointer to its first element invokes undefined behavior if the
> >> designated array object has register storage class. (I'm not sure why
> >> it's undefined behavior rather than a constraint violation.)n
> >>

> >
> > So is this code acceptable in C99?
> >
> > #include <stdio.h>
> >
> > int main(void)
> > {
> > register int a[2] = {
> > printf("%zu\n", sizeof *a),
> > printf("%zu\n", sizeof a)
> > };
> > return 0;
> > }
> >
> > Since it's a normal array, and not a variable-length array, the
> > expression *a should never be evaluated, but just the type examined to
> > determine its size.

>
> Well, *I* certainly wouldn't accept it. }
>
> But yes, I believe it's legal (no constraint violations, no undefined
> behavior, but implementation-defined behavior because the output
> depends on sizeof(int)).
>
> <OT>
> gcc complains "error: address of register variable 'a' requested" on
> "sizeof *a". I believe gcc is wrong, [...]
> </OT>



The gcc error is consistent with another reading that I think is
reasonable. Here's 6.3.2.1 p3 again:

Except when it is the operand of the sizeof operator or the
unary & operator, or is a string literal used to initialize
an array, an expression that has type "array of type" is
converted to an expression with type "pointer to type" that
points to the initial element of the array object and is not
an lvalue. If the array object has register storage class,
the behavior is undefined.

I read the last sentence as saying the behavior of the _expression_ is
undefined, not that the behavior of the _conversion_ is undefined. If
read this way, the behavior should be undefined whether the expression
is evaluated or not.

Incidentally, making the behavior undefined rather than making it a
constraint violation allows an implementation to define indexing of
register arrays with so it works just like regular indexing.
 
Reply With Quote
 
 
 
 
Skarmander
Guest
Posts: n/a
 
      11-11-2005
Keith Thompson wrote:
> Skarmander <(E-Mail Removed)> writes:
>
>>Keith Thompson wrote:
>>
>>>Skarmander <(E-Mail Removed)> writes:

>

[tentative quotes tying conversion to evaluation]
>
> It seems to me from these definitions that conversions are tied very
> tightly to expressions. Conversions occur only as a result of an
> operator being applied to an operand (not quite correct, but close
> enough), which occurs as part of expression evaluation.
>


Let's say we agree on this. We can, because I can still highlight the
problem even if we assume the actual conversion is not taking place.
I'll argue that in this case, you're just stuck and have to fudge your
way out, when the standard does not require you to.

> Furthermore, just as a matter of common sense (dangerous, I know),
> expression evaluation happens at execution time; type determination
> must happen at compilation time.
>


That doesn't really matter here: I already agreed evaluation is not
taking place.

That said, common sense is only half right (not bad for common sense,
but still). Constant expressions can (must not, but may) be evaluated at
compile time (6.6.2), and they're not evaluated any differently from
non-constant expressions (6.6.11).

Case in point: the very sizeof expression we've been discussing is
evaluated at compile time. This is not relevant since the discussion is
about the operand of sizeof, not the sizeof expression as a whole, but
it's fun to note.

Type determination must, for the most part, happen at compilation time,
because the compiler must issue diagnostics for constraint violations,
and most of these simply require accurate typing information. (There is
probably nothing in the standard that disallows run-time typing where
constraints would not be violated, but such a hybrid implementation
would be unattractive for obvious reasons.)

> [snip]
>
>
>>If you believe an alternate mechanism is required or supplied by the
>>standard that the compiler can apply to determine the type without
>>going through conversion, I'd like to know. I don't see what magically
>>tells the compiler what the type of `*a' is without tripping over the
>>conversion rules.

>
>
> There's nothing magical about it. For any non-VLA expression that's
> the operand of a sizeof operator, the compiler has to go through the
> same process it does for any expression to determine the type, but
> without evaluating the expression (or rather, without generating code
> to evaluate the expression).
>


You say that as if the undefined behavior that results from converting a
register array to a pointer is part of the code that would be generated
to evaluate the expression. It is not, or rather, nothing in the
standard says it is.

>>You can try and argue that the conversion is (part of) evaluation and
>>the compiler has only to *act* as if it converted for the sake of type
>>calculation, but must not actually do so. This is an eminently
>>reasonable approach, but it's made up out of whole cloth; the standard
>>doesn't say this is how determining types can be done. We are then
>>claiming the part about undefined behavior should be ignored without
>>having anything in the standard to back us up on this.

>
>
> Then how *does* the standard say the type is determined?


By such phrases as "the type of <expression> is <type>", in particular
"The unary * operator denotes indirection. [...] If the operand has type
'pointer to type', the result has type 'type'." Note that evaluation of
the operand is not required, we need only know its type. By recursively
applying such rules, we can determine the type without even any
reference to evaluation. The sentence that immediately follows it, for
example, "If an invalid value has been assigned to the pointer, the
behavior of the unary * operator is undefined", is irrelevant: behavior
of the operator has no bearing on the typing.

I'll quote and simplify the actual case to demonstrate what I mean.

void f() {
register size_t a[1] = {sizeof *a};
}

According to both of us and the standard, `*a' is not evaluated. In my
view, the *only* rule in the *entire* standard that allows us to
determine the type of `*a' (which sizeof needs) is the one that
describes the indirection operator, quoted above. For this, `a' must be
of meta-type 'pointer to <t>', for some type t. But it is not.

By your view, we are now stuck as far as the rules we're given go. We
can't actually convert `a' to a `size_t *' because conversion is part of
evaluation, which we don't do, since we're in a sizeof. So, if I get you
correctly, you propose that the compiler now proceeds *as if* it
converted `a' to a `size_t *', concludes that the type of `*a' is
therefore `size_t', and applies sizeof accordingly.

This is *almost* my view, but with one crucial difference. I propose
this must follow 6.3.2.1.3 exactly: "An expression that has type 'array
of <type>' is converted to an expression with type 'pointer to <type>'
that points to the initial element of the array object and is not an
lvalue. If the array object has register storage class, the behavior is
undefined."

Here is the essence of the problem: even if we agree that the compiler
does not actually need to *do* anything to yield "an expression [...]
that points to the initial element of the array object and is not an
lvalue" because it only needs the go-ahead for the type conversion, we
*still* trigger the UB clause.

We *know* at compile time that `a' has register storage class, and there
is no other way of completing the typing process. We must follow these
rules because no others will get the job done, and they say we've messed
up and the compiler may unleash the nasal demons. Nothing in the
standard says "because you're not evaluating `a', you may pretend there
is no UB" or "because you're not evaluating `a', you may make up your
own rules about the typing that resemble the ones used when evaluating".

> If it has to carry out a run-time operation (the conversion) to
> determine compile-time information, we're in big trouble.
>


Where does it say conversion *of this kind* is a run-time operation? We
would be in big trouble if we found out we needed conversions of *actual
values* to do typing, but we don't. But at this point we simply *need*
to apply at least that part of the conversion that includes the typing
rules, and it comes with UB.

S.
 
Reply With Quote
 
 
 
 
Mabden
Guest
Posts: n/a
 
      11-12-2005
"Richard Bos" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)4all.nl...
> http://www.velocityreviews.com/forums/(E-Mail Removed) (Gordon Burditt) wrote:
>
> > You can never be sure that the keyword 'register' will affect
> > the code at all. And if you use it enough, you *WILL* run out
> > of actual CPU registers.

>
> Erm... I spot an inconsistency.


So say what it is. Why make us guess?

He is saying the "register" is not *always* used, as such, by the CPU,
but on the converse, by using it too much, you fill up registers that
can be used, by taking away the CPU's decision making process, thus
making less registers available, thus causing other "register" variables
to not be register variables.

Seems quite clear to me.

--
Mabden


 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      11-12-2005
Mabden wrote:
>
> "Richard Bos" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)4all.nl...
> > (E-Mail Removed) (Gordon Burditt) wrote:
> >
> > > You can never be sure that the keyword 'register' will affect
> > > the code at all. And if you use it enough, you *WILL* run out
> > > of actual CPU registers.

> >
> > Erm... I spot an inconsistency.

>
> So say what it is. Why make us guess?
>
> He is saying the "register" is not *always* used, as such, by the CPU,
> but on the converse, by using it too much, you fill up registers that
> can be used, by taking away the CPU's decision making process, thus
> making less registers available,
> thus causing other "register" variables
> to not be register variables.
>
> Seems quite clear to me.


He's using a circular definition of "enough".
If you wish hard enough,
all of your pennies *WILL* turn into gold.
You're using "too much" the same way.

--
pete
 
Reply With Quote
 
Mabden
Guest
Posts: n/a
 
      11-12-2005
"pete" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Mabden wrote:
> >
> > "Richard Bos" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)4all.nl...
> > > (E-Mail Removed) (Gordon Burditt) wrote:
> > >
> > > > You can never be sure that the keyword 'register' will affect
> > > > the code at all. And if you use it enough, you *WILL* run out
> > > > of actual CPU registers.
> > >
> > > Erm... I spot an inconsistency.

> >
> > So say what it is. Why make us guess?
> >
> > He is saying the "register" is not *always* used, as such, by the

CPU,
> > but on the converse, by using it too much, you fill up registers

that
> > can be used, by taking away the CPU's decision making process, thus
> > making less registers available,
> > thus causing other "register" variables
> > to not be register variables.
> >
> > Seems quite clear to me.

>
> He's using a circular definition of "enough".
> If you wish hard enough,
> all of your pennies *WILL* turn into gold.
> You're using "too much" the same way.


Ok, that helped. How?

--
Mabden


 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      11-12-2005
In article <(E-Mail Removed)>,
pete <(E-Mail Removed)> wrote:
....
>But Kenny isn't.
>
>http://www.codecomments.com/Unix_Pro...age665290.html
>
><OT>
>Poor Kenny. The people in comp.lang.c aren't amenable to redefining
>the purpose of the newsgroup to suit him. One wonders why he continues
>to hang around there
></OT>
>I stick around, read, and post, for the same reasons I do in
>any other joke newsgroup - because it is so much fun.


Thank you for posting taking the time to find and post that. Saves me the
trouble. It makes my case very well, but I really don't see how you could
think that it furthers your case. Except that, what I really think some of
you believe is that it is morally wrong to have fun here. It is as if
someone was having fun in church - which is, of course, a very apt analogy.

I'm clear about why I read and post in this joke newsgroup, but I really
don't see why some of you do. What needs of yours are being met?

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-12-2005
(E-Mail Removed) (Kenny McCormack) writes:
[the usual crap]

Kenny: Please go away and have your "fun" somewhere else.

Everyone else:

___________________
/| /| | |
||__|| | Please do |
/ O O\__ NOT |
/ \ feed the |
/ \ \ trolls |
/ _ \ \ ______________|
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ \ __||
/ / \ |____| ||
/ | | /| | --|
| | |// |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ // |
/ _ \\ _ // | /
* / \_ /- | - | |
* ___ c_c_c_C/ \C_c_c_c____________


--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      11-13-2005
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:
>(E-Mail Removed) (Kenny McCormack) writes:
>[the usual crap]
>
>Kenny: Please go away and have your "fun" somewhere else.


It's too much fun here. Sorry if that offends you (having fun in church,
you know...)

>Everyone else:
>
> ___________________


Made ya look!

 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      11-14-2005
"Mabden" <mabden@sbc_global.net> wrote:

> "Richard Bos" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)4all.nl...
> > (E-Mail Removed) (Gordon Burditt) wrote:
> >
> > > You can never be sure that the keyword 'register' will affect
> > > the code at all. And if you use it enough, you *WILL* run out
> > > of actual CPU registers.

> >
> > Erm... I spot an inconsistency.

>
> So say what it is. Why make us guess?


If you can't be sure that "register" has any effect at all, you cannot
know that you _will_ run out of anything, including registers. If you
know that you will eventually run out of registers, that in itself is a
way in which "register" will affect your code.

(The first of Gordon's sentences is true. The last one is not. It used
to be true, but modern compilers are much better at optimising.)

Richard
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      11-14-2005
Richard Bos wrote:
> "Mabden" <mabden@sbc_global.net> wrote:
>
>>"Richard Bos" <(E-Mail Removed)> wrote in message
>>news:(E-Mail Removed)4all.nl...
>>
>>>(E-Mail Removed) (Gordon Burditt) wrote:
>>>
>>>>You can never be sure that the keyword 'register' will affect
>>>>the code at all. And if you use it enough, you *WILL* run out
>>>>of actual CPU registers.
>>>
>>>Erm... I spot an inconsistency.

>>
>>So say what it is. Why make us guess?

>
> If you can't be sure that "register" has any effect at all, you cannot
> know that you _will_ run out of anything, including registers. If you
> know that you will eventually run out of registers, that in itself is a
> way in which "register" will affect your code.
>
> (The first of Gordon's sentences is true. The last one is not. It used
> to be true, but modern compilers are much better at optimising.)


In the desktop world, yes. For embedded systems, most bets are off.

For some target platforms, it seems more important that the vendors
whip out some sort of compiler in short time than a good one in
appropriate time. If it is halfway conforming and does not blunder at
the most elementary stuff, then everything is fine.
Some code generators even "code around" the known compiler bugs and
inefficiencies by default as there are enough of both to justify
the additional effort.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to register a custom class name in c#? jay ASP .Net 0 02-19-2004 07:06 AM
Register problem(long) Morfeusz VHDL 4 12-03-2003 09:35 AM
synthese: date and time automatically placed in a register?? Pierre-Louis VHDL 8 10-17-2003 05:56 PM
need the code for linearfeedback register yoga VHDL 1 10-11-2003 01:08 AM
(newbie) 2 read/write register Max VHDL 1 09-04-2003 12:44 PM



Advertisments