using volatile ptrs ...

[LBJ]

lets say i have the following definition:

volatile char* p = 0x0a0a0a;

lets say p now points directly to cacheable memory, and lets also
say that this memory is currently cached. when p is accessed, will the
cache be hit, or will the program actually go out to DRAM (due to the
volatile qualifier)? I am guessing that the cache will be hit, and
that 'volatile' only means that internal registers to the cpu cannot
save *p. is that correct?

 

[Joona I Palaste]

lets say i have the following definition:

volatile char* p = 0x0a0a0a;

lets say p now points directly to cacheable memory, and lets also
say that this memory is currently cached. when p is accessed, will the
cache be hit, or will the program actually go out to DRAM (due to the
volatile qualifier)? I am guessing that the cache will be hit, and
that 'volatile' only means that internal registers to the cpu cannot
save *p. is that correct?

This question is entirely implementation-specific. The C language does
not even specify the terms "cacheable memory" or "DRAM".
Even assigning a direct address to a pointer in the first place causes
undefined behaviour. As far as the C language cares, a legal outcome of
the above code is to paint your screen purple with pink spots and print
"Cuckoo Cashew!" seventeen times in random locations, while renaming
every file on your file system to a line from "Finnegan's wake".

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp

 

[Eric Sosman]

lets say i have the following definition:

volatile char* p = 0x0a0a0a;

Indeed, let's. Note that if you say it to a C
compiler, the compiler must issue a diagnostic message.

lets say p now points directly to cacheable memory, and lets also
say that this memory is currently cached. when p is accessed, will the
cache be hit, or will the program actually go out to DRAM (due to the
volatile qualifier)? I am guessing that the cache will be hit, and
that 'volatile' only means that internal registers to the cpu cannot
save *p. is that correct?

The C language has no notion of cacheable memory, of
cached memory versus uncached memory, of hitting a cache,
of DRAM, or of "internal registers." Your question can't
be answered in terms of the C language, but only with
reference the a particular implementation on a particular
platform -- and, of course, different implementations will
have different answers. Consult the documentation for the
implemenations of interest, or seek advice on newsgroups
devoted to them.

 

[Lawrence Kirby]

lets say i have the following definition:

volatile char* p = 0x0a0a0a;

As others have indicated this is not valid C, you need an explicit cast to
convert an integer to a pointer. The result in this case won't be
portable.

lets say p now points directly to cacheable memory, and lets also
say that this memory is currently cached. when p is accessed, will the
cache be hit, or will the program actually go out to DRAM (due to the
volatile qualifier)? I am guessing that the cache will be hit, and that
'volatile' only means that internal registers to the cpu cannot save *p.
is that correct?

This is a level of detail that the C language doesn't cover. volatile has
a couple of uses in standard C, e.g. in relation to signal handlers and
sig_atomic_t. However it is commonly used in platform-specific extensions
to the language (e.g. threading). The basic idea is that it indicates that
an object can be accessed asynchronously e.g. from a different
process/thread on a signal or interrupt as a hardware sensitive location
and so on. It suggests to an optimiser that it should not eliminate
actual accesses of that location. Having volatile objects cached but not
held in registers (or more specifically a read/write in the source causes
an actual read/write of the memory location holding the object) is a
common implementation but certainly not something that C specifies or
requires. C defines the behaviour of programs (and in the case of volatile
constructs not very tightly), it does not specify how implementations
should achieve that behaviour. The non-portability I mentioned at the top
i.e. lack of definition by C itself, tends to generate broad license for
how implementations deal with it.

Lawrence

 

[Michael Wojcik]

lets say i have the following definition:

volatile char* p = 0x0a0a0a;

Let's assume that you have the necessary cast as well.

lets say p now points directly to cacheable memory, and lets also
say that this memory is currently cached. when p is accessed, will the
cache be hit, or will the program actually go out to DRAM (due to the
volatile qualifier)?

Neither. Your program will stop with a program check condition, and
a message will be sent to the user message queue (or job message
queue, if it's running in a non-interactive subsystem) noting the
error. If the message queue is in auto-answer mode, the program will
be cancelled and its spool file will contain a description of the
failure; otherwise, it will wait for a reply to the message. Typically
you will have the option of cancelling the program, debugging it, or
ignoring the program check - but in the last case you'll simply get
an immediate machine check which will only let you cancel the
program, IIRC.

Of course I'm assuming that you're using one of the conforming C
implementations for OS/400 V3R7, as is often[1] the case. Other
implementations may behave differently.

In OS/400 V3, and in later versions of OS/400 except for certain
special cases,[2] the implementation always produces a trap repre-
sentation when converting from an integer to a pointer. That's a
specific, real-world example of a conforming C implementation where
you cannot cast an integer to a pointer and successfully dereference
the latter.

As for your question regarding the "volatile" qualifier: the C
standard actually makes very few guarantees about volatile, and its
behavior is almost entirely a Quality of Implementation issue. So
you'll have to ask whoever wrote your compiler.


[1] Under certain other assumptions we need not go into here.

[2] The exceptions are the Licensed Internal Code, which forms the
lowest level of the OS; and the PASE environment, which was created
to support ill-behaved C programs. PASE gives the executing program
a one-TB memory object as its "address space", in which it is free
to muck about as it likes.

--
Michael Wojcik (e-mail address removed)

"Well, we're not getting a girl," said Marilla, as if poisoning wells were
a purely feminine accomplishment and not to be dreaded in the case of a boy.
-- L. M. Montgomery, _Anne of Green Gables_

 

[Joe Wright]

[ snip ]
Lawrence

Is that you fred? Welcome back. We've missed you here.

 

[Lawrence Kirby]

[ snip ]
Lawrence

Is that you fred? Welcome back. We've missed you here.

Yes, that's me!

Lawrence