How to access 32-bit and 64-bit heap space ?

C

chipzz1

On a 64-bit Linux environment, how do I access 32-bit and 64-bit
addressable heap space, explicitly. This is assuming that malloc()
just gives you a chunk from the flat 64-bit addressable heap.


TIA,

(e-mail address removed)
 
J

Joe Pfeiffer

On a 64-bit Linux environment, how do I access 32-bit and 64-bit
addressable heap space, explicitly. This is assuming that malloc()
just gives you a chunk from the flat 64-bit addressable heap.

I'm not quite sure what the question means, but

man sbrk

might give you what you're looking for.
 
S

Stephen Sprunk

On a 64-bit Linux environment, how do I access 32-bit and 64-bit
addressable heap space, explicitly. This is assuming that malloc()
just gives you a chunk from the flat 64-bit addressable heap.

There is no "32-bit heap space" in 64-bit mode. If you compile the
program to run in 64-bit mode, the heap is 64-bit. AFAIK, there are no
specific functions to allocate memory below the 4GB (or 2GB) line,
though you _might_ be able to hack something together with mmap().

More importantly, though, why would you want to? There may be a better
way to accomplish what you're trying to do.

S
 
A

Antoninus Twink

AFAIK, there are no specific functions to allocate memory below the
4GB (or 2GB) line, though you _might_ be able to hack something
together with mmap().

More importantly, though, why would you want to? There may be a better
way to accomplish what you're trying to do.

The only reason I can think of why someone may want to to this is to
save memory by being able to store pointers in 32 bits instead of 64. In
this case, the obvious (ugly) solution is to store a 64-bit "base"
pointer, and then instead of storing pointers to struct nodes (or
whatever) inside the array starting at base(*), you store 32-bit (or
even 16-bit) offsets. Then you write a little accessor macro, and
instead of code like

do_stuff(struct tree *X)
{
struct node *n = X->root;
n = n->left;
....
}

you have code like

do_stuff(struct tree *T)
{
struct node *n = X->root;
n = LEFT(T,n);
....
}

where LEFT is (T + n->left_offset)



(*) for the benefit of the idiotic pedants, yes I know what an array is,
and that this is loose but common language for memory obtained from
malloc.
 
R

Rainer Weikusat

[...]
(*) for the benefit of the idiotic pedants, yes I know what an array is,
and that this is loose but common language for memory obtained from
malloc.

This seems to mean that "Mister Twink" really doesn't care if he is a)
making any sense at all and b) actually right or wrong and c) he is
firmly convinced that only inferior lifeform would handle this anyhow
different, IOW, he is a troll and information coming from him is not
trustworthy.
 
B

BartC

Rainer Weikusat said:
[...]
(*) for the benefit of the idiotic pedants, yes I know what an array is,
and that this is loose but common language for memory obtained from
malloc.

This seems to mean that "Mister Twink" really doesn't care if he is a)
making any sense at all and b) actually right or wrong and c) he is
firmly convinced that only inferior lifeform would handle this anyhow
different, IOW, he is a troll and information coming from him is not
trustworthy.

Actually, I've generally found his technical advice sensible and practical.
 
K

Kenny McCormack

[...]
(*) for the benefit of the idiotic pedants, yes I know what an array is,
and that this is loose but common language for memory obtained from
malloc.

This seems to mean that "Mister Twink" really doesn't care if he is a)
making any sense at all and b) actually right or wrong and c) he is
firmly convinced that only inferior lifeform would handle this anyhow
different, IOW, he is a troll and information coming from him is not
trustworthy.

Your obsession and jealousy is duly noted.
 
K

Kenny McCormack

This seems to mean that "Mister Twink" really doesn't care if he is a)
making any sense at all and b) actually right or wrong and c) he is
firmly convinced that only inferior lifeform would handle this anyhow
different, IOW, he is a troll and information coming from him is not
trustworthy.

Actually, I've generally found his technical advice sensible and practical.[/QUOTE]

Be careful with that. You're likely to find yourself banned for saying
such things. You could be the next subject of Kiki's obsession...
 
C

Chris M. Thomasson

Antoninus Twink said:
AFAIK, there are no specific functions to allocate memory below the
4GB (or 2GB) line, though you _might_ be able to hack something
together with mmap().

More importantly, though, why would you want to? There may be a better
way to accomplish what you're trying to do.

The only reason I can think of why someone may want to to this is to
save memory by being able to store pointers in 32 bits instead of 64.
[...]

Another reason somebody would want to do this is to allow for two 32-bit
offsets to be mutated with 64-bit atomic instructions. Its a fairly easy way
to get a DWCAS on a 64-bit system that only offers 64-bit CAS (e.g., SPARC).
 
C

CBFalconer

BartC said:
Rainer Weikusat said:
[...]
(*) for the benefit of the idiotic pedants, yes I know what an
array is, and that this is loose but common language for memory
obtained from malloc.

This seems to mean that "Mister Twink" really doesn't care if he
is a) making any sense at all and b) actually right or wrong and
c) he is firmly convinced that only inferior lifeform would
handle this anyhow different, IOW, he is a troll and information
coming from him is not trustworthy.

Actually, I've generally found his technical advice sensible and
practical.
From what I've seen quoted, that is rare. His advice usually has
serious flaws.
 
A

Antoninus Twink

This seems to mean that "Mister Twink" really doesn't care if he is a)
making any sense at all and b) actually right or wrong and c) he is
firmly convinced that only inferior lifeform would handle this anyhow
different, IOW, he is a troll and information coming from him is not
trustworthy.

Of course, this is complete garbage.

Like 99% of programmers, I'm happy to use the same word (array) for two
different concepts ("real" arrays and malloc()'d blocks) *in contexts
where the two are interchangeable*. Competent programmers will be
sophisticated enough to make the distinction when necessary, and blur
the distinction when that makes conceptual sense.

Unfortunately, if you do that on clc without a disclaimer such as the
one above, then a half-dozen Heathfield wannabes will pile in like
jackals who've scented a kill, and take great delight in pointing out
the obvious as if they're Moses coming down from Mount Sinai (to use a
comparison from the regs' favorite book).
 
K

Kenny McCormack

Be careful with that. You're likely to find yourself banned for saying
such things. You could be the next subject of Kiki's obsession...

He has no obsession with Han. I know. He told us 20 times last week.[/QUOTE]

Does seem a bit, er, obsessive, doesn't it?
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

I still love this sig!
 
C

cr88192

Antoninus> The only reason I can think of why someone may want to to
Antoninus> this is to save memory by being able to store pointers in
Antoninus> 32 bits instead of 64. In this case, the obvious (ugly)
Antoninus> solution is to store a 64-bit "base" pointer, and then
Antoninus> instead of storing pointers to struct nodes (or whatever)
Antoninus> inside the array starting at base(*), you store 32-bit
Antoninus> (or even 16-bit) offsets.

<
i.e. doing segmented addressing on your own.

But that doesn't require any distinction between 32-bit or 64-bit heaps
(actually, there are no such separate heaps at all). I often use this
technique to manage my own data pools with fewer than 256 (or 65536)
objects, so that the object id's are short enough (only 8-bit or 16-bit
long) to make other data structures compact. There is absolutely no
need to bother with sizeof(void*) at all.

So, the question again: why would the OP want to handle 32-bit (which
doesn't exist) and 64-bit heaps separately? What is the intention?
though, technically OT for this group, I will mention that mmap provides a
flag specifically for the purpose of allocating in the low 4GB of address
space, and yes, there are some uses for this (primarily, it is useful when
doing custom compilation and linking, as x86-64 machine code typically uses
32-bits for addresses and immediates and similar, and so linking all of the
code into the lower 4GB allows a compiler to generate faster and more
compact code).

as for the 32-bit local-heap idea, yes, this is a workable approach for
data, but as can be noted, does have the cost of likely requiring data to be
accessed via handles (the local offsets).
 

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
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top