Velocity Reviews > Unsigned Int and Variable at address

# Unsigned Int and Variable at address

John T.
Guest
Posts: n/a

 06-25-2003
Hi NG.
I have two questions.
First, could I address some bit of an unsigned integer? lets say the integer
"mrtest" holds the value 0xFFFF0000 and I would like to do something like
(this is wirtten in some pseudo code)
if(mrtest(bit7,bit6,bit5,bit4 and bit 3 == 0b00000)
{
do a lot of things;
}

Second, how do I store a variable at a specific address?
for example

Best Regards
John

Dan Pop
Guest
Posts: n/a

 06-25-2003
In <bdc3br\$ppq\$(E-Mail Removed)-c.dk> "John T." <(E-Mail Removed)> writes:

>First, could I address some bit of an unsigned integer? lets say the integer
>"mrtest" holds the value 0xFFFF0000 and I would like to do something like
>(this is wirtten in some pseudo code)
>if(mrtest(bit7,bit6,bit5,bit4 and bit 3 == 0b00000)
>{
>do a lot of things;
>}

Try to use some kind of pseudo code that makes sense to other people, too.
If you want to test that all these bits are 0, build an unsigned mask
containing ones only in the corresponding positions: 0xF8U should do the
job (assumming bit0 is the least significant one). A bitwise and between
the value to be tested and the mask will tell you if all the relevant
bits are zero:

if ((mrtest & 0xF8U) == 0) {
/* do a lot of things */ ;
}

The extra pair of parentheses is needed because the & operator has the
"wrong" precedence WRT the == operator.

>Second, how do I store a variable at a specific address?
>for example

This is a very unwise thing to do, unless you have a *good* reason for
doing it. Most modern platforms use virtual memory, which makes such
an exercise pointless.

The answer is to define mrtest as a macro:

#define mrtest (*(unsigned int *)0xFFFF1166)

Now, the identifier mrtest will give you an unsigned int stored at address
0xFFFF1166, assuming that this address is suitable for storing an unsigned
int at all. If it isn't, your program may crash at the first attempt to
use mrtest...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: http://www.velocityreviews.com/forums/(E-Mail Removed)

dbtid
Guest
Posts: n/a

 06-25-2003
On Wed, 25 Jun 2003 14:09:34 +0200, John T. <(E-Mail Removed)> wrote:

> Hi NG.
> I have two questions.
> First, could I address some bit of an unsigned integer? lets say the
> integer
> "mrtest" holds the value 0xFFFF0000 and I would like to do something like
> (this is wirtten in some pseudo code)
> if(mrtest(bit7,bit6,bit5,bit4 and bit 3 == 0b00000)
> {
> do a lot of things;
> }
>
>

I'm not quite sure I understand what you're asking, but I'll state some
assumptions and you can go from there...

I assume by 0b00000 you mean binary 5 bits worth of 0's.

If that's the case, then, yes, this is possible, and even better, it's
easy.

if ((mrtest & 0x000000fc) == 0)
{
// do whatever.
}

If any of the bits in mrtest[7:3] is a 1, the result of the bitwise and
will be non-zero.

> Second, how do I store a variable at a specific address?
> for example
> Store mrtest at address 0xFFFF1166.
>

Declare a pointer of the appropriate type and set it to the address you
want.
Then assign the value through that pointer.

unsigned int *xFFFF1166 = (unsigned int *) 0xFFFF1166;
*xFFFF1166 = mrtest;

b) other way:

*((unsigned int *) 0xFFFF1166) = mrtest;

HTH

Dan Pop
Guest
Posts: n/a

 06-25-2003
In <(E-Mail Removed) m> dbtid <(E-Mail Removed)> writes:

>I assume by 0b00000 you mean binary 5 bits worth of 0's.
>
>If that's the case, then, yes, this is possible, and even better, it's
>easy.
>
> if ((mrtest & 0x000000fc) == 0)
> {
> // do whatever.
> }
>
>If any of the bits in mrtest[7:3] is a 1, the result of the bitwise and
>will be non-zero.

Nope, your mask contains *six* set bits (0xC == 8 + 4), so the result
can be non-zero even if *all* the five "target" bits are zero.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: (E-Mail Removed)

dbtid
Guest
Posts: n/a

 06-25-2003
On 25 Jun 2003 13:21:55 GMT, Dan Pop <(E-Mail Removed)> wrote:

> In <(E-Mail Removed) m> dbtid <dbtid@dev-
> null.us> writes:
>
>> I assume by 0b00000 you mean binary 5 bits worth of 0's.
>>
>> If that's the case, then, yes, this is possible, and even better, it's
>> easy.
>>
>> if ((mrtest & 0x000000fc) == 0)
>> {
>> // do whatever.
>> }
>>
>> If any of the bits in mrtest[7:3] is a 1, the result of the bitwise and
>> will be non-zero.

>
> Nope, your mask contains *six* set bits (0xC == 8 + 4), so the result
> can be non-zero even if *all* the five "target" bits are zero.
>
> Dan

To quote Homer Simpson, "Doh!"

Thanks, Dan, for pointing that out.

The bitmask ought to be 0x000000f8.

Humble apologies.

Emmanuel Delahaye
Guest
Posts: n/a

 06-25-2003
In 'comp.lang.c', (E-Mail Removed) (Dan Pop) wrote:

> The answer is to define mrtest as a macro:
>
> #define mrtest (*(unsigned int *)0xFFFF1166)

#define mrtest (*(unsigned volatile int *)0xFFFF1166)

--
-ed- (E-Mail Removed) [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-library: http://www.dinkumware.com/htm_cl/index.html
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

CBFalconer
Guest
Posts: n/a

 06-26-2003
Dan Pop wrote:
> Emmanuel Delahaye <(E-Mail Removed)> writes:
>

.... snip ...
> >
> >
> > #define mrtest (*(unsigned volatile int *)0xFFFF1166)

>
> It's supposed to be a memory address and last time I checked,
> memory counted as hardware. Yet, values stored in memory are
> not supposed to change by themselves, therefore volatile is not,
> a priori, justified.

The mere fact that you are defining such a location carries a
strong implication that something else knows about that location,
and thus may be modifying it. The only other reasonable
interpretation I see is that it participates in memory-mapped i/o,
in which case the volatile is again needed to prevent optimizing
out repeated output events.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.

Dan Pop
Guest
Posts: n/a

 06-26-2003
In <(E-Mail Removed)> CBFalconer <(E-Mail Removed)> writes:

>Dan Pop wrote:
>> Emmanuel Delahaye <(E-Mail Removed)> writes:
>>

>... snip ...
>> >
>> >
>> > #define mrtest (*(unsigned volatile int *)0xFFFF1166)

>>
>> It's supposed to be a memory address and last time I checked,
>> memory counted as hardware. Yet, values stored in memory are
>> not supposed to change by themselves, therefore volatile is not,
>> a priori, justified.

>
>The mere fact that you are defining such a location carries a
>strong implication that something else knows about that location,
>and thus may be modifying it. The only other reasonable
>interpretation I see is that it participates in memory-mapped i/o,
>in which case the volatile is again needed to prevent optimizing
>out repeated output events.

Your imagination is limited (but, at least, you haven't left your brain in
"neutral" this time Suppose that you have two types of memory
(e.g. slow/fast or cached/uncached or volatile/backed up) and you
want to force this particular object to be allocated on a certain
type of memory, hence the explicit address.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: (E-Mail Removed)

CBFalconer
Guest
Posts: n/a

 06-26-2003
Dan Pop wrote:
> CBFalconer <(E-Mail Removed)> writes:
> >Dan Pop wrote:
> >> Emmanuel Delahaye <(E-Mail Removed)> writes:
> >>

> >... snip ...
> >> >
> >> >
> >> > #define mrtest (*(unsigned volatile int *)0xFFFF1166)
> >>
> >> It's supposed to be a memory address and last time I checked,
> >> memory counted as hardware. Yet, values stored in memory are
> >> not supposed to change by themselves, therefore volatile is not,
> >> a priori, justified.

> >
> >The mere fact that you are defining such a location carries a
> >strong implication that something else knows about that location,
> >and thus may be modifying it. The only other reasonable
> >interpretation I see is that it participates in memory-mapped i/o,
> >in which case the volatile is again needed to prevent optimizing
> >out repeated output events.

>
> Your imagination is limited (but, at least, you haven't left your
> brain in "neutral" this time Suppose that you have two types
> of memory (e.g. slow/fast or cached/uncached or volatile/backed up)
> and you want to force this particular object to be allocated on a
> certain type of memory, hence the explicit address.

That smells highly of 'kluge'. Such a job is better left to the
executable creation. Of course the language limitations of a
particular implementation may force you to such a dirty kluge.
There certainly is no standard way of handling it, including the

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.

Junior Member
Join Date: Sep 2008
Posts: 2

 09-03-2008
what does it mean and where will it be used
*int a;