register variable

[dssuresh6]

I have a few doubts regarding the register variable. Though the C
standard says that it is illegal to access the address of a register
variable, the GCC compiler gave only warning. At run-time also, there
was no error (probably, the register variable is converted into an
'auto' variable by the compiler).

Suppose the register variable is not converted into 'auto' variable,
then at run-time, will it give error? So far I've not come across a
situation where the variable declared as 'register' is actually put
into a register. It looks like everytime the GCC compiler turns it into
'auto' variable. From a program, how to find whether the variable is
actually put into a register or it is made an auto variable?

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dssuresh6 wrote:
| I have a few doubts regarding the register variable. Though the C
| standard says that it is illegal to access the address of a register
| variable, the GCC compiler gave only warning.

This, then, is a flaw in the GCC compiler.

| At run-time also, there
| was no error (probably, the register variable is converted into an
| 'auto' variable by the compiler).

The compiler is free to make that conversion.


| Suppose the register variable is not converted into 'auto' variable,
| then at run-time, will it give error?

Presumably, if the compiler is broken enough to not forbid taking the address of
a register variable, then the runtime program may do just about anything,
including causing demons to emerge from the nose of the user who ran it.

| So far I've not come across a
| situation where the variable declared as 'register' is actually put
| into a register.

Maybe you've been lucky.

| It looks like everytime the GCC compiler turns it into
| 'auto' variable. From a program, how to find whether the variable is
| actually put into a register or it is made an auto variable?

"register" is a hint to the compiler, and the compiler is not obliged to take
the hint. The program should have no need to determine if the compiler took the
hint or not; the programmer has explicitly determined this course of action by
specifying that the variable is a "register" variable, and the program is the
end-result of the programmer's actions in this regard.


- --
Lew Pitcher
IT Consultant, Enterprise Data Systems,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFBnP1EagVFX4UWr64RAvETAJ9plnAqGQCqaXuV4ZfLcGhldHYwhgCg3vNI
4b5DJzL0I4jFa3NzsRnNgvw=
=kupR
-----END PGP SIGNATURE-----

 

[Ulrich Eckhardt]

I have a few doubts regarding the register variable. Though the C
standard says that it is illegal to access the address of a register
variable, the GCC compiler gave only warning. At run-time also, there
was no error (probably, the register variable is converted into an
'auto' variable by the compiler).

I can't give you the exact quote, but I read that for years(!) compilers
have been doing a better job at optimising code than you could with
'register' attributes. That is also the reason why many compilers today
simply ignore this suggestion(which is perfectly valid, btw!).

Uli

 

[Chris Torek]

I have a few doubts regarding the register variable. Though the C
standard says that it is illegal to access the address of a register
variable, the GCC compiler gave only warning.

The Standard requires only "a diagnostic". GCC produced one, then
went on to pretend you wrote some other code, and compiled that
other code instead.

If you want to be in control of what code you run, do not let the
compiler change your code to some other code just so that it can be
compiled. Fix your code instead; and consider using GCC's "-Werror"
option to make the warning terminate compilation entirely, instead
of substituting some other code that does compile.

 

[Gordon Burditt]

| I have a few doubts regarding the register variable. Though the C

| standard says that it is illegal to access the address of a register
| variable, the GCC compiler gave only warning.

This, then, is a flaw in the GCC compiler.

I disagree here. GCC produced a diagnostic, like the standard says
it has to. ANSI C does not define a distinction between warning
(produces executable anyway), error (no executable produced), severe
error (compiler deletes offending source code) and catastrophic
error (compiler kills offending programmer). void main() should
come under the "catastrophic error" heading, but ANSI C does
not insist on it.

Gordon L. Burditt

 

[Merrill & Michele]

I have a few doubts regarding the register variable. Though the C
standard says that it is illegal to access the address of a register
variable, the GCC compiler gave only warning. At run-time also, there
was no error (probably, the register variable is converted into an
'auto' variable by the compiler).

Suppose the register variable is not converted into 'auto' variable,
then at run-time, will it give error? So far I've not come across a
situation where the variable declared as 'register' is actually put
into a register. It looks like everytime the GCC compiler turns it into
'auto' variable. From a program, how to find whether the variable is
actually put into a register or it is made an auto variable?

I read today in K&R that you can register as many variables as you like and
need not think you are on thin ice, as your compiler is free to ignore any
request it doesn't like in this regard. MPJ

 

[J. J. Farrell]

I can't give you the exact quote, but I read that for years(!) compilers
have been doing a better job at optimising code than you could with
'register' attributes. That is also the reason why many compilers today
simply ignore this suggestion(which is perfectly valid, btw!).

A conforming compiler cannot simply ignore it. It must give a
diagnostic if the program takes the address of a register variable.

When code breaks a constraint in this way, anything can happen.
Unless your compiler's documentation happens to tell you, there
is no saying how the compiler or the program it produces will
behave. A fairly obvious thing for a compiler to do is to issue
the required diagnostic then pretend that the register keyword
is not present - many compilers effectively pretend it's not
there for all other purposes anyway.

 

[Dan Pop]

The Standard requires only "a diagnostic". GCC produced one, then
went on to pretend you wrote some other code, and compiled that
other code instead.

Or it compiled the same code:

4 A declaration of an identifier for an object with storage-class
specifier register suggests that access to the object be as fast
as possible. The extent to which such suggestions are effective
is implementation-defined.

A compiler is free to ignore the register storage-class specifier, as long
as it generates the mandatory diagnostics.

And since we're talking about gcc, its documentation says that register
*may* have some effect on the code generation only at optimisation level
0.

But your general point is still valid: once a mandatory diagnostic has
been issued, it is as if the code invoked undefined behaviour.

Dan

 

[Dan Pop]

I read today in K&R that you can register as many variables as you like and
need not think you are on thin ice, as your compiler is free to ignore any
request it doesn't like in this regard. MPJ

However, it has to issue diagnostics when the address of *any* register
variable is taken, regardless of where it actually allocates it.

Dan

 

[Dan Pop]

I have a few doubts regarding the register variable. Though the C
standard says that it is illegal to access the address of a register
variable, the GCC compiler gave only warning.

It warned you that your code is breaking the restrictions imposed by the
C standard. Isn't that good enough for you?

At run-time also, there
was no error (probably, the register variable is converted into an
'auto' variable by the compiler).

As a general rule, there is no point in executing C code violating the C
standard, unless the effects of the violation are well documented by
another standard relevant to your implementation.

Suppose the register variable is not converted into 'auto' variable,
then at run-time, will it give error?

It is entirely pointless to speculate about the behaviour of code
requiring a diagnostic: it is not valid C code and the standard doesn't
specify its semantics. No sensible compiler would allocate such a
variable into a register: it would either allocate it in memory and treat
it as a non-fatal standard violation or it would treat it is as fatal
standard violation and not generate any object code at all.

So far I've not come across a
situation where the variable declared as 'register' is actually put
into a register. It looks like everytime the GCC compiler turns it into
'auto' variable.

The gcc documentation says that, if you use -O0, you have a chance to get
register variables allocated in registers.

From a program, how to find whether the variable is
actually put into a register or it is made an auto variable?

You cannot. Most modern optimisers keep in registers what they determine
to be the hottest variables in that part of the code. In a different
part of the code, they may keep a different set of variables in
registers. Due to this approach, even variables that spend most of their
lifetimes in registers, also get allocated as automatics. Especially if
the code is calling another function, which might have its own variables
allocated in registers.

Dan

 

[Richard Tobin]

[...] No sensible compiler would allocate such a
variable into a register

Except perhaps on a system where registers have addresses, such as
some members of the PDP-11 family.

-- Richard

 

[dandelion]

[...] No sensible compiler would allocate such a
variable into a register

Except perhaps on a system where registers have addresses, such as
some members of the PDP-11 family.

Is a register address on that member of the PDP-11 family the same as a
memory address? If not... Well... I

I'll leave it to you to conclude what will happen. I for one, do not think
the PDP would apply a 16/32/64 bit address space to a register file. It
would *seem* a bit redundant.

 

[Richard Tobin]

Except perhaps on a system where registers have addresses, such as
some members of the PDP-11 family.

[/QUOTE]

Is a register address on that member of the PDP-11 family the same as a
memory address? If not... Well... I

Reading or writing certain addresses near the top of the address space
would read or write the registers instead of external memory. I don't
have a PDP-11 handbook here to check the details.

There were even machines in which the registers were executable. If I
recall correctly, you could fit short loops into registers on the
PDP-10, where they would execute much faster. (Semiconductor
registers were an optional add-on - I used to have a price list that
included them.)

-- Richard

 

[dandelion]

Is a register address on that member of the PDP-11 family the same as a
memory address? If not... Well... I

Reading or writing certain addresses near the top of the address space
would read or write the registers instead of external memory.[/QUOTE]

Yuck! What on earth for?

I don't have a PDP-11 handbook here to check the details.

I believe you on your word.

There were even machines in which the registers were executable.

Yuck squared!

-- Richard

Btw. I mistook you for another Richard, so if my post came across a little
sarcastic, please apologize.

regards,

dandelion.

 

[Alex Fraser]

Yuck! What on earth for?

Perhaps to meet opcode constraints or otherwise simplify the processor logic
(reducing addressing modes without sacrificing functionality).

Yuck squared!

I can see the value, if there is no instruction cache.

Alex

 

[Keith Thompson]

Is a register address on that member of the PDP-11 family the same as a
memory address? If not... Well... I

Reading or writing certain addresses near the top of the address space
would read or write the registers instead of external memory. I don't
have a PDP-11 handbook here to check the details.

There were even machines in which the registers were executable. If I
recall correctly, you could fit short loops into registers on the
PDP-10, where they would execute much faster. (Semiconductor
registers were an optional add-on - I used to have a price list that
included them.)[/QUOTE]

<OT>

PDP-11 was the first assembly language I learned, and I don't recall
any such feature. (Conceivably they just didn't want to tell us about
it.) As I recall, it has 8 general-purpose 16-bit registers, R0..R7;
R6 is the stack pointer, and R7 is the program counter. I vaguely
recall that some TI chip allowed registers to be addressed as memory,
and I wouldn't be surprised if some PDP-XX did the ssame thing, for
XX != 11.

</OT>

 

[Dave Vandervies]

(e-mail address removed) (Richard Tobin) writes:

<OT>

PDP-11 was the first assembly language I learned, and I don't recall
any such feature. (Conceivably they just didn't want to tell us about
it.) As I recall, it has 8 general-purpose 16-bit registers, R0..R7;
R6 is the stack pointer, and R7 is the program counter. I vaguely
recall that some TI chip allowed registers to be addressed as memory,
and I wouldn't be surprised if some PDP-XX did the ssame thing, for
XX != 11.

The PDP-10 had memory-mapped registers that could be used for code:
http://groups.google.com/[email protected]

Another followup to my post that's quoted in this one claims that the
-11 did in fact have registers mapped into the high end of the address
space, with some limitations on how they could be accessed.


Not entirely unrelated (only mostly), the 6502 had three on-chip registers
and a 256-byte memory page designed to act as general-purpose registers
(either as 8-bit registers or paired as 128 16-bit registers, or some
combination thereof). I doubt using these actually eliminated memory
accesses, though; I think it was just CPU-wise that zero page access
was faster. So putting code there wouldn't speed it up the way it would
on the PDP-10.

</OT>

dave

 

[Richard Tobin]

[/QUOTE]

PDP-11 was the first assembly language I learned, and I don't recall
any such feature. (Conceivably they just didn't want to tell us about
it.)

You wouldn't come across it when writing generic PDP-11 assembler, but
only by reading the manuals for specific PDP-11 versions. All I
remember reading about it was a warning not to rely on it because it
didn't work on all PDP-11 versions. I imagine it was only used in
system code (perhaps as a simple way to save/restore all the
registers?).

As I recall, it has 8 general-purpose 16-bit registers, R0..R7;
R6 is the stack pointer, and R7 is the program counter.

Right; and on the machines in question you could also access them as
memory locations 01777XY for some XY.

(I'm not sure if the use of R6 as stack pointer was anything more than
convention; you could use the same stack-like addressing modes on any
register.)

I vaguely
recall that some TI chip allowed registers to be addressed as memory,

You're probably thinking of the TMS 9900. Its "registers" really were
memory: you could change the base address of them. So you could just
push a whole new set of registers. Sort of like register windows on
Sparc.

-- Richard

 

[Dik T. Winter]

> In article <[email protected]>,

>
> You wouldn't come across it when writing generic PDP-11 assembler, but
> only by reading the manuals for specific PDP-11 versions.

From the PDP-11 handbook (c) 1978 (pretty late in development):

777 717 User R6 (SP)
777 716 Supervisor R6 (SP)
777 715-710 General registers, set 1 R5-R0
777 707 Kernel R7 (PC)
777 706 Kernel R6 (PC)
777 705-700 Gereral registers, set 0 R5-R0

> (I'm not sure if the use of R6 as stack pointer was anything more than
> convention; you could use the same stack-like addressing modes on any
> register.)

See above. User and Supervisor R6 were different (in the time when the
three layer model had been introduced). I can look up how it was in
the time of the two layered model, but I think this is sufficient.
On the other hand, instructions like JSR and RTS specifically address R6
as stack pointer.

>
> You're probably thinking of the TMS 9900.

Not only that one. There has been a large number of processors where
the registers were actually memory.

 

[Chris Croughton]

Perhaps to meet opcode constraints or otherwise simplify the processor logic
(reducing addressing modes without sacrificing functionality).

Also it allowed values to be keyed directly into the registers from the
front panel switches, which was necessary with some of the bootstrap
code (for instance to determine whether you wished to load from paper
tape, card, DECTape, etc., and which particular device). It also
allowed a register to be examined in the same way as other memory, hence
saving cost (and front panel space).

I can see the value, if there is no instruction cache.

The early PDP-11 machines didn't have instruction (or data) cache, they
only had the magnetic core store.

It actually took more hardware to prevent the registers from being
executable, so why bother? TTL chips were expensive, and nothing else
was protected...

(alt.folklore.computers has a number of people who remember PDP-11
machines fondly...)

Chris C