James Kuyper <jameskuyper@verizon.net> writes:

> Richard wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>
>>> Richard Tobin wrote:
>>>> In article <7kt3v4-2fi.ln1@dead.foo>,
>>> To answer the associated question: malloc() knows which memory type to
>>> allocate, because the only memory types it's allowed to allocate are
>>> memory types that can be used to construct objects of any type. If
>>> there is no such memory on a given machine, malloc() can only return a
>>> null pointer, which renders it pretty useless.
>>
>> Which is fair enough and obvious. I was making the point that a few core
>> users constantly mention that pointers can (theoretically) point to
>> different "types of memory". I think its pretty done to death now I guess.
>
> I can't see any reason why that wouldn't be possible, but when you
> brought that concept into the discussion, you should have indicated
> that you were doing so; up until your message the context of the
> discussion was much broader than just those particular kinds of
> implementations, and at least some of us thought you were still
> discussing that broader context.

I clarified this about 7 posts back in the thread to be fair.

In article <1193330904.464952.309350@o3g2000hsb.googlegroups. com>,
<jameskuyper@verizon.net> wrote:

>> Malloc() is going to be the least of your problems. How will the
>> implementation handle any structure containing different types?

>Such an object can only be allocated from memory in which both types
>can be built. If there is no such memory, then such an object cannot
>be allocated.

An implementation might be able to use outrageous operating-system
specific tricks to make it work. For example, it could allocate the
space in both kinds of memory, and return a pointer to one of them.
When it gets a trap for accessing it as the wrong kind, it could
"fix" it by doing the access in the other area.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Richard Tobin wrote:
> In article <5O0Ui.10099$MV4.9677@trnddc03>,
> James Kuyper <jameskuyper@verizon.net> wrote:
>
> >To answer the associated question: malloc() knows which memory type to
> >allocate, because the only memory types it's allowed to allocate are
> >memory types that can be used to construct objects of any type. If there
> >is no such memory on a given machine, malloc() can only return a null
> >pointer, which renders it pretty useless.
>
> Malloc() is going to be the least of your problems. How will the
> implementation handle any structure containing different types?

Such an object can only be allocated from memory in which both types
can be built. If there is no such memory, then such an object cannot
be allocated. In principle, this is no different from the fact that
most ordinary implementation of C can translate a program which will
fail to execute correctly because it has insufficient memory to
allocate all of the objects it contains.

Such an implementation would be clearly conforming if problems can
occur only for types with a size bigger than 32767. If it fails for
types smaller than that, then it can be considered conforming only by
use of a weasly interpretation of the "implementation limits" clause.
Unfortunately, thanks to the infamous "one program" clause, such a
weasely interpretation is arguably correct (and believe me, this has
been frequently and vociferously argued about).

Richard wrote:
....
> I clarified this about 7 posts back in the thread to be fair.

You didn't clarify it well enough for me. Could you identify the
particular message you're referring to?

On "Date: Mon, 22 Oct 2007 15:58:09 +0200" you wrote:
> But we are talking about values of "special memory blocks" where the
> pointers are different.

However, you said nothing about the manner in which those memory
blocks were special.

On "Date: Tue, 23 Oct 2007 14:28:39 +0200" You wrote that
> We were talking about pointers being different sizes because they are
> used to point to different areas in memory. Or I was.

However you didn't specify what makes those areas different.

I can't find any other message you sent that even comes close to
clarifying the fact that you were talking about special memory blocks
that differ from regular memory blocks because some object types can
only be constructed in particular memory blocks. And I can find no
evidence suggesting that anyone else was talking about such blocks
until you brought them up, claiming that they were what other people
were already talking about.

Other people were talking only about the more general case of
implementations where pointers to different types can have different
sizes.

>>> But we are talking about values of "special memory blocks" where the
>>> pointers are different. How does malloc know which "memory type" to
>>> allocate?
>
>> Memory has no type. Objects have type, and they occupy memory. But
>>memory is not objects. It is merely location, a place for objects to
>>reside.
>
>You are misunderstanding the question. It's about computers where
>certain types can only be stored in certain parts of memory, perhaps
>each with their own kind of pointer. On such systems, memory isn't
>merely location.

Consider a specific (nightmare) case where the sign bit of an integer
type can only be stored in signed memory and the other bits of an
integer type can only be stored in unsigned memory. (It's some
kind of odd hardware and legal restriction. Signed memory and
unsigned memory were assigned to different contractors. Signed
memory is from 0xf8000000 to 0xffffffff and unsigned memory is
0x00000000 to 0xf7ffffff). A pointer to an integer might then
consist of the address of the sign bit and the address of the rest
of the bits, concatenated into a "fat" pointer.

The trouble is, I don't think this can fit into the C model.
There are numerous oddities:

- malloc() has to allocate sign bits for every byte just in case the
memory is used as signed bytes *and* it has to allocate a high-order
(non-sign) bit just in case the memory is used as unsigned bytes.
- Pointers to signed integers are twice as big as pointers to unsigned
integers.
- memcpy() can only copy unsigned integers; it loses the sign bits of
signed integers. This, I believe, is prohibited by the standard.
- What do you do about signed integers inside dynamically-allocated
structures?
- Casting a pointer to signed integer to a pointer to unsigned integer and
back loses information. Is this acceptable per the standard? This
particularly includes casting from a void pointer (which much be "signed"
for malloc() to be able to allocate memory for signed integers) to
a pointer to unsigned char and back losing information.

More nightmares: exponents, mantissas, and exponent sign bits must all
be in separate blocks of memory.

"Gordon Burditt" <gordonb.l6q0a@burditt.org> a écrit dans le message de
news: 13i2bm5pmm9if8d@corp.supernews.com...
>>>> But we are talking about values of "special memory blocks" where the
>>>> pointers are different. How does malloc know which "memory type" to
>>>> allocate?
>>
>>> Memory has no type. Objects have type, and they occupy memory. But
>>>memory is not objects. It is merely location, a place for objects to
>>>reside.
>>
>>You are misunderstanding the question. It's about computers where
>>certain types can only be stored in certain parts of memory, perhaps
>>each with their own kind of pointer. On such systems, memory isn't
>>merely location.
>
> Consider a specific (nightmare) case where the sign bit of an integer
> type can only be stored in signed memory and the other bits of an
> integer type can only be stored in unsigned memory. (It's some
> kind of odd hardware and legal restriction. Signed memory and
> unsigned memory were assigned to different contractors. Signed
> memory is from 0xf8000000 to 0xffffffff and unsigned memory is
> 0x00000000 to 0xf7ffffff). A pointer to an integer might then
> consist of the address of the sign bit and the address of the rest
> of the bits, concatenated into a "fat" pointer.
>
> The trouble is, I don't think this can fit into the C model.
> There are numerous oddities:
>
> - malloc() has to allocate sign bits for every byte just in case the
> memory is used as signed bytes *and* it has to allocate a high-order
> (non-sign) bit just in case the memory is used as unsigned bytes.
> - Pointers to signed integers are twice as big as pointers to unsigned
> integers.
> - memcpy() can only copy unsigned integers; it loses the sign bits of
> signed integers. This, I believe, is prohibited by the standard.
> - What do you do about signed integers inside dynamically-allocated
> structures?
> - Casting a pointer to signed integer to a pointer to unsigned integer and
> back loses information. Is this acceptable per the standard? This
> particularly includes casting from a void pointer (which much be "signed"
> for malloc() to be able to allocate memory for signed integers) to
> a pointer to unsigned char and back losing information.
>
> More nightmares: exponents, mantissas, and exponent sign bits must all
> be in separate blocks of memory.

Useless mental masturbation.
Get a life!

--
Chqrlie.

Richard <rgrdev@gmail.com> wrote:

> Which is fair enough and obvious. I was making the point that a few core
> users constantly mention that pointers can (theoretically) point to
> different "types of memory". I think its pretty done to death now I guess.

Would you care to point out where anybody except you has done that? For
example, until you brought it up, all the rest of us had been talking
about in this thread were different types of _pointer_, not memory.

Richard

jameskuyper@verizon.net writes:
<snip>
> Other people were talking only about the more general case of
> implementations where pointers to different types can have different
> sizes.

So was everyone else up to this point:

MisterE <Mist...@nimga.com>:
| Pointers of any type will have the same size because they hold the address
| value of memory that they point to, thus they always hold the same type of
| data. On standard PC's this is a 32bit address (4 bytes), but it depends on
| the system what the size is.

Barry Schwarz <schwarz45@yahoo.com>:
| While this may be true in your experience, the C standard imposes no
| such restriction. Furthermore, there are systems for which it is not
| true.

Richard <rgrdev@gmail.com>
|Could you explain how malloc works for such systems please.

The only way I can see the odd (and almost impossible to implement)
idea of separate memory for some types creeping in is if Richard
misunderstood the exchange: "thus they always hold the same kind of
data" / "C imposes not such restriction" as Barry Schwarz suggesting
separate memory blocks for some types.

It seems clear to me that MisterE was referring to all *pointers*
holding the same type (meaning kind, not type in the C sense) of data
and thus were always the same size (wrong, of course) and it was
simply that error that Barry Schwarz was correcting.

I can see how it could be misread, but Richard's one-liner did not
. Had he written "Could you explain how malloc works if different
types must reside in separate areas of memory" all this could have
been avoided.

I don't see where Richard gets the idea that 'a few core users
constantly mention that pointers can (theoretically) point to
different "types of memory"' unless he is talking about the common
remark that function pointers are different. Many systems separate
code from data in ways that make the conversion between pointers into
these areas either pointless or undefined, but that has no
consequences for malloc since malloc can only allocate data.

I hope this s clarify where the confusion started. If it does
not, just ignore me -- or simply say "no, not ful". Another long
sub-thread about how I've got this summary wrong will just mess things
up even more!

--
Ben.

Richard Bos wrote:
> Richard <rgrdev@gmail.com> wrote:
>
>> Which is fair enough and obvious. I was making the point that a few core
>> users constantly mention that pointers can (theoretically) point to
>> different "types of memory". I think its pretty done to death now I guess.
>
> Would you care to point out where anybody except you has done that? For

Yes, please - I'd like to find out what precisely they were talking
about. This isn't a characteristic of any system I'm aware of. I've been
thinking about it for a day or so now, and so far I haven't found any
insuperable obstacles to creating a conforming implementation with that
characteristic, though that is probably just because I haven't thought
about it long enough. However, even if creating a conforming
implementation with that feature is possible, I can't imagine why anyone
might want to do so.

I just did a quick Google search for "types of memory". The types I've
found discussions of include:

ROM vs. RAM
code vs. data
stack vs. heap
static vs. dynamic vs. allocated.

However, I could not find any discussion of data types that could only
be allocated in certain types of memory with different pointer sizes.

santosh <santosh.k83@gmail.com> writes:
[...]
> The point was that different pointer types might differ in size. That
> doesn't mean that the memory pool from which malloc gets space has to
> be different for each differing pointer types.

Right. Pointers can differ; that doesn't mean that the memory they
point to can differ.

> It may be that the implementation, for example, decides to append extra
> information with pointers to floating types, but not to other types. In
> this case such pointers might conceivably be larger than others.

Right. Perhaps more realistically, on a system where machine pointers
point to words (where a word is several byte), an int* might be, say,
4 bytes, but a char* might be larger, with extra information added to
resolve which byte within the word it points to.

> Also an implementation might decide to allocate objects of a certain
> type in lower address spaces than others. In such a case, pointers to
> that type may be of smaller width, though the memory for the entire
> gamut is the same.

I don't believe a conforming implementation can do this, at least not
consistently. A pointer returned by malloc must be able to point to
any type of object; similarly, it's possible to declare a union of any
two or more object types. Restricting objects of a certain type to be
allocated only at low addresses might be possible, but other objects
would be dragged in as well.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Tue, 23 Oct 2007 10:33:04 -0700, jameskuyper@verizon.net wrote:
<snip: different data pointer types may have different sizes>
> Well, the most frequently cited case where pointers of different types
> have different sizes are implementations targeted for machines where
> the smallest directly addressable memory unit is much larger than the
> size that the implementor wishes to use for char. My favorite example,
> because it violates so many preconceptions, would be the PDP machines
> where the word size was 36, which could be used as the basis for a C
> implementation with CHAR_BITS=9 (whether this has ever actually been
> done has been frequently asked, and seldom answered: the point is, it
> could have been done; and something similar has been done on many
> other more conventional systems).
>
> On such implementations, addressibility of individual bytes is not
> performed directly by the hardware, but is emulated in software, by
> using a pointer that contains both a memory address and a byte
> offset.The compiler inserts bit-masking operations as needed to
> extract (or insert) the correct byte out of the specified word of
> memory.
>
Your basic point is correct, but you've got the details fuzzed.

The two architectures in the (DEC) PDP line with 36-bit word
addressing were PDP-6 and PDP-10; the latter for sure and I believe
also the former did have special byte instructions. MOST instructions
accessed a 36-bit word (and in a few cases more than one word) using a
word address either fixed or computed, but certain instructions used a
different format address, called logically enough a byte pointer, to
access a byte of any size anywhere wholly within a word, that is any
contiguous 1 to 36 bits at any bit offset of 0 to 36-W.

In fact because of the importance of -10's in the early hacker (in the
original good sense) ARPAnet and pre-commercial Internet community,
the -10 assembly mnemonics LDB and DPB were common early hackish for
'extract' and 'insert'; IBP ILDB and IDPB were used much less, and
ADJBP only as a deliberately self-parodying joke.

Several other machines in the PDP line had 18-bit words (-4 -7 -9) or
12-bit words (-5 -8 -12) and bytes (or characters) within a word were
indeed accessed by explicit shifts and masks. (Well, except that some
DEC software in some places represented characters in radix 40, so
those were 'stored' and 'fetched' using arithmetic operations.)

There are also machines with byte addressing but not byte access, like
early Alpha's also from DEC, which thus used shifts and masks. But
that is less relevant to the question of representation of pointers.

- formerly david.thompson1 || achar(64) || worldnet.att.net