out

  • Thread starter Bill Cunningham
  • Start date
K

Kenny McCormack

And the maximum address of the memory space is?

Does "if(!p)" work when p is your NULL?

One suspects that Harald is, er, what's the word I'm looking for, oh,
yeah, here it is, lying.

It is a frequent tactic of the regs to speak, for pedagogic purposes, as
if the DS9000 actually exists and, further, that they use one on a
regular basis.

Many would have us believe that they have one in their basement.
 
H

Harald van Dijk

One suspects that Harald is, er, what's the word I'm looking for, oh,
yeah, here it is, lying.

It is a frequent tactic of the regs to speak, for pedagogic purposes, as
if the DS9000 actually exists and, further, that they use one on a
regular basis.

It's hardly a DS9000. If you're interested in details, you could just
ask. If you're not interested in details, that's fine too, then just
continue as you're doing now, I won't get in your way.
 
R

Richard

Harald van Dijk said:
As 0x55555555. What is a pointer to address 0x00000000 stored as on your
system?

0, why? I can honestly say I have never programmed a system where I
needed a pointer to address 0. So I dont spend too much time worrying
about it in order to keep things simple.

Now if your address is stored in memory as 0x55555555, how do you
differentiate between the NULL value you maintain is stored as
0x55555555 and the real address which you maintain is also stored as
0x55555555?
 
H

Harald van Dijk

0, why? I can honestly say I have never programmed a system where I
needed a pointer to address 0. So I dont spend too much time worrying
about it in order to keep things simple.

That's pretty much why. :)
Now if your address is stored in memory as 0x55555555, how do you
differentiate between the NULL value you maintain is stored as
0x55555555 and the real address which you maintain is also stored as
0x55555555?

I don't have to. There's no need to access the memory at address
0x55555555 any more than there is to access the memory at address
0x00000000. The system is responsibile for ensuring that no valid object
will be positioned there.
 
W

Walter Roberson

Richard said:
0, why? I can honestly say I have never programmed a system where I
needed a pointer to address 0. So I dont spend too much time worrying
about it in order to keep things simple.

I seem to recall that I used to work with some chips that had
interrupt vectors starting right from address 0. That was some time
ago, but it wouldn't surprise me if the descendants of those
chips were still in use.


Architectural oddity story:

The Silicon Graphics (SGI) workstations were designed with
memory starting from the 4Kb boundary, which was used for graphics
because memory was expensive then and smaller pointers and smaller
branch offsets could be used for very low addresses. At the time
of the design, memory from 0 to 4Kb-1 was not populated, so
dereferencing the 0 pointer caused an address fault.

Eventually, though, when SGI upgraded CPUs to the MIPS R8000 family
(and then the R10000), SGI changed the basic kernel page size to 8K
instead of 4K. Which meant that in order for that graphics memory
at 4K to be within a page, the entire page from 0 to 8K had to be mapped.
And suddenly dereferencing the 0 pointer did not cause an address
fault and writing through the null pointer or small offsets of the
null pointer (e.g., a structure offset relative to a null pointer)
caused real memory to be written, leading to various kinds of excitement.
 
F

Flash Gordon

Harald van Dijk wrote, On 07/04/08 19:58:
That's pretty much why. :)

When doing embedded work I have had to access memory at address 0x0000,
but what I was doing was non-portable so I did not care that I had to do
it in a non-portable way.
I don't have to. There's no need to access the memory at address
0x55555555 any more than there is to access the memory at address
0x00000000. The system is responsibile for ensuring that no valid object
will be positioned there.

Granted. Now what system is it that uses 0x55555555 as the
representation of a null pointer?
 
H

Harald van Dijk

Granted. Now what system is it that uses 0x55555555 as the
representation of a null pointer?

The x86 translator (backend) of tendra has an option to use 0x55555555 as
the representation of a null pointer. It's usable on Linux or the BSD
variants and capable of acting as a hosted implementation if you compile
libc with this option, or a freestanding implementation if you don't. To
be honest, I suspect it was only added as a test to make sure they would
be able to port to a system where null pointers with set bits were
already used, but whatever the reason, there it is.
 
K

Keith Thompson

Harald van Dijk said:
On one implementation I have access to, a null pointer is stored as
0x55555555, while a pointer to address zero is stored as 0x00000000.

Fascinating.

What system is it? Does it have a conforming C implementation (or
even a non-conforming C-like implementation)?
 
K

Keith Thompson

Richard said:
Note : I'm not trolling here. I'm just trying to find the "perfect
explanation" for the benefit of others. In too many places there is zero
or null :)-)) understanding of NULL not being the same as a zero
pointer.
[...]

The best explanation I've seen is section 5 of the comp.lang.c FAQ,
<http://www.c-faq.com/>.
 
H

Harald van Dijk

Fascinating.

What system is it? Does it have a conforming C implementation (or even
a non-conforming C-like implementation)?

The hardware is the same x86 anyone can easily get. It's purely the
compiler that can be configured to give null pointers the representation
0x55555555. The compiler is tendra, it runs on Linux or the various BSD
flavours (or perhaps other systems, but those I know of), and to the best
of my knowledge, it conforms to C90.
 
R

Richard Bos

I seem to recall that I used to work with some chips that had
interrupt vectors starting right from address 0. That was some time
ago, but it wouldn't surprise me if the descendants of those
chips were still in use.

I'd be highly surprised if it wasn't; the chip you're thinking of was
probably the Z80.

PRINT "Reset! "; USR 0

Richard
 
K

Kenny McCormack

I'd be highly surprised if it wasn't; the chip you're thinking of was
probably the Z80.

PRINT "Reset! "; USR 0

Richard

Simpler: 8086 (and descendants in "real mode").

Standard practice in DOS programming.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,431
Messages
2,571,679
Members
48,796
Latest member
Greg L.

Latest Threads

Top