Re: Far and near pointers
Jonathan de Boyne Pollard
>>
>> It's *not* just the compiler writers who have to be cognizant of the
>> segmentation models. When the application programmer used C within
>> Mess-DOS, he/she had to futz with memory models too!!! A pointer is
>> *not* just a pointer, it has to be a "far" pointer or a "near"
>> pointer, or some other awful variety...
>>
> However, no one has had to program in that model for over 15 years.
>
x86 systems programmers have. If one is using the C or C++ languages to
marshal data over the system call interface, far pointers are what one
uses, with careful attention to segmentation so that one uses the
correct privilege levels.
Jonathan de Boyne Pollard
>
> I believe the Watcom 32 bit compilers can (or could, maybe removed by
> now) large model (16 bit selector, 32 bit offset) code.
>
OpenWatcom version 1.9 is currently at its first release candidate.
16:32 far pointer support is, to the best of my knowledge, still there.
There's no reason to remove it. Indeed, the far pointer capabilities of
the compiler have been worked on by the developers for this release.
(Initialization of 16:16 far pointers with static storage duraction has
been improved. See the release notes for details.)
> It might be that OS/2 know what to do with that, I don't believe any
> other OS does.
>
One tends to use that sort of thing for systems programming, rather than
applications programming. In the case of OS/2, for example, there's not
much scope for using 16:32 far pointers in applications code, which is
almost always the Tiny model for 32-bit programs, but in kernel mode
code there are at least a couple of 32-bit segments that one might want
to work with using far pointers.
Ian Collins
Please stop this asinine cross posting.
--
Ian Collins
Kenny McCormack
Ian Collins <ian-...@hotmail.com> wrote:
>On 03/22/10 10:56 PM, Jonathan de Boyne Pollard wrote:
>
>Please stop this asinine cross posting.
(Reading in comp.lang.c, the funniest and most entertaining newsgroup on
the Usenet)
Yes, I was just about to ask where the CLC topicality police were hiding
out and why they were ignoring this thread. I was about to make the
usual comment about the double standard - how only the newbies get
pounded on for being "OT".
Thanks Ian - you've restored my faith in (what passes for ... in CLC)
humanity.
--
(This discussion group is about C, ...)
Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...
1022 guy
Jonathan de Boyne Pollard
>
> Yes, I was just about to ask where the CLC topicality police were
> hiding out and why they were ignoring this thread.
>
language in newsgroups relevant to that compiler and the C language!
Emily PostNews would have a fit. I'm not sure how Ian Collins expects
the rest of us to stop his so-called "asinine" cross-posting for him,
though.
Returning to what we were talking about before the silly diversion, I
should point out that 32-bit applications programming where the target
is extended DOS or 32-bit Win16 (with OpenWatcom's extender) will also
occasionally employ 16:32 far pointers of course. But as I said before,
regular 32-bit OS/2 or Win32 applications programming generally does
not, since those both use the Tiny memory model, and 16:32 far pointers
are generally confined to the realms of systems programming on the
relevant operating systems. (Systems programming on Windows NT usually
will not involve them, since the gory details of specialized I/O and
memory accesses are abstracted away within C/C++ macros and library
functions for systems programmers on Windows NT. But systems
programming on DOS-Windows 9x/ME and OS/2 may well.)
Peter Flass
>
> should point out that 32-bit applications programming where the target
> is extended DOS or 32-bit Win16 (with OpenWatcom's extender) will also
> occasionally employ 16:32 far pointers of course. But as I said before,
> regular 32-bit OS/2 or Win32 applications programming generally does
> not, since those both use the Tiny memory model,
Flat memory model.
Branimir Maksimovic
Problem with standard C and C++ is that they assume flat memory
model.
Eg pointer to char can have more than one type, in different
addressing modes.
It's not covered by standard. Since C and C++ aren't designed
to run in virtual machine, those are real problems.
Obvious advantage of segmented architecture is memory saving
you get for using short pointers , when appropriate.
Imagine just how memory is wasted in 64 bit environment...
"
In 64-bit mode (a sub-mode of IA-32e mode), a near pointer is 64 bits. This
equates to an effective address. Far pointers in 64-bit mode can be one of three
forms:
• 16-bit segment selector, 16-bit offset if the operand size is 32 bits
• 16-bit segment selector, 32-bit offset if the operand size is 32 bits
• 16-bit segment selector, 64-bit offset if the operand size is 64 bits
"
So, problem with flat model is that it is *not* most effective when
you waste 8 bytes for pointer that could take half of that!
Greets!
Sometimes online sometimes not
Ben Bacarisse
> On Tue, 23 Mar 2010 06:51:18 -0400
> Peter Flass <Peter...@Yahoo.com> wrote:
>
>> Jonathan de Boyne Pollard wrote:
>> >
>> > Returning to what we were talking about before the silly diversion,
>> > I should point out that 32-bit applications programming where the
>> > target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
>> > will also occasionally employ 16:32 far pointers of course. But as
>> > I said before, regular 32-bit OS/2 or Win32 applications
>> > programming generally does not, since those both use the Tiny
>> > memory model,
>>
>> Flat memory model.
>
> Problem with standard C and C++ is that they assume flat memory
> model.
> Eg pointer to char can have more than one type, in different
> addressing modes.
I think you mean: "The problem with standard C and C++ is that they
assume a single memory model. In contrast, hardware pointers come in
many forms in different addressing modes."
I don't usually comment on language but I kept re-reading what you
unable to work out what it was you were saying.
If this is what you did mean, then I agree and I have no other reason
to post! If you did mean that C assumes a flat memory model, then I'd
disagree.
<snip>
--
Ben.
Branimir Maksimovic
Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> Branimir Maksimovic <bm...@hotmail.com> writes:
>
> > On Tue, 23 Mar 2010 06:51:18 -0400
> > Peter Flass <Peter...@Yahoo.com> wrote:
> >
> >> Jonathan de Boyne Pollard wrote:
> >> >
> >> > Returning to what we were talking about before the silly
> >> > diversion, I should point out that 32-bit applications
> >> > programming where the target is extended DOS or 32-bit Win16
> >> > (with OpenWatcom's extender) will also occasionally employ 16:32
> >> > far pointers of course. But as I said before, regular 32-bit
> >> > OS/2 or Win32 applications programming generally does not, since
> >> > those both use the Tiny memory model,
> >>
> >> Flat memory model.
> >
> > Problem with standard C and C++ is that they assume flat memory
> > model.
> > Eg pointer to char can have more than one type, in different
> > addressing modes.
>
> I think you mean: "The problem with standard C and C++ is that they
> assume a single memory model. In contrast, hardware pointers come in
> many forms in different addressing modes."
>
My English is not that good, thank you for explaining it .
> I don't usually comment on language but I kept re-reading what you
> unable to work out what it was you were saying.
>
> If this is what you did mean, then I agree and I have no other reason
> to post! If you did mean that C assumes a flat memory model, then I'd
> disagree.
Yes, you can;t subtract two pointers which are not within same array.
That allows segmented model to work.
Ben Bacarisse
> On Tue, 23 Mar 2010 12:09:27 +0000
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
<snip>
> My English is not that good, thank you for explaining it .
>
>> I don't usually comment on language but I kept re-reading what you
>> unable to work out what it was you were saying.
Neither is mine, as I have just spotted by re-reading what I wrote!
[BTW I don't normally have any trouble understanding what you write.]
<snip>
--
Ben.
Jonathan de Boyne Pollard
>>
>> Returning to what we were talking about before the silly diversion, I
>> should point out that 32-bit applications programming where the
>> target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
>> will also occasionally employ 16:32 far pointers of course. But as I
>> said before, regular 32-bit OS/2 or Win32 applications programming
>>
> Flat memory model.
>
It's the same thing. Think about it. In the flat memory model
DS=ES=SS=CS (modulo the various required differences between code and
data segment descriptors) and all pointers are near. That's the
definition of the tiny memory model. The flat memory model is the tiny
memory model.
Since we are discussing OpenWatcom, I point to the OpenWatcom Users
Guide as one place where you can see this for yourself quite easily. In
the 16-bit Memory Models section, you'll find a Summary of 16-bit Memory
Models subsection, with a table. In the 32-bit Memory Models section,
you'll find a Summary of 32-bit Memory Models subsection, with a table.
Compare the tables in the twain, and you'll see that the row labelled
"tiny" in the former is labelled "flat" in the latter.
There's no real distinction between the twain (apart from some
implementation-specific pre-defined macros). 32-bit flat model
programming is 32-bit tiny model programming, and 16-bit tiny model
programming is 16-bit flat model programming. In all, near pointers to
automatic storage data, heap storage data, static storage data, and code
can be casted to one another without differences in assumed segment
registers causing problems. In all, the code generator doesn't emit
segment re-loads, or even segment overrides, when using the default
pointer sizes. In all, near forms of instructions are used.
Nick
writes:
PLEASE! Don't cut all the attributions. I've seen you asked this more
than once in a different newsgroup in the last few days and you've
ignored the requests. Please listen to them.
>>
>>>
[content snipped]
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Richard Bos
> On 03/22/10 10:56 PM, Jonathan de Boyne Pollard wrote:
>
> Please stop this asinine cross posting.
That crossposting was, for once, not asinine. It served as a nice
example why, even now, Leenux weenies are not correct when they insist
that C has a flat memory model and all pointers are just numbers.
Richard
robert...@yahoo.com
newsgro...@NTLWorld.COM> wrote:
> >> Returning to what we were talking about before the silly diversion, I
> >> should point out that 32-bit applications programming where the
> >> target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
> >> will also occasionally employ 16:32 far pointers of course. But as I
> >> said before, regular 32-bit OS/2 or Win32 applications programming
> >> generally does not, since those both use the Tiny memory model, [...]
>
> > Flat memory model.
>
> It's the same thing. Think about it. In the flat memory model
> DS=ES=SS=CS (modulo the various required differences between code and
> data segment descriptors) and all pointers are near. That's the
> definition of the tiny memory model. The flat memory model is the tiny
> memory model.
Just to be pedantic, while DS==ES==SS (IOW, they contain exactly the
same selector), CS contains a *different* selector than the other
three segment registers in flat model. The descriptor for the CS
selector specifies the same base address and limit (usually), and thus
overlaps the data descriptor referenced by the other segment
registers, so all of them address the same memory. But they are not
interchangeable - while you could load the code selector into DS, an
attempt to store data would then generate an exception. Conversely
attempting to load a data selector into CS will trigger an exception.
This is different from the real-mode "tiny" model, where CS would be
loaded with the same segment value as DS, ES and SS. So I’d have to
say that using “tiny model” to mean “flat model” is at least slightly
incorrect.
Branimir Maksimovic
Hm , I think that protection mechanism id done on page level rather
on segment level. JIT couldn;t be possible in case of whole CS
segment is marked as read/execute only.
JIT could have to hack into more privileged level in order to perform
writes/instruction cache flush/execute.
Greets
glen herrmannsfeldt
(snip)
> That crossposting was, for once, not asinine. It served as a nice
> example why, even now, Leenux weenies are not correct when they insist
> that C has a flat memory model and all pointers are just numbers.
Well, you could also read the C standard to learn that.
There are additional complications for C on the PDP-10.
-- glen
Peter Flass
> On Tue, 23 Mar 2010 06:51:18 -0400
> Peter Flass <Peter...@Yahoo.com> wrote:
>
>> Jonathan de Boyne Pollard wrote:
>>> Returning to what we were talking about before the silly diversion,
>>> I should point out that 32-bit applications programming where the
>>> target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
>>> will also occasionally employ 16:32 far pointers of course. But as
>>> I said before, regular 32-bit OS/2 or Win32 applications
>>> programming generally does not, since those both use the Tiny
>>> memory model,
>> Flat memory model.
>
> Problem with standard C and C++ is that they assume flat memory
> model.
I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
as I know there's nothing in the C standard that assumes anything about
pointers, except that they have to be the same size as int, so for 16:32
pointers I guess you'd need 64-bit ints.
As far as implementations are concerned, both Watcom and IBM VA C++
support segmented memory models. These are the ones I'm aware of, there
are probably more.
Branimir Maksimovic
Peter Flass <Peter...@Yahoo.com> wrote:
> Branimir Maksimovic wrote:
> > On Tue, 23 Mar 2010 06:51:18 -0400
> > Peter Flass <Peter...@Yahoo.com> wrote:
> >
> >> Jonathan de Boyne Pollard wrote:
> >>> Returning to what we were talking about before the silly
> >>> diversion, I should point out that 32-bit applications
> >>> programming where the target is extended DOS or 32-bit Win16
> >>> (with OpenWatcom's extender) will also occasionally employ 16:32
> >>> far pointers of course. But as I said before, regular 32-bit
> >>> OS/2 or Win32 applications programming generally does not, since
> >>> those both use the Tiny memory model,
> >> Flat memory model.
> >
> > Problem with standard C and C++ is that they assume flat memory
> > model.
>
> I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as
> far as I know there's nothing in the C standard that assumes anything
> about pointers, except that they have to be the same size as int, so
> for 16:32 pointers I guess you'd need 64-bit ints.
No, 32. You would load 16 bit selector into segment register.
Regarding 64 bit mode on Intel, segmentation is disabled, not
used, none, but you can save on memory if you are using 32
bit operands and you don;t need more than 4gb of ram.
So basically you can program like in 32 bit mode almost
completely (stack requires different alignment dough)
but you can save on memory if you could have
both 32 bit and 64 bit pointer to char eg.
This is not about segmentation, but memory savings.
Of course, you can always, compile as 32 bit ;),
or I guess there are 64 bit mode switches to
choose sizes, but AMD made it that way that you can
actually *mix* 32 bit with 64 it code ;)
Seebs
> I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
> as I know there's nothing in the C standard that assumes anything about
> pointers, except that they have to be the same size as int, so for 16:32
> pointers I guess you'd need 64-bit ints.
Uh, no. Pointers do not have to be the same size as int. It's not even
strictly guaranteed that there is *ANY* integer type that is the same size
as a pointer, but if there is an integer that can safely hold pointer
values, it should be available as intptr_t in C99. In C89, there was nothing.
So, no, pointer does not have to be the same size as int, and I've used
plenty of systems where it wasn't.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Flash Gordon
> Branimir Maksimovic wrote:
>> On Tue, 23 Mar 2010 06:51:18 -0400
>> Peter Flass <Peter...@Yahoo.com> wrote:
>>
>>> Jonathan de Boyne Pollard wrote:
>>>> Returning to what we were talking about before the silly diversion,
>>>> I should point out that 32-bit applications programming where the
>>>> target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
>>>> will also occasionally employ 16:32 far pointers of course. But as
>>>> I said before, regular 32-bit OS/2 or Win32 applications
>>>> programming generally does not, since those both use the Tiny
>>>> memory model,
>>> Flat memory model.
>>
>> Problem with standard C and C++ is that they assume flat memory
>> model.
>
> I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
> as I know there's nothing in the C standard that assumes anything about
> pointers, except that they have to be the same size as int, so for 16:32
> pointers I guess you'd need 64-bit ints.
There is no requirement in the standard that pointers are the same size
as int. In fact, there is no requirement that there is *any* integer
type the same size (or as large as) a pointer. There is also no
requirement that pointers of all types are the same size.
> As far as implementations are concerned, both Watcom and IBM VA C++
> support segmented memory models. These are the ones I'm aware of, there
> are probably more.
I'm sure there have been a number of processors with segmented
architectures, and that a number of them will have had C compilers, so
there are almost certainly more.
--
Flash Gordon
Jonathan de Boyne Pollard
>>
>> It's the same thing. Think about it. In the flat memory model
>> DS=ES=SS=CS (modulo the various required differences between code and
>> data segment descriptors) and all pointers are near. That's the
>> definition of the tiny memory model. The flat memory model is the
>> tiny memory model.
>>
> Just to be pedantic, while DS==ES==SS (IOW, they contain exactly the
> same selector), CS contains a *different* selector than the other
>
That's not being pedantic. That's simply ignoring what I put in the
parentheses. It's also commits the common "just to be pedantic" error
of being outright wrong if one really were being pedantic. (-: If you
look at what an x86 processor actually does with the segment descriptor
cache in real and v8086 modes, you'll see that in fact there are
differences between CS on the one hand and DS/ES/SS on the other in
real/v8086 mode, which you are incorrectly asserting to be the sole
domain of the tiny model, just as there are differences between the two
in protected mode, which you are incorrectly asserting to be the sole
domain of the flat model. Both real/v8086 and protected modes make this
distinction, and this is not, therefore, something that distinguishes
the flat model from the tiny model. Processor execution modes and
program memory models are largely disjoint concepts.
There are plenty of articles by Robert R. Collins in Dr Dobbs' Journal
from the late 1990s on this subject that one can read for onesself,
which I'm not going to laboriously re-hash. A breif précis only then:
Whilst the documentation may suggest that the descriptor cache is
ignored in real and v8086 modes, the reality is that in real and v8086
modes the segment descriptors are still re-loaded with appropriate
(hardwired) values upon a re-load of any segment register, and the
values in the descriptor registers are not wholly ignored but are in
fact still used by the address calculation hardware. The idea that the
CS segment descriptor is the same as the DS/ES/SS segment descriptors in
the tiny model, because only the selector register values themselves
count in real/v8086 modes, is thus a falsehood. The segment descriptors
have effect in all three of real, v8086, and protected modes. Moreover,
this effect has much the same split in real/v8086 modes as in protected
mode. There's special-case processing for the CS segment descriptor in
real/v8086 modes that differentiates it from the DS/ES/SS segment
descriptors. The supposed lack of distinction amongst or use of segment
descriptors, that makes flat model a protected-mode-only thing and tiny
model a real/v8086-mode-only thing, is bogus. Read Robert R. Collins'
articles for a lot more on this.
As I said before, the two are, in reality, only really distinguished by
some pre-defined macros. Those macros aside, the C/C++ language pointer
semantics that one sees, with all pointers being near pointers, the
things that the code generator does, with no selector re-loads or
segment register overrides employed, and the instruction forms used,
with all instructions using their near address forms, are the same for
both flat and tiny models.
Gordon Burditt
>> same selector), CS contains a *different* selector than the other
>> three segment registers in flat model. The descriptor for the CS
>> selector specifies the same base address and limit (usually), and thus
>> overlaps the data descriptor referenced by the other segment
>> registers, so all of them address the same memory. But they are not
>> interchangeable - while you could load the code selector into DS, an
>> attempt to store data would then generate an exception. Conversely
>> attempting to load a data selector into CS will trigger an exception.
>
>Hm , I think that protection mechanism id done on page level rather
>on segment level. JIT couldn;t be possible in case of whole CS
>segment is marked as read/execute only.
>JIT could have to hack into more privileged level in order to perform
>writes/instruction cache flush/execute.
No, JIT can *write* through DS and *execute* through CS. It has
to assume that the OS has mapped the two segments to the same piece
of memory (with different permissions ).
Page-level access permissions (on x86) don't allow for different
access through different segment descriptors. That would break
JIT.
One of the reasons for many of the odd restrictions of C, such as
not allowing subtraction of pointers that don't point to the same
object, is to allow far pointers to be used as pointers. What you
don't get to do is portably mix near pointers and far pointers.
Pick one format and call them "pointers".
robert...@yahoo.com
newsgro...@NTLWorld.COM> wrote:
> >> It's the same thing. Think about it. In the flat memory model
> >> DS=ES=SS=CS (modulo the various required differences between code and
> >> data segment descriptors) and all pointers are near. That's the
> >> definition of the tiny memory model. The flat memory model is the
> >> tiny memory model.
>
> > Just to be pedantic, while DS==ES==SS (IOW, they contain exactly the
> > same selector), CS contains a *different* selector than the other
> > three segment registers in flat model. [...]
>
> That's not being pedantic. That's simply ignoring what I put in the
> parentheses. It's also commits the common "just to be pedantic" error
> of being outright wrong if one really were being pedantic. (-: If you
> look at what an x86 processor actually does with the segment descriptor
> cache in real and v8086 modes, you'll see that in fact there are
> differences between CS on the one hand and DS/ES/SS on the other in
> real/v8086 mode, which you are incorrectly asserting to be the sole
> domain of the tiny model, just as there are differences between the two
> in protected mode, which you are incorrectly asserting to be the sole
> domain of the flat model. Both real/v8086 and protected modes make this
> distinction, and this is not, therefore, something that distinguishes
> the flat model from the tiny model. Processor execution modes and
> program memory models are largely disjoint concepts.
OK, to quote you: "In the flat memory model DS=ES=SS=CS (modulo the
various required differences between code and data segment
descriptors) and all pointers are near." The last part is certainly
true ("all pointers are near"), and the parenthetical is reasonably
correct (the code descriptor must be somewhat different than the data
descriptor). The pedantic correction has to do with the assertion
"DS=ES=SS=CS". Without additional comment this is manifestly untrue
in flat model, as you could execute the following code:
mov ax,ds
mov bx,cs
cmp ax,bx
and the Z flag will *not* be set. The contents of those registers
are, to a resonable extent (at least so long as the program avoid
trying to store via CS) *logically* equivilent, but certainly they are
not equal. And equality is what is specified by the chosen operators
in "DS=ES=SS=CS". Practical difficulties aside (as in it's not an
ASCII character), the triple-bar equivalence symbol would certainly
make *your* meaning clear, but you simply can't assume that as the
default interpretation of "=".
The correction is also pedantic (in the common sense of minutia)
because most flat model application never attempt to store through CS,
and never actually inspect or modify the values in the segment
registers, so for them there is no practical difference between
equality and equivalence.
In real mode, ignoring some of the odder effect possible from getting
unusual values loaded into the descriptor cache, the values in the
segment register *are* equal (and also logically equivalent, but
that's trivial).
(...true but irrelevant stuff about descriptor cache operation
snipped...)
> As I said before, the two are, in reality, only really distinguished by
> some pre-defined macros. Those macros aside, the C/C++ language pointer
> semantics that one sees, with all pointers being near pointers, the
> things that the code generator does, with no selector re-loads or
> segment register overrides employed, and the instruction forms used,
> with all instructions using their near address forms, are the same for
> both flat and tiny models.
I never disagreed with any of that.
Nick Keighley
> In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
> (snip)
>
> > That crossposting was, for once, not asinine. It served as a nice
> > example why, even now, Leenux weenies are not correct when they insist
> > that C has a flat memory model and all pointers are just numbers.
>
> Well, you could also read the C standard to learn that.
but if you say that you get accused of language lawyering.
"Since IBM stopped making 360s no C program ever needs to run on such
a platform"
Dann Corbit
63ab37...@d37g2000yqn.googlegroups.com>,
nick_keigh...@hotmail.com says...
We have customers who are running their business on harware from the mid
1980s. It may sound ludicrous, but it if solves all of their business
needs, and runs solid 24x365, why should they upgrade?
Richard Bos
> In alt.sys.pdp10 Richard Bos <ral...@xs4all.nl> wrote:
>
> > That crossposting was, for once, not asinine. It served as a nice
> > example why, even now, Leenux weenies are not correct when they insist
> > that C has a flat memory model and all pointers are just numbers.
>
> Well, you could also read the C standard to learn that.
Yes, but Leenux weenies who post to comp.lang.c are frequently found to
be remarkably unable either to do that, or to believe that what they
read there applies to what it pleases them to call "the real world"
(i.e., Leenux-weenieworld).
Richard
Richard Bos
> Branimir Maksimovic wrote:
> > Problem with standard C and C++ is that they assume flat memory
> > model.
Nonsense.
> I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
> as I know there's nothing in the C standard that assumes anything about
> pointers, except that they have to be the same size as int,
There is absolutely nothing in the C Standard that requires pointers to
have the size of int, or even the size of anything whatsoever, except
that
- void pointers and char pointers shall have the same representation
(and therefore size) as one another - _not_ necessarily as any other
kind of pointer, though since void pointers must be able to be freely
convertible from and to other object pointers, it takes a perverted
implementation to make them _smaller_ than other object pointers (but
perversion, though not advised, is allowed implementation authors);
- pointers to const <foo> must have the same representation as pointers
to <foo> and vice versa, and ditto for volatile and restrict;
- all pointers to struct must have the same representation, and all
pointers to union (but struct pointers need not be the same as union
pointers; again, it would usually be silly not to have them be, but
it's allowed).
Nothing about ints there.
Richard
Branimir Maksimovic
ral...@xs4all.nl (Richard Bos) wrote:
> Peter Flass <Peter...@Yahoo.com> wrote:
>
> > Branimir Maksimovic wrote:
>
> > > Problem with standard C and C++ is that they assume flat memory
> > > model.
>
> Nonsense.
>
Well, technically this is not nonsense. There are no built in
features to portably accommodate different memory models.
Problem is that sizeof(char*) can be realistically
in some situation 4 bytes in other 8 bytes , and
third 2 bytes even in same function.
Is this allowed by standard C and C++?
If this is allowed then yes, C and C++ does not assume
flat memory model.
Branimir Maksimovic
Problem is that segmented memory model is much better when working
with 64 bit address space. Flat memory model wastes to much
RAM. It would be better for standard C and C++ to provide appropriate
pointer semantics in order to keep memory usage optimal.
What is use of 64 bit flat pointers when you can actually
just load segment base and work with offsets?
Actually compilers are forced to use maximum possible
size of pointer in order to cover all possible sizes,
because of memory model forced by C and C++.
This is not about segmented flat model.
It is about different addressing modes even in flat model.
It seems that besides flat memory model C and C++ assumes
always absolute addressing pointers.
Technically this limitation can be easily circumvented
if different sizes of pointers to same type are allowed.
Ok, void* should be maximum size, but there is no reason
you can't have different sizes for char*.
Peter Flass
Yes, I've gotten a few corrections on this;-) I guess what I was
thinking of is a statement I've heard several times that lots of
existing C code *assumes* sizeof(ptr) = sizeof(int), and breaks when
this isn't true.
Branimir Maksimovic
It is strange that one have to check for size of pointer, because
you can always implement segmented/relative addressing model,
buy using shorts/ints/longs/longlongs as pointers
into array(segment) and implement far near pointer thing,
without problem thanks to malloc and brilliant design
of C arrays that can map to 1-1 to real segment.
Technically besides void* (as a base) there is no real use of any
other type of C or C++ pointer in portable code.
Ints would do perfectly. No need to check for sizes of pointers
at all ;)
Greets
Ahem A Rivet's Shot
Branimir Maksimovic <bm...@hotmail.com> wrote:
> On Wed, 24 Mar 2010 09:48:12 GMT
> ral...@xs4all.nl (Richard Bos) wrote:
>
> > Peter Flass <Peter...@Yahoo.com> wrote:
> >
> > > Branimir Maksimovic wrote:
> >
> > > > Problem with standard C and C++ is that they assume flat memory
> > > > model.
> >
> > Nonsense.
> >
> Well, technically this is not nonsense. There are no built in
> features to portably accommodate different memory models.
> Problem is that sizeof(char*) can be realistically
> in some situation 4 bytes in other 8 bytes , and
> third 2 bytes even in same function.
> Is this allowed by standard C and C++?
Having the underlying addressing mechanism of the processor use
different sizes of address for different contexts does not require a C
implementation to follow suit. Nothing requires C pointers to be addresses
they could be larger structures that include enough information for the
compiler to generate an address of the appropriate type when needed (or
otherwise retrieve the data being pointed to).
> If this is allowed then yes, C and C++ does not assume
> flat memory model.
It doesn't - all that C requires of pointers is that they can be
dereferenced, converted to void pointers and back again, and that adding
and subtracting integers works within certain well defined limits. Nothing
requires them to be machine addresses.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Nick Keighley
> In article <1e27d5ee-a1b1-45d9-9188-
> 63ab37398...@d37g2000yqn.googlegroups.com>,
> nick_keighley_nos...@hotmail.com says...
> > On 23 Mar, 20:56, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > > In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
> > > > That crossposting was, for once, not asinine. It served as a nice
> > > > example why, even now, Leenux weenies are not correct when they insist
> > > > that C has a flat memory model and all pointers are just numbers.
>
> > > Well, you could also read the C standard to learn that.
>
> > but if you say that you get accused of language lawyering.
> > "Since IBM stopped making 360s no C program ever needs to run on such
> > a platform"
>
> We have customers who are running their business on harware from the mid
> 1980s. It may sound ludicrous, but it if solves all of their business
> needs, and runs solid 24x365, why should they upgrade?
why did I scare quote it?
<snip>
Branimir Maksimovic
Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Wed, 24 Mar 2010 10:57:37 +0100
> Branimir Maksimovic <bm...@hotmail.com> wrote:
>
> > On Wed, 24 Mar 2010 09:48:12 GMT
> > ral...@xs4all.nl (Richard Bos) wrote:
> >
> > > Peter Flass <Peter...@Yahoo.com> wrote:
> > >
> > > > Branimir Maksimovic wrote:
> > >
> > > > > Problem with standard C and C++ is that they assume flat
> > > > > memory model.
> > >
> > > Nonsense.
> > >
> > Well, technically this is not nonsense. There are no built in
> > features to portably accommodate different memory models.
> > Problem is that sizeof(char*) can be realistically
> > in some situation 4 bytes in other 8 bytes , and
> > third 2 bytes even in same function.
> > Is this allowed by standard C and C++?
>
> Having the underlying addressing mechanism of the processor
> use different sizes of address for different contexts does not
> require a C implementation to follow suit. Nothing requires C
> pointers to be addresses they could be larger structures that include
> enough information for the compiler to generate an address of the
> appropriate type when needed (or otherwise retrieve the data being
> pointed to).
Is it allowed to have different sizes of char* then in same program?
I mean what is advantage say int* over plain short/int/long/long long
as pointer into array, except easier dereferencing syntax?
>
> > If this is allowed then yes, C and C++ does not assume
> > flat memory model.
>
> It doesn't - all that C requires of pointers is that they can
> be dereferenced, converted to void pointers and back again, and that
> adding and subtracting integers works within certain well defined
> limits. Nothing requires them to be machine addresses.
Hm , how abstract C and C++ machine looks like? Is it flat
address space or segmented?
Problem is that we are talking about *pointers* and *pointer
arithmetic*. Actually integers are more useful than pointers,
for performance optimal code in both C and C++,
since they actually map to abstract machine address, unlike
pointers which can be slow, unoptimized (because of rules) and useless.
Alright int* can be base of segment eg after malloc,
but short can be used as pointer instead, since we cannot
count on different sizes of int*.
We just need that 'int*' , for scale factor in arithmetic.
I understand that char* requirement to be same size as void*,
follow historical reasons.
jmfbahciv
> Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.COM>
> writes:
>
> PLEASE! Don't cut all the attributions. I've seen you asked this more
> than once in a different newsgroup in the last few days and you've
> ignored the requests. Please listen to them.
>
>
> [content snipped]
/BAH
Ahem A Rivet's Shot
Branimir Maksimovic <bm...@hotmail.com> wrote:
I didn't say that there would be different sizes of char *, I said
that char * could be a fixed size structure which includes an address and an
indication of the size and type of that address something like this
internally:
struct pointer {
char type;
union {
uint16_t pointer16;
uint32_t pointer32;
uint64_t pointer64;
} ptr;
}
I'm not suggesting this is necessarily a good idea - just that it's
possible. The point is that C pointer types do not have to be machine
addresses.
> > > If this is allowed then yes, C and C++ does not assume
> > > flat memory model.
> >
> > It doesn't - all that C requires of pointers is that they can
> > be dereferenced, converted to void pointers and back again, and that
> > adding and subtracting integers works within certain well defined
> > limits. Nothing requires them to be machine addresses.
>
> Hm , how abstract C and C++ machine looks like? Is it flat
> address space or segmented?
What abstract machine ?
> Problem is that we are talking about *pointers* and *pointer
> arithmetic*.
Yes C defines pointers and the rules for pointer arithmetic.
> Actually integers are more useful than pointers,
Only if they're big enough - nothing prevents a C implementation
having no integer type bigger than 32 bits while pointers are (say) 48 bits.
> for performance optimal code in both C and C++,
> since they actually map to abstract machine address, unlike
Integers may not be able to map to machine addresses, that being
said it may well be more efficient to use a base pointer and an integer
offset than to manipulate pointers - but underneath it all C is going to be
manipulating pointers when you do that.
Branimir Maksimovic
What this mister is talking about then?
http://www.stanford.edu/group/sequoia/cgi-bin/node/15
>
> > Problem is that we are talking about *pointers* and *pointer
> > arithmetic*.
>
> Yes C defines pointers and the rules for pointer arithmetic.
>
> > Actually integers are more useful than pointers,
>
> Only if they're big enough - nothing prevents a C
> implementation having no integer type bigger than 32 bits while
> pointers are (say) 48 bits.
Problem is that integers are used to index into arrays.
Since arrays are identical to raw memory segment thanks to malloc,
ints must have capability to index maximum array/segment
size on architecture. So actually long long would be
enough big for maximum relative indexing of segment.
Since pointer arithmetic in C is identical with
array indexing, plain ints are actually C pointers
with relative addressing , while you p[revious explanation
shows that ordinary C pointers are actually absolute addressing
pointers with convenient syntax.
Actually implementation can identify any pointer with
int as they are identical to indexes into arrays,
but void* and char* has to be absolute addresses.
Good implementation can do that in order to
minimize memory usage for pointers other than
char* and void*. Only problem is that pointers
can be stored in memory as single type (I mean pointer to one type)
and that requires fixed size which is actually maximum array
size. Far/Near/Huge pointers came as necessity for practical
reasons on architectures where C abstract machine does not map 1-1.
>
> > for performance optimal code in both C and C++,
> > since they actually map to abstract machine address, unlike
>
> Integers may not be able to map to machine addresses, that
> being said it may well be more efficient to use a base pointer and an
> integer offset than to manipulate pointers - but underneath it all C
> is going to be manipulating pointers when you do that.
Of course. Think about malloc, what it returns and you
can cast that to *any type*. Brilliant thing.
Greets
Ahem A Rivet's Shot
Branimir Maksimovic <bm...@hotmail.com> wrote:
> On Wed, 24 Mar 2010 12:41:04 +0000
> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> > Only if they're big enough - nothing prevents a C
> > implementation having no integer type bigger than 32 bits while
> > pointers are (say) 48 bits.
>
> Problem is that integers are used to index into arrays.
Well strictly speaking you need size_t in order to guarantee being
able to index into any array.
> Since arrays are identical to raw memory segment thanks to malloc,
Nothing guarantees that.
> ints must have capability to index maximum array/segment
> size on architecture. So actually long long would be
> enough big for maximum relative indexing of segment.
Nope size_t must be big enough for that, but there's no requirement
that any int type be as big as size_t.
> Since pointer arithmetic in C is identical with
> array indexing, plain ints are actually C pointers
> with relative addressing ,
No ints are not C pointers they have *very* different arithmetic
rules.
> while you p[revious explanation
> shows that ordinary C pointers are actually absolute addressing
> pointers with convenient syntax.
> Actually implementation can identify any pointer with
> int as they are identical to indexes into arrays,
> but void* and char* has to be absolute addresses.
Pointers do not have to be any kind of address.
Branimir Maksimovic
Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Wed, 24 Mar 2010 14:45:24 +0100
> Branimir Maksimovic <bm...@hotmail.com> wrote:
>
> > On Wed, 24 Mar 2010 12:41:04 +0000
> > Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> > > Only if they're big enough - nothing prevents a C
> > > implementation having no integer type bigger than 32 bits while
> > > pointers are (say) 48 bits.
> >
> > Problem is that integers are used to index into arrays.
>
> Well strictly speaking you need size_t in order to guarantee
> being able to index into any array.
Remember size_t is typedef. Can;t be float, can;t be pointer,
it has to be one of available ints.
Actually I don;t think size_t is any good for indexing into array.
>
> > Since arrays are identical to raw memory segment thanks to malloc,
>
> Nothing guarantees that.
void* is raw memory, concerning C programmer. And malloc
returns pointer to raw memory segment that can be used
to store *any type*. array arithmetic, pointer arithmetic
are same. Since you pass size_t typedef to malloc,
actually int of largest block, can;t see inconsistency
in that.
>
> > ints must have capability to index maximum array/segment
> > size on architecture. So actually long long would be
> > enough big for maximum relative indexing of segment.
>
> Nope size_t must be big enough for that, but there's no
> requirement that any int type be as big as size_t.
And what size_t would be? Integer? float? pointer?
What you can pass to malloc?
>
> > Since pointer arithmetic in C is identical with
> > array indexing, plain ints are actually C pointers
> > with relative addressing ,
>
> No ints are not C pointers they have *very* different
> arithmetic rules.
I don;t think so. as *(a+i) is identical to a[i] or i[a]
and a automatically converts to pointer to first element.
Did you know that array subscript is associative?
Do you know why?
Only difference is that a+i increments by scale bytes, scale being
type that pointer points to.
But C memory model assumes absolute addressing.
You can't do b=a+i;c=a+b;
But you can decrement, since if you substract two absolute addresses
you can;t get out of segment bounds.
That is why it would be useful to have relative /absolute semantics.
Just because to avoid casting ints to pointers in order to
have convenient syntax for array indexing.
>
> > while you p[revious explanation
> > shows that ordinary C pointers are actually absolute addressing
> > pointers with convenient syntax.
> > Actually implementation can identify any pointer with
> > int as they are identical to indexes into arrays,
> > but void* and char* has to be absolute addresses.
>
> Pointers do not have to be any kind of address.
http://en.wikipedia.org/wiki/Pointer_%28computing%29
Greets!
Branimir Maksimovic
Branimir Maksimovic <bm...@hotmail.com> wrote:
> Did you know that array subscript is associative?
Commutative...
Walter Bushell
Dann Corbit <dco...@connx.com> wrote:
> In article <1e27d5ee-a1b1-45d9-9188-
> 63ab37...@d37g2000yqn.googlegroups.com>,
> nick_keigh...@hotmail.com says...
(snip)
> > >
>
> We have customers who are running their business on harware from the mid
> 1980s. It may sound ludicrous, but it if solves all of their business
> needs, and runs solid 24x365, why should they upgrade?
>
<snip>
None, except one should have a backup plan for when the hardware fails.
New development should be done on modern platforms.
--
A computer without Microsoft is like a chocolate cake without mustard.
Walter Bushell
Branimir Maksimovic <bm...@hotmail.com> wrote:
But ram is *so* cheap these days. Can you think of a reason for a
million pointers at once? And that would be 0.008 gigabytes. Perhaps one
needs to be that conscious for embedded work, but then one is not
working with 64 bit addressing either.
Branimir Maksimovic
Walter Bushell <pr...@panix.com> wrote:
> In article <20100324111807.6f00fd0f@maxa>,
> Branimir Maksimovic <bm...@hotmail.com> wrote:
>
> > On Wed, 24 Mar 2010 01:53:56 -0700 (PDT)
> > Nick Keighley <nick_keigh...@hotmail.com> wrote:
> >
> > > On 23 Mar, 20:56, glen herrmannsfeldt <g...@ugcs.caltech.edu>
> > > wrote:
> > > > In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
> > > > (snip)
> > > >
> > > > > That crossposting was, for once, not asinine. It served as a
> > > > > nice example why, even now, Leenux weenies are not correct
> > > > > when they insist that C has a flat memory model and all
> > > > > pointers are just numbers.
> > > >
> > > > Well, you could also read the C standard to learn that.
> > >
> > > but if you say that you get accused of language lawyering.
> > > "Since IBM stopped making 360s no C program ever needs to run on
> > > such a platform"
> > >
> > Problem is that segmented memory model is much better when working
> > with 64 bit address space. Flat memory model wastes to much
> > RAM. It would be better for standard C and C++ to provide...
>
> But ram is *so* cheap these days. Can you think of a reason for a
> million pointers at once? And that would be 0.008 gigabytes. Perhaps
> one needs to be that conscious for embedded work, but then one is not
> working with 64 bit addressing either.
>
Imagine double linked list.
You need two pointers. 16 bytes just for that instead of 8.
Take any data structure that has pointer in it.
You can easily consume more ram than available.
Say you waste 1gb of ram per process easily.
No matter how memory is cheap, if you don;t save
you will sooner or later hit the roof.
Why use 1gb of ram when 32 mb is enough?
Think about it. Problem is not in price of memory,
but nowadays memory is *wasted* so much .
Ahem A Rivet's Shot
Branimir Maksimovic <bm...@hotmail.com> wrote:
> On Wed, 24 Mar 2010 14:06:28 +0000
> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> > On Wed, 24 Mar 2010 14:45:24 +0100
> > Branimir Maksimovic <bm...@hotmail.com> wrote:
> >
> > > On Wed, 24 Mar 2010 12:41:04 +0000
> > > Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> >
> > > > Only if they're big enough - nothing prevents a C
> > > > implementation having no integer type bigger than 32 bits while
> > > > pointers are (say) 48 bits.
> > >
> > > Problem is that integers are used to index into arrays.
> >
> > Well strictly speaking you need size_t in order to guarantee
> > being able to index into any array.
>
> Remember size_t is typedef. Can;t be float, can;t be pointer,
> it has to be one of available ints.
It doesn't have to be a typedef - it usually is but it doesn't have
to be.
> Actually I don;t think size_t is any good for indexing into array.
Yes it is - it's the only type that's defined to be big enough to
index any array.
> > > Since arrays are identical to raw memory segment thanks to malloc,
> >
> > Nothing guarantees that.
>
> void* is raw memory, concerning C programmer. And malloc
void* is a pointer such that any other pointer can be cast to void
* and back again without getting damaged.
> > Nope size_t must be big enough for that, but there's no
> > requirement that any int type be as big as size_t.
>
> And what size_t would be? Integer? float? pointer?
It would be perfectly valid to build a C compiler in which
int, long, long long are all 32 bits but size_t is 64 bits and pointer is
some convoluted structure with a memory address buried in it.
> What you can pass to malloc?
You pass a size_t to malloc.
> > > Since pointer arithmetic in C is identical with
> > > array indexing, plain ints are actually C pointers
> > > with relative addressing ,
> >
> > No ints are not C pointers they have *very* different
> > arithmetic rules.
>
> I don;t think so. as *(a+i) is identical to a[i] or i[a]
Provided that one of a and i is a pointer and the other is an
integer - if both a and i are pointers then this is not a valid expression,
likewise if both are integers this is not valid. Therefore pointers are not
the same as ints.
> and a automatically converts to pointer to first element.
If a is an array - yes.
> Did you know that array subscript is associative?
> Do you know why?
Commutative - as you corrected yourself. Yes I do, it is
commutative because it is defined as being so.
> Only difference is that a+i increments by scale bytes, scale being
> type that pointer points to.
That is *one* very important difference, another is that adding a
pointer to an integer is only valid within certain limits having to do with
the original allocation or declaration of the object being pointed to
(basically between the first entry in an array and one past the end of an
array) - for example:
int *p;
int a[50];
p = &(a[0]);
p = p - 1;
p = p + 1;
It is no longer guaranteed that p points to a[0], yet another
important difference between pointer arithmetic and integer arithmetic.
> But C memory model assumes absolute addressing.
> You can't do b=a+i;c=a+b;
No you cannot add pointers.
> But you can decrement, since if you substract two absolute addresses
> you can;t get out of segment bounds.
C doesn't talk about segments.
> >
> > Pointers do not have to be any kind of address.
>
> http://en.wikipedia.org/wiki/Pointer_%28computing%29
Is correct this far:
"In computer science, a pointer is a programming language data type whose
value refers directly to (or "points to") another value"
After that it strays into implementation detail which may or may
not be correct.
Mark Crispin
>>> That crossposting was, for once, not asinine. It served as a nice
>>> example why, even now, Leenux weenies are not correct when they insist
>>> that C has a flat memory model and all pointers are just numbers.
>> Well, you could also read the C standard to learn that.
> but if you say that you get accused of language lawyering.
> "Since IBM stopped making 360s no C program ever needs to run on such
> a platform"
And, as you probably know, people who say such things are mindless
cretins who, "in a civilized society, would be sent to a state laboratory
for experimental purposes." Such people are boxing themselves into a
corner; they just don't realize it yet.
I will laugh myself silly when the latest & greatest CPU uses something
other than numbers for pointers, and we can see a reprise of "all the
world is not VAX."
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Joe Pfeiffer
Besides, whatever relevance his arguments have, they apply to virtual
space, not physical RAM.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
Walter Bushell
Branimir Maksimovic <bm...@hotmail.com> wrote:
Go virtual man. One does have to structure the data for the problem, but
if you are using that much space for pointers you are using more for the
data. Also you if 32 bits are enough you can pack two 32 bit addressen
in each 64 bit word and expand as necessary.
This from the top of my head. A little research could improve this
substantially I am quite sure.
A little more though, if the structure is of length N then we need only
store the base address and (relative pointer)/N which will be integer,
so we might be able to store data in the pointer word along with the two
pointers, or make create a balanced trinary or qunintary linked list or
even higher order.
Cheers.
Branimir Maksimovic
Problem is that virtual address space is mapped to physical RAM.
You have to write OS in some language. Assembler?
I think that writing device drivers an Os is lot easier
in C than in Java. what do you think why?
Branimir Maksimovic
Voice of reason!
Cheers!
Seebs
> Yes, I've gotten a few corrections on this;-) I guess what I was
> thinking of is a statement I've heard several times that lots of
> existing C code *assumes* sizeof(ptr) = sizeof(int), and breaks when
> this isn't true.
I wouldn't say "lots". Some, certainly. Some checks whether int or
long is the same size, and gives up if neither is. The vast majority
of C code, I suspect, doesn't care.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
> Is it allowed to have different sizes of char* then in same program?
No, but that doesn't mean the hardware can't use different types of
pointers. The compiler can do a great deal of magic under the hood.
> Hm , how abstract C and C++ machine looks like? Is it flat
> address space or segmented?
It is hypersegmented, in that every single object is its own address
space, with no guarantees about relations between them except that you
can compare them for equality.
> Problem is that we are talking about *pointers* and *pointer
> arithmetic*. Actually integers are more useful than pointers,
> for performance optimal code in both C and C++,
> since they actually map to abstract machine address, unlike
> pointers which can be slow, unoptimized (because of rules) and useless.
Where do you get this stuff?
Pointers nearly always map very well to physical hardware capabilities.
On systems which really need multiple types of pointers, the usual
solution is to extend the language to allow declarations of other pointer
types.
Joe Pfeiffer
No, a very small fraction of the virtual address space is mapped to
physical RAM.
Keith Thompson
> On Wed, 24 Mar 2010 14:06:28 +0000
> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
>> On Wed, 24 Mar 2010 14:45:24 +0100
>> Branimir Maksimovic <bm...@hotmail.com> wrote:
>>
>> > On Wed, 24 Mar 2010 12:41:04 +0000
>> > Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>
>> > > Only if they're big enough - nothing prevents a C
>> > > implementation having no integer type bigger than 32 bits while
>> > > pointers are (say) 48 bits.
>> >
>> > Problem is that integers are used to index into arrays.
>>
>> Well strictly speaking you need size_t in order to guarantee
>> being able to index into any array.
>
> Remember size_t is typedef. Can;t be float, can;t be pointer,
> it has to be one of available ints.
It has to be an unsigned integer type.
> Actually I don;t think size_t is any good for indexing into array.
Sure it is.
For a declared object of any type, ``sizeof object'' yields the size
in bytes of the object, with a result of type size_t. For an object
allocated by a call to malloc() the size argument to malloc is of
type size_t, so it can't create an object bigger than SIZE_MAX bytes.
(SIZE_MAX, as the name implies, is the largest possible value of
type size_t.)
Which means that, with the possible exception of some bizarre cases,
no object can be bigger than SIZE_MAX bytes. Since the elements
of an array must be at least 1 byte in size, it follows that the
maximum index for an array object cannot exceed SIZE_MAX.
size_t is the only integer type (other that uintmax_t) that has this
guarantee.
(The bizarre cases are things like calloc() with two arguments whose
product exceeds SIZE_MAX and large (possibly variable-length) arrays.
On most implementations, such objects can't created; calloc()
will return NULL and huge array object declarations will exceed
implementation limits. We've had some discussions here recently
about whether an implementation is, or should be, permitted to
support objects bigger than SIZE_MAX bytes.)
[...]
>> Nope size_t must be big enough for that, but there's no
>> requirement that any int type be as big as size_t.
>
> And what size_t would be? Integer? float? pointer?
> What you can pass to malloc?
You're right, size_t is a typedef for some existing unsigned integer
type. (Note: "integer type" not "int type"; "int" is one specific
integer type.) But there's no guarantee that any int type is as
big as a pointer. A pointer can point to any object in memory;
size_t only needs to be big enough to span a single object.
>>
>> > Since pointer arithmetic in C is identical with
>> > array indexing, plain ints are actually C pointers
>> > with relative addressing ,
>>
>> No ints are not C pointers they have *very* different
>> arithmetic rules.
>
> I don;t think so. as *(a+i) is identical to a[i] or i[a]
> and a automatically converts to pointer to first element.
> Did you know that array subscript is associative?
Commutative, not associative, as you acknowledged in a followup.
> Do you know why?
Because both pointer+integer and integer+pointer arithmetic are
supported (as well as pointer-integer and pointer-pointer). The
language *could* have required the pointer to appear on the LHS of the
"+", banning integer+pointer. The (unnecessary IMHO) symmetry goes
back to the early days of C, when the distinction between integers and
pointers wasn't as strong as it is now.
> Only difference is that a+i increments by scale bytes, scale being
> type that pointer points to.
Pointer addition is a different operation than integer addition.
> But C memory model assumes absolute addressing.
Not really, though I suppose it depends on what exactly you mean by
"absolute addressing".
> You can't do b=a+i;c=a+b;
> But you can decrement, since if you substract two absolute addresses
> you can;t get out of segment bounds.
> That is why it would be useful to have relative /absolute semantics.
> Just because to avoid casting ints to pointers in order to
> have convenient syntax for array indexing.
I'm not sure what you're saying here, but in some of your other
articles in this thread I think you're conflating two different
things.
C requires all pointers of a given type to have the same size and
representation. char* and int* might be different, but any two
pointers to char are stored the same way. On some systems, it might
be convenient to be able to have different "flavors" of pointers to
the same type, where the different flavors might, for example, be able to
point to different regions of memory. On a 64-bit system, you might
want to have 64-bit pointers that can point anywhere, and 32-bit
pointers that can only point into the bottom 4GB of memory.
C doesn't support this. Pointers are distinguished only by the type
they point to. If I obtain a pointer to an int object, I can copy
that pointer value into any other pointer-to-int object and
dereference the copy without knowing or caring how the original
pointer was generated.
This kind of thing can be supported by an implementation-specific
extension, such as the "near" and "far" pointer types in some x86
compilers. But any code that uses such an extension is non-portable.
On the other hand, C does *not* assume a monolithic addressing space.
A C pointer might internally consist of a segment identifier plus
an offset into that segment. Pointer arithmetic might affect only
the offset.
>> > while you p[revious explanation
>> > shows that ordinary C pointers are actually absolute addressing
>> > pointers with convenient syntax.
>> > Actually implementation can identify any pointer with
>> > int as they are identical to indexes into arrays,
>> > but void* and char* has to be absolute addresses.
>>
>> Pointers do not have to be any kind of address.
That depends on what you mean by "address". The C standard uses the
word to mean, essentially, a pointer value. But an address / pointer
value needn't be a machine address, either physical or virtual (though
on most implementations it is).
> http://en.wikipedia.org/wiki/Pointer_%28computing%29
Wikipedia doesn't define what "pointer" means in C; the C standard
does.
Recommended reading: sections 4 (Pointers) and 6 (Arrays and Pointers)
of the comp.lang.c FAQ, <http://www.c-faq.com/>.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson
> On Wed, 24 Mar 2010 15:57:46 +0100
> Branimir Maksimovic <bm...@hotmail.com> wrote:
>> Remember size_t is typedef. Can;t be float, can;t be pointer,
>> it has to be one of available ints.
>
> It doesn't have to be a typedef - it usually is but it doesn't have
> to be.
How could size_t not be a typedef? It's not a keyword or a macro.
You can legally declare an object called "size_t" in a local scope
(not that it's a good idea). And you can invoke the sizeof operator
without the name size_t being visible.
sizeof yields a result of some predefined unsigned type. size_t is a
typedef for that type.
The standard doesn't say so explicitly; it says, in C99 7.17p2, that
size_t "is the unsigned integer type of the result of the sizeof
operator. If you can think of a way to satisfy that requirement
without making size_t a typedef (or any reason to do so), I'd
be interested.
[...]
> It would be perfectly valid to build a C compiler in which
> int, long, long long are all 32 bits but size_t is 64 bits and pointer is
> some convoluted structure with a memory address buried in it.
Yes, but size_t needs to be a typedef for some unsigned integer type.
If it's bigger than unsigned long long, then it has to be an extended
integer type as described in C99 6.2.5.
[...]
Jonathan de Boyne Pollard
>
> But [virtual address space] is *so* cheap these days. Can you think of
> gigabytes.
>
Before the "But, but, but! A program would never want them all at once!"
sputtering comes along from anyone, I point out that this happens
regularly, even for people without Big Problems To Solve. For example:
One of the newsgroups for this very post is alt.folklore.computers. My
Usenet node carries all of the (correctly formatted) messages in that
newsgroup (that I've been able to find) for the past half decade.
That's currently a little over 127,500 messages. My NUA's thread-view
pane of course needs to be capable of displaying the NOV data for all of
those messages, sorted into the viewing order that I have selected. So
it has at least that many objects in memory in some form of data
structure when it is presenting that newsgroup.
Branimir Maksimovic
Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
Hm , why then people have problem with Linux OOM killer, especially
regarding Java GC. It has to pick targets more nicely not
in random manner;) (and those machines have 4gb of ram)
Problem is that I cn see no improvement over older hardware...
and much less RAM...
Branimir Maksimovic
Array indexing in C is relative indexing. Relative pointers are ints,
and absolute pointers are C pointers.
So if you have possibility to declare relative , "near" pointer than
you could do absolute + relative pointer addition .
You can;t add two pointers into C array as they assume absolute
addressing. By that I mean either flat or segmented model.
far/near pointers are necessity, both on flat and segmented model,
since I don;t know CPU that supports only absolute addressing mode.
That means that we have to use int's as pointers into arrays
obtained by malloc and achieve same effect. Actually it's just
a matter of convenient syntax, *(absolutep+relativep)
People just cast ints to pointers for same reason ,but
it is not portable since you have to carry base with it.
And you don;t save memory since it is better to use short
in case you need 64k relative addressing, as relative pointer than C
pointer (because of size). On implementations where short can
be bigger does not matter since it will work anyway.
So actually *++p iteration through array assumes absolute
addressing ,while *(p + relativep) assumes relative addressing.
If I can be more clear.
>
> > You can't do b=a+i;c=a+b;
> > But you can decrement, since if you substract two absolute addresses
> > you can;t get out of segment bounds.
> > That is why it would be useful to have relative /absolute semantics.
> > Just because to avoid casting ints to pointers in order to
> > have convenient syntax for array indexing.
>
> I'm not sure what you're saying here, but in some of your other
> articles in this thread I think you're conflating two different
> things.
I think, malloc guarantees largest segment
and ints are actually relative , short pointers into segment,
while you can still use absolute pointers as bases.
It's just a matter of realizing this.
So for example if you have architecture base+ 12 bit offset like 360
you can't malloc more than 4kb because of absolute+relativep.
Since relativep in this case is 12 bits your size_t is limited to
4096 bytes.
Can someone explain how those things are worked out there?
I worked with 370's but fortran,pascal and cobol in high school and
university. Also Unisys A systems, but cobol. There weren't C compilers.
I wrote T27 emulator and some banking transactions for DOS with it
in C , to support Serbia's electronic payment system ;)
That was back in 92-93.
Greets.
Joe Pfeiffer
I haven't had any problem with the OOM killer since the last time a
sysadmin forgot to turn swap on.
Keith Thompson
> On Wed, 24 Mar 2010 11:15:05 -0700
> Keith Thompson <ks...@mib.org> wrote:
>> Branimir Maksimovic <bm...@hotmail.com> writes:
>> > But C memory model assumes absolute addressing.
>>
>> Not really, though I suppose it depends on what exactly you mean by
>> "absolute addressing".
>
> Array indexing in C is relative indexing. Relative pointers are ints,
> and absolute pointers are C pointers.
If you're talking about C, it's *very* important to remember that
pointers are not integers, and integers are not pointers.
It's possible to convert between pointer and integer types, but the
result of such a conversion (with the lone exception of converting a
constant 0 to a pointer type) is not portable.
[...]
> I think, malloc guarantees largest segment
> and ints are actually relative , short pointers into segment,
> while you can still use absolute pointers as bases.
> It's just a matter of realizing this.
Sorry, I don't know what "malloc guarantees largest segment"
is supposed to mean. The C standard, which is what defines the
behavior of malloc, doesn't talk about segments. C is carefully
designed to work on systems with either segmented or monolithic
addressing spaces.
> So for example if you have architecture base+ 12 bit offset like 360
> you can't malloc more than 4kb because of absolute+relativep.
> Since relativep in this case is 12 bits your size_t is limited to
> 4096 bytes.
A conforming hosted C implementation must support objects of at least
65535 bytes (in C99; C90 required 32767 bytes). So size_t must be at
least 16 bits. It's up to the compiler to generate whatever code is
needed to support this.
[...]
glen herrmannsfeldt
(snip)
> But ram is *so* cheap these days. Can you think of a reason for a
> million pointers at once? And that would be 0.008 gigabytes. Perhaps one
> needs to be that conscious for embedded work, but then one is not
> working with 64 bit addressing either.
RAM is cheap, but bandwidth isn't. Bigger pointers means more
data transfer to/from memory and slower running programs.
-- glen
Peter Flass
> On Wed, 24 Mar 2010, Nick Keighley posted:
>>>> That crossposting was, for once, not asinine. It served as a nice
>>>> example why, even now, Leenux weenies are not correct when they insist
>>>> that C has a flat memory model and all pointers are just numbers.
>>> Well, you could also read the C standard to learn that.
>> but if you say that you get accused of language lawyering.
>> "Since IBM stopped making 360s no C program ever needs to run on such
>> a platform"
>
> And, as you probably know, people who say such things are mindless
> cretins who, "in a civilized society, would be sent to a state
> laboratory for experimental purposes." Such people are boxing
> themselves into a corner; they just don't realize it yet.
>
> I will laugh myself silly when the latest & greatest CPU uses something
> other than numbers for pointers, and we can see a reprise of "all the
> world is not VAX."
>
I suppose you could have associative pointers.
Branimir Maksimovic
Speaking to that I found that traversing linked list where
nodes are sorted by address is twice as fast than where
nodes are randomly sorted. Also found that quicksort that
is based on sequential memory access is much faster
than any sort based on random access. Same sort is
about 7 times faster when nodes are allocated behind
one another sorted by address and about 3-4 times
faster when there is larger gap between nodes.
That's why linked list sorts that change access order
are really bad thing, since after them traversing said list
is at least twice slower.
Eg random access radix sort of 5million nodes (512kb L@ cache dual
xeon ) is slower than first quick sort list by address, then
quick sort list by value by *sequential* access.
Of course that is if nodes are smaller ;)
That is for intel. Didn;t try amd.
Also tested initialization of 256 meg of ram
on modern quad xeon (external memory controller),and
home model dual athlon , same speed can you beleive?!
4 threads xeon , two threads athlon.
All in all nowadays it is more important to
pay attention on memory access patterns than anything else.
Greets
Peter Flass
>
> I think, malloc guarantees largest segment
> and ints are actually relative , short pointers into segment,
> while you can still use absolute pointers as bases.
> It's just a matter of realizing this.
> So for example if you have architecture base+ 12 bit offset like 360
> you can't malloc more than 4kb because of absolute+relativep.
> Since relativep in this case is 12 bits your size_t is limited to
> 4096 bytes.
This is a false assumption. The displacement in the instruction is 12
bits, but you have an index register that's 2**31 bits, (2GB)
Branimir Maksimovic
Thanks for explanation.
Greets!
Branimir Maksimovic
Keith Thompson <ks...@mib.org> wrote:
>
> If you're talking about C, it's *very* important to remember that
> pointers are not integers, and integers are not pointers.
Well digital computer is all numbers. array of 1' and 0's.
Remember, C was meant for assembler programmers.
I first learned basic than assembler on spectrum 48kb.
Then somehow C compiler was available for spectrum,
so when I saw ++ operator, immediately recognized
C as another assembler. Especially was fascinated that
you could crash computer with it same as in assembler.
Technically pointers are integers, but understanding
their meaning and usage on particular implementation
and exploiting it is not portable, of course.
But you *can* do it anyway if necessary and portability
is not of concern.
>
> It's possible to convert between pointer and integer types, but the
> result of such a conversion (with the lone exception of converting a
> constant 0 to a pointer type) is not portable.
> [...]
>
> > I think, malloc guarantees largest segment
> > and ints are actually relative , short pointers into segment,
> > while you can still use absolute pointers as bases.
> > It's just a matter of realizing this.
>
> Sorry, I don't know what "malloc guarantees largest segment"
> is supposed to mean. The C standard, which is what defines the
> behavior of malloc, doesn't talk about segments. C is carefully
> designed to work on systems with either segmented or monolithic
> addressing spaces.
Yes but, when you malloc you get chunk of raw memory
that can be indexed by integers of any type.
This maps 1-1 on assembler thinkology ;)
What about memory bank switching model?
Eg on amstrad cpc6128 there was 128kb of ram,
but 8 memory banks of 16kb each.
CPU could address maximum of 64kb.
64kb linear address space for apps and shadow OS
in another 64 kb, CP/M ?
There is *real* C compiler for it.
My second home computer btw ;)
>
> > So for example if you have architecture base+ 12 bit offset like 360
> > you can't malloc more than 4kb because of absolute+relativep.
> > Since relativep in this case is 12 bits your size_t is limited to
> > 4096 bytes.
>
> A conforming hosted C implementation must support objects of at least
> 65535 bytes (in C99; C90 required 32767 bytes). So size_t must be at
> least 16 bits. It's up to the compiler to generate whatever code is
> needed to support this.
Thanks for explanation.
Greets!
Seebs
> Keith Thompson <ks...@mib.org> wrote:
>> If you're talking about C, it's *very* important to remember that
>> pointers are not integers, and integers are not pointers.
> Well digital computer is all numbers. array of 1' and 0's.
Yes, but a pointer need not be a single number. It could be a pair
of numbers, one of which indicates a segment, and another of which
indicates an offset, and operations on that pointer could operate
entirely on the offset, for instance.
> Remember, C was meant for assembler programmers.
Yes.
> Technically pointers are integers,
No, they aren't.
They often happen to be isomorphic to integers on machines with a flat
addressing space, but they aren't always elsewhere. On a segmented
architecture, it's quite possible to have two different bit patterns
of "pointer" point to the same location.
> Yes but, when you malloc you get chunk of raw memory
> that can be indexed by integers of any type.
What do you mean "indexed by integers of any type"?
> This maps 1-1 on assembler thinkology ;)
Well, it might. It usually maps pretty well onto any given assembler, but
sometimes the mapping is very different between different C implementations.
Seebs
> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>> It doesn't have to be a typedef - it usually is but it doesn't have
>> to be.
> How could size_t not be a typedef? It's not a keyword or a macro.
It could, however, be treated magically by the compiler.
Which means that, while it appears to necessarily have the same semantics
as a typedef, there's no requirement that it actually *is* one.
Phil Carmody
Ahem A Rivet's Shot <ste...@eircom.net> writes:
> On Wed, 24 Mar 2010 14:45:24 +0100
> Branimir Maksimovic <bm...@hotmail.com> wrote:
>
>> On Wed, 24 Mar 2010 12:41:04 +0000
>> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
>> > Only if they're big enough - nothing prevents a C
>> > implementation having no integer type bigger than 32 bits while
>> > pointers are (say) 48 bits.
>>
>> Problem is that integers are used to index into arrays.
>
> Well strictly speaking you need size_t in order to guarantee being
> able to index into any array.
>
>> Since arrays are identical to raw memory segment thanks to malloc,
>
> Nothing guarantees that.
Nothing even _defines_ what that means. 'Raw' and 'segment' have
simply been pulled out of an over-active imagination.
>> ints must have capability to index maximum array/segment
>> size on architecture. So actually long long would be
>> enough big for maximum relative indexing of segment.
>
> Nope size_t must be big enough for that, but there's no requirement
> that any int type be as big as size_t.
How else can there be a corresponding signed type? (n869 7.19.6.1)
>> Since pointer arithmetic in C is identical with
>> array indexing, plain ints are actually C pointers
>> with relative addressing ,
>
> No ints are not C pointers they have *very* different arithmetic
> rules.
>
>> while you p[revious explanation
>> shows that ordinary C pointers are actually absolute addressing
>> pointers with convenient syntax.
>> Actually implementation can identify any pointer with
>> int as they are identical to indexes into arrays,
>> but void* and char* has to be absolute addresses.
>
> Pointers do not have to be any kind of address.
The pointer which is a result of the & operator has to be a very
addressy kind of address.
Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
Phil Carmody
> On 2010-03-24, Keith Thompson <ks...@mib.org> wrote:
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>> It doesn't have to be a typedef - it usually is but it doesn't have
>>> to be.
>
>> How could size_t not be a typedef? It's not a keyword or a macro.
>
> It could, however, be treated magically by the compiler.
>
> Which means that, while it appears to necessarily have the same semantics
> as a typedef, there's no requirement that it actually *is* one.
It has to be a 'type' which has a 'corresponding signed type', and it
has to be both 'declared' and 'defined'. Not many things can be all
of those.
Ben Bacarisse
> On Wed, 24 Mar 2010 14:04:54 -0700
> Keith Thompson <ks...@mib.org> wrote:
>>
>> If you're talking about C, it's *very* important to remember that
>> pointers are not integers, and integers are not pointers.
>
> Well digital computer is all numbers. array of 1' and 0's.
Would you have made the same response if Keith had said "remember that
floating point numbers are not integers, and integers are not floating
point numbers"?
Sure, you can sometimes treat a region of storage as either an int or
a float, but doing so ignores what is important about the two types.
> Remember, C was meant for assembler programmers.
> I first learned basic than assembler on spectrum 48kb.
> Then somehow C compiler was available for spectrum,
> so when I saw ++ operator, immediately recognized
> C as another assembler. Especially was fascinated that
> you could crash computer with it same as in assembler.
> Technically pointers are integers, but understanding
> their meaning and usage on particular implementation
> and exploiting it is not portable, of course.
Technically, both pointers and integers are stored as collections of
bits, but it's a long way from that to say that pointers are
integers. The most useful view of a data type is what you can do with
it. The operations defined on integer types and pointer types (in C)
are very different.
<snip>
--
Ben.
Phil Carmody
> In article <1e27d5ee-a1b1-45d9-9188-
> 63ab37...@d37g2000yqn.googlegroups.com>,
> nick_keigh...@hotmail.com says...
>>
>> On 23 Mar, 20:56, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> > In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
>> > (snip)
>> >
>> > > example why, even now, Leenux weenies are not correct when they insist
>> > > that C has a flat memory model and all pointers are just numbers.
>> >
>> > Well, you could also read the C standard to learn that.
>>
>> but if you say that you get accused of language lawyering.
>> "Since IBM stopped making 360s no C program ever needs to run on such
>> a platform"
>
> 1980s. It may sound ludicrous, but it if solves all of their business
> needs, and runs solid 24x365, why should they upgrade?
Because they could run an equivalently computationally powerful
solution with various levels of redundancy and fail-over protection,
with a power budget sensibly measured in mere Watts?
Phil, who has customers who prefer systems consuming <20 mW.
Phil Carmody
> Branimir Maksimovic <bm...@hotmail.com> wrote:
>> Problem is that segmented memory model is much better when working
>> with 64 bit address space. Flat memory model wastes to much
>> RAM. It would be better for standard C and C++ to provide appropriate
>> pointer semantics in order to keep memory usage optimal.
>> What is use of 64 bit flat pointers when you can actually
>> just load segment base and work with offsets?
> But ram is *so* cheap these days. Can you think of a reason for a
> million pointers at once? And that would be 0.008 gigabytes. Perhaps one
> needs to be that conscious for embedded work, but then one is not
> working with 64 bit addressing either.
64-bit Alpha, POWER, and MIPS architectures have been used in
embedded applications, complete with their native 64-bit
addressing.
Phil
Phil Carmody
> Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
>> No, a very small fraction of the virtual address space is mapped to
>> physical RAM.
>
> Hm , why then people have problem with Linux OOM killer,
Because they are using vastly more virtual address space
than there is physical RAM. Which kinda follows from what
Joe already said.
Ben Bacarisse
> Seebs <usenet...@seebs.net> writes:
>> On 2010-03-24, Keith Thompson <ks...@mib.org> wrote:
>>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>>> It doesn't have to be a typedef - it usually is but it doesn't have
>>>> to be.
>>
>>> How could size_t not be a typedef? It's not a keyword or a macro.
>>
>> It could, however, be treated magically by the compiler.
>>
>> Which means that, while it appears to necessarily have the same semantics
>> as a typedef, there's no requirement that it actually *is* one.
>
> It has to be a 'type' which has a 'corresponding signed type',
I can't find this requirement. Where does it come from?
(The reverse: that for every signed integer type there is a
corresponding unsigned integer type is certainly true).
> and it
> has to be both 'declared' and 'defined'. Not many things can be all
> of those.
All sorts of magic might be involved:
__declare__and__define('size_t', '48 bits');
or maybe the type just pops into existence when one of the appropriate
header files is seen, but in most cases there is no reason not to use
a typedef.
--
Ben.
Keith Thompson
> On Wed, 24 Mar 2010 14:04:54 -0700
> Keith Thompson <ks...@mib.org> wrote:
>>
>> If you're talking about C, it's *very* important to remember that
>> pointers are not integers, and integers are not pointers.
>
> Well digital computer is all numbers. array of 1' and 0's.
But that's not all they are. Certain combinations of 1s and 0s have
*meanings*. And we use languages at a higher level than raw binary,
whether assembly language, C, Lisp, or whatever, precisely so we can
manipulate those meaning rather than the 1s and 0s.
> Remember, C was meant for assembler programmers.
Not really. C is meant for C programmers. Assembler is meant for
assembler programmers.
Yes, C can be an alternative to assembly language, but the whole point
is that it's an alternative. It's not the same thing.
> I first learned basic than assembler on spectrum 48kb.
> Then somehow C compiler was available for spectrum,
> so when I saw ++ operator, immediately recognized
> C as another assembler.
C's ++ and -- operators were probably inspired by autoincrement and
autodecrement addressing modes on some early PDP-whatever. But
they're much more general.
> Especially was fascinated that
> you could crash computer with it same as in assembler.
> Technically pointers are integers, but understanding
> their meaning and usage on particular implementation
> and exploiting it is not portable, of course.
> But you *can* do it anyway if necessary and portability
> is not of concern.
Yes, if portability is not a concern, you can do all sorts of ugly
things. You can treat pointers as integers in C, but you have to
fight the language to do it, since C pointers *are not integers*.
Feed the following to a C compiler:
char *p = 0xdeadbeef;
and it will at least complain, and very likely reject your program.
[...]
>> > I think, malloc guarantees largest segment
>> > and ints are actually relative , short pointers into segment,
>> > while you can still use absolute pointers as bases.
>> > It's just a matter of realizing this.
>>
>> Sorry, I don't know what "malloc guarantees largest segment"
>> is supposed to mean. The C standard, which is what defines the
>> behavior of malloc, doesn't talk about segments. C is carefully
>> designed to work on systems with either segmented or monolithic
>> addressing spaces.
>
> Yes but, when you malloc you get chunk of raw memory
> that can be indexed by integers of any type.
> This maps 1-1 on assembler thinkology ;)
Try thinking about C in its own terms. You might find it more
rewarding than forcing it into an assembly-level model.
[snip]
Keith Thompson
> On 2010-03-24, Keith Thompson <ks...@mib.org> wrote:
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>> It doesn't have to be a typedef - it usually is but it doesn't have
>>> to be.
>
>> How could size_t not be a typedef? It's not a keyword or a macro.
>
> It could, however, be treated magically by the compiler.
>
> Which means that, while it appears to necessarily have the same semantics
> as a typedef, there's no requirement that it actually *is* one.
How is something with the same semantics as a typedef not a typedef?
Yeah, ok, there might not be a line of C source code containing the
tokens "typedef" and "size_t" in whatever entity "#include <stddef.h>"
refers to. Similarly, printf might be some magic thing that acts like
a variadic function, but really isn't one.
To put it another way, a typedef declaration, perhaps
typedef unsigned long size_t;
that appears when you write
#include <stddef.h>
perfectly satisifies the standard's requirements for size_t. And no
other C construct does so.
It quacks like a duck.
Seebs
> Seebs <usenet...@seebs.net> writes:
>> Which means that, while it appears to necessarily have the same semantics
>> as a typedef, there's no requirement that it actually *is* one.
> How is something with the same semantics as a typedef not a typedef?
The same way something with the same semantics as 'signed char' (or 'unsigned
char') might be something else, such as a plain 'char'? :)
> It quacks like a duck.
True, and I guess I'll concede the point.
Jonathan de Boyne Pollard
>
> Another practical difference is that in the tiny model, accessible
> memory is given up for program efficiency. In the flat model the
> registers are large enough that this trade-off is not require.
>
Bogus argument. You're assuming a difference as a premise, and then
using that premise to prove that there's a difference. This is really
very simple: There is no real difference (apart from those pre-defined
macros). Your assumed premise is bogus. Memory models don't imply
processor execution modes, nor do they imply either target platforms or
bitness. (The large memory model, for comparison, is still the large
memory model whether the bitness of the pointers is 16:16 because one is
using wcc/wpp or 16:32 because one is using wcc386/wpp386.) They are
largely disjoint from those concepts. Whether flat or tiny, the
compiler does not emit code any differently, the programmer sees the
same near pointers, and the instructions generated are all near form.
(As just pointed out to M. Person, the actual C and C++ compilers
themselves in OpenWatcom C/C++ don't even know about these memory models
as distinct models in their own rights, throwing the information about
-mf away once some pre-defined macros have been set up, and not even
recognizing -mt at all.) Flat model and tiny model are in reality but
two names for the same thing.
bbreynolds
And the purpose of such a capability? Why, of course---to be
able to determine how many of /BAH's postings to a.f.c. begin
with the exclamation "Sigh!".
Bruce B. Reynolds, Trailing Edge Technologies, Warminster PA
Jonathan de Boyne Pollard
>
>> I'm sure there have been a number of processors with segmented
>> architectures, and that a number of them will have had C compilers,
>> so there are almost certainly more.
>>
> The IBM 360 mainframe line (designed in the early 1960-s) is probably
> the earliest segmented architecture, but it never had the limitations
> of the Intel architecture. Register size was 32 b, regardless of the
> width of the memory bus (which was available in all power-of-two sizes
> from 8-b to 128-b width, depending on your budget), and registers
> could address all memory. All pointers were flat model pointers.
>
We were discussing the 68xx and 680x0 processors earlier in this thread,
and the reasons to like them. Having general-purpose registers that
were as big as full memory addresses (at the instruction set level) is
definitely one such reason. It raises an interesting question, though.
How many CPUs in the modern personal computer market, or indeed in the
modern computer market overall, is that still true of? Not having
general-purpose registers as wide as memory addresses has long been the
case for the majority (given the popularity of the x86 architecture).
But has it now become universally the case?
Jonathan de Boyne Pollard
>
> I will laugh myself silly when the latest & greatest CPU uses
> something other than numbers for pointers, and we can see a reprise of
> "all the world is not VAX" .
>
Spencer's Ten Commandments for C Programmers, for the benefits of the
lurkers.)
The thing is, you can laugh yourself silly now. Henry Spencer gave "All
the world's a 386." as a heresy equivalent to "All the world's a VAX.".
The people who argue that the whole planet is flat, because their
platform of choice gives them a tiny/flat memory model, are forgetting
that the very processor architecture that they are using is one of the
reasons that the C and C++ languages are careful not to provide such
sweeping conversion (and other) semantics for pointers in the first place.
They forget the many cries of the programmers using the very same
processor architecture that they are now using to argue the flatness of
the globe. "My code is far but my data are near and I cannot therefore
cast from pointer to function to pointer to data without loss of
information!" "DS isn't equal to CS and I cannot therefore cast from
near pointer to function to near pointer to data and have the pointers
point to the same thing!" "16-bit OS/2/Windows has loaded my constants
into a read-only segment and so my program will crash if I attempt to
write to a string constant!" "My array of data has been allocated a
single segment of its own by the heap manager, so running off the end of
the array will immediately exceed the segment limit and crash the
program!" "My program is huge model, therefore size_t is wider than
unsigned int!" "16-bit OS/2/Windows invalidates freed LDT selectors, so
even if I don't dereference it, merely just using the value of a pointer
to deallocated memory in an expression, which will often attempt to load
a now invalid LDT selector into a processor segment register, will cause
my program to crash!"
glen herrmannsfeldt
> The thing is, you can laugh yourself silly now. Henry Spencer gave "All
> the world's a 386." as a heresy equivalent to "All the world's a VAX.".
> The people who argue that the whole planet is flat, because their
> platform of choice gives them a tiny/flat memory model, are forgetting
> that the very processor architecture that they are using is one of the
> reasons that the C and C++ languages are careful not to provide such
> sweeping conversion (and other) semantics for pointers in the first place.
Maybe one of the reasons, but machines like the PDP-10 are another.
There is consideration for C pointers being different for
different types, especially on word addressed machines.
Consider a PDP-10 C system with 9 bit char, four per word.
Now, cast between (int*) and (char*) and see what happens?
I presume an (int*) is the PDP-10 address of the word, but
what is in a (char*)?
Also possible is an 18 bit (char) using H instructions.
-- glen
Keith Thompson
> On 2010-03-25, Keith Thompson <ks...@mib.org> wrote:
>> Seebs <usenet...@seebs.net> writes:
>>> Which means that, while it appears to necessarily have the same semantics
>>> as a typedef, there's no requirement that it actually *is* one.
>
>> How is something with the same semantics as a typedef not a typedef?
>
> The same way something with the same semantics as 'signed char' (or 'unsigned
> char') might be something else, such as a plain 'char'? :)
Ah, but signed char doesn't have the same semantics as plain char.
For one thing, I can assign a signed char* value to a signed char*
object, but I can't assign a signed char* value to a char* value.
(Assuming plain char is signed; s/signed/unsigned/g otherwise.)
>> It quacks like a duck.
>
> True, and I guess I'll concede the point.
Quack.
Phil Carmody
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>> Seebs <usenet...@seebs.net> writes:
>>> On 2010-03-24, Keith Thompson <ks...@mib.org> wrote:
>>>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>>>> It doesn't have to be a typedef - it usually is but it doesn't have
>>>>> to be.
>>>
>>>> How could size_t not be a typedef? It's not a keyword or a macro.
>>>
>>> It could, however, be treated magically by the compiler.
>>>
>>> Which means that, while it appears to necessarily have the same semantics
>>> as a typedef, there's no requirement that it actually *is* one.
>>
>> It has to be a 'type' which has a 'corresponding signed type',
>
> I can't find this requirement. Where does it come from?
Ref posted elsethread, but it was the description of printf's %z.
> (The reverse: that for every signed integer type there is a
> corresponding unsigned integer type is certainly true).
>
>> and it
>> has to be both 'declared' and 'defined'. Not many things can be all
>> of those.
>
> All sorts of magic might be involved:
>
> __declare__and__define('size_t', '48 bits');
There's no C declaration there, and no C definition there. The
terms are clearly defined by the C standard, and even have
grammatical rules specifying them, and the above is neither.
> or maybe the type just pops into existence when one of the appropriate
> header files is seen, but in most cases there is no reason not to use
> a typedef.
If it were to just pop into existence, then there would be
no declaration/definition of it. The standard insists there
is a declaration/definition.
Nick Keighley
> On Wed, 24 Mar 2010 12:41:04 +0000
> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> > On Wed, 24 Mar 2010 12:48:26 +0100
> > Branimir Maksimovic <bm...@hotmail.com> wrote:
> > > On Wed, 24 Mar 2010 11:16:06 +0000
> > > Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> > > > On Wed, 24 Mar 2010 10:57:37 +0100
> > > > Branimir Maksimovic <bm...@hotmail.com> wrote:
<snip>
> > > > > If this is allowed then yes, C and C++ does not assume
> > > > > flat memory model.
>
> > > > It doesn't - all that C requires of pointers is that they
> > > > can be dereferenced, converted to void pointers and back again,
> > > > and that adding and subtracting integers works within certain
> > > > well defined limits. Nothing requires them to be machine
> > > > addresses.
>
> > > Hm , how abstract C and C++ machine looks like? Is it flat
> > > address space or segmented?
>
> > What abstract machine ?
>
> What this mister is talking about then?
>
> http://www.stanford.edu/group/sequoia/cgi-bin/node/15
he's talking nonsense. He's really trying to talk about some tree-like
memory model and contrasts it with some flat memory model he chooses
to call the "C abstract memory model". This actually doesn't have
anything to do with C's memory model. The stuff about registers
doesn't even parse.
On the other hand the C standard does talk about an abstract machine.
"The semantic descriptions in this standard describe the behavior of
an abstract machine..."
<snip>
--
SICP is the most important printed literature to develop
from our species in the 20th century.
(Amazon Review)
Nick Keighley
> Seebs <usenet-nos...@seebs.net> writes:
> > On 2010-03-24, Keith Thompson <ks...@mib.org> wrote:
> >> Ahem A Rivet's Shot <ste...@eircom.net> writes:
> >>> It doesn't have to be a typedef - it usually is but it doesn't have
> >>> to be.
>
> >> How could size_t not be a typedef? It's not a keyword or a macro.
>
> > It could, however, be treated magically by the compiler.
consider a Maximally Perverse Compiler...
> > Which means that, while it appears to necessarily have the same semantics
> > as a typedef, there's no requirement that it actually *is* one.
actually the Standard says "The following types [...] are defined
[...] size_t". I thought a typedef didn't create a type but merely a
type alias. Doesn't this mean typedef has the wrong semantics to
define size_t and hence size_t /cannot/ be a typedef?
Ok, from the standard:- "A typedef declaration does not introduce a
new type, only a synonym for the type so specified."
> How is something with the same semantics as a typedef not a typedef?
>
> Yeah, ok, there might not be a line of C source code containing the
> tokens "typedef" and "size_t" in whatever entity "#include <stddef.h>"
> refers to. Similarly, printf might be some magic thing that acts like
> a variadic function, but really isn't one.
I'd invoke the "As If" rule. I agree with your duck remark below.
> To put it another way, a typedef declaration, perhaps
> typedef unsigned long size_t;
> that appears when you write
> #include <stddef.h>
> perfectly satisifies the standard's requirements for size_t. And no
> other C construct does so.
>
> It quacks like a duck.
I bet afc thought they had all the crazy people to themselves...
Branimir Maksimovic
Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
> Walter Bushell <pr...@panix.com> writes:
> > Branimir Maksimovic <bm...@hotmail.com> wrote:
> >> Problem is that segmented memory model is much better when working
> >> with 64 bit address space. Flat memory model wastes to much
> >> RAM. It would be better for standard C and C++ to provide
> >> appropriate pointer semantics in order to keep memory usage
> >> optimal. What is use of 64 bit flat pointers when you can actually
> >> just load segment base and work with offsets?
> ...
> > But ram is *so* cheap these days. Can you think of a reason for a
> > million pointers at once? And that would be 0.008 gigabytes.
> > Perhaps one needs to be that conscious for embedded work, but then
> > one is not working with 64 bit addressing either.
>
> 64-bit Alpha, POWER, and MIPS architectures have been used in
> embedded applications, complete with their native 64-bit
> addressing.
>
I guess they are more powerful than mainframes used in 70's and 80's ;)
In my router there is MIPS with *16mb* of RAM.
Unisis A mainframe had 4mb of RAM ;) (one that I worked on)
Branimir Maksimovic
Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
> Branimir Maksimovic <bm...@hotmail.com> writes:
> > Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
> >> No, a very small fraction of the virtual address space is mapped to
> >> physical RAM.
> >
> > Hm , why then people have problem with Linux OOM killer,
>
> Because they are using vastly more virtual address space
> than there is physical RAM.
>Which kinda follows from what
> Joe already said.
Yes, but you have to know how much GB of swap to enable.
Besides that then everything runs sluggish.
Nick Keighley
> Branimir Maksimovic <bm...@hotmail.com> writes:
> > Ahem A Rivet's Shot <ste...@eircom.net> wrote:
<snip>
> >> No ints are not C pointers they have *very* different
> >> arithmetic rules.
>
> > I don;t think so. as *(a+i) is identical to a[i] or i[a]
> > and a automatically converts to pointer to first element.
> > Did you know that array subscript is [commutative]?
[...]
> > Do you know why?
because Dennis said so
> Because both pointer+integer and integer+pointer arithmetic are
> supported (as well as pointer-integer and pointer-pointer). The
> language *could* have required the pointer to appear on the LHS of the
> "+", banning integer+pointer. The (unnecessary IMHO) symmetry goes
> back to the early days of C, when the distinction between integers and
> pointers wasn't as strong as it is now.
>
> > Only difference is that a+i increments by scale bytes, scale being
> > type that pointer points to.
>
> Pointer addition is a different operation than integer addition.
>
> > But C memory model assumes absolute addressing.
>
> Not really, though I suppose it depends on what exactly you mean by
> "absolute addressing".
I can't begin to guess what it means, but I'm pretty sure it's wrong.
> > You can't do b=a+i;c=a+b;
> > But you can decrement, since if you substract two absolute addresses
> > you can;t get out of segment bounds.
> > That is why it would be useful to have relative /absolute semantics.
> > Just because to avoid casting ints to pointers in order to
> > have convenient syntax for array indexing.
>
> I'm not sure what you're saying here, but in some of your other
> articles in this thread I think you're conflating two different
> things.
>
> C requires all pointers of a given type to have the same size and
> representation. char* and int* might be different, but any two
> pointers to char are stored the same way. On some systems, it might
> be convenient to be able to have different "flavors" of pointers to
> the same type, where the different flavors might, for example, be able to
> point to different regions of memory. On a 64-bit system, you might
> want to have 64-bit pointers that can point anywhere, and 32-bit
> pointers that can only point into the bottom 4GB of memory.
>
> C doesn't support this. Pointers are distinguished only by the type
> they point to. If I obtain a pointer to an int object, I can copy
> that pointer value into any other pointer-to-int object and
> dereference the copy without knowing or caring how the original
> pointer was generated.
>
> This kind of thing can be supported by an implementation-specific
> extension, such as the "near" and "far" pointer types in some x86
> compilers. But any code that uses such an extension is non-portable.
>
> On the other hand, C does *not* assume a monolithic addressing space.
If anything it assumes a segmented address space with every object in
its own segment. Not sure about sub-objects tho
> A C pointer might internally consist of a segment identifier plus
> an offset into that segment. Pointer arithmetic might affect only
> the offset.
<snip>
Branimir Maksimovic
Keith Thompson <ks...@mib.org> wrote:
> Branimir Maksimovic <bm...@hotmail.com> writes:
> > On Wed, 24 Mar 2010 14:04:54 -0700
> > Keith Thompson <ks...@mib.org> wrote:
> >>
> >> If you're talking about C, it's *very* important to remember that
> >> pointers are not integers, and integers are not pointers.
> >
> > Well digital computer is all numbers. array of 1' and 0's.
>
> But that's not all they are. Certain combinations of 1s and 0s have
> *meanings*. And we use languages at a higher level than raw binary,
> whether assembly language, C, Lisp, or whatever, precisely so we can
> manipulate those meaning rather than the 1s and 0s.
>
> > Remember, C was meant for assembler programmers.
>
> Not really. C is meant for C programmers. Assembler is meant for
> assembler programmers.
Yes, but C programming style is good assembler programming style.
>
> > Especially was fascinated that
> > you could crash computer with it same as in assembler.
> > Technically pointers are integers, but understanding
> > their meaning and usage on particular implementation
> > and exploiting it is not portable, of course.
> > But you *can* do it anyway if necessary and portability
> > is not of concern.
>
> Yes, if portability is not a concern, you can do all sorts of ugly
> things. You can treat pointers as integers in C, but you have to
> fight the language to do it, since C pointers *are not integers*.
> Feed the following to a C compiler:
> char *p = 0xdeadbeef;
> and it will at least complain, and very likely reject your program.
bmaxa@maxa:~$ gcc -std=c89 ts.c -o ts
ts.c: In function ‘main’:
ts.c:5: warning: initialization from incompatible pointer type
ts.c:6: warning: initialization makes pointer from integer without a cast
bmaxa@maxa:~$
bmaxa@maxa:~$ cat ts.c
int main(void)
{
int a=10;
int *pa = &a;
float *p = pa;
float *p1 = 0xdeadbeef;
return 0;
}
bmaxa@maxa:~$
That is why C is better than C++. You don;t have to cast in order
to compile such code. But with C you get *warnings* when you
do such things, unlike in C++ (more verbose code, but dangerous code
without warnings)
Casts are actually not necessary. They surve purpose just to shut up
compiler warnings which should be there anyway, for maintenance
programmers or ones that want to *port* code.
>
> [...]
>
> >> > I think, malloc guarantees largest segment
> >> > and ints are actually relative , short pointers into segment,
> >> > while you can still use absolute pointers as bases.
> >> > It's just a matter of realizing this.
> >>
> >> Sorry, I don't know what "malloc guarantees largest segment"
> >> is supposed to mean. The C standard, which is what defines the
> >> behavior of malloc, doesn't talk about segments. C is carefully
> >> designed to work on systems with either segmented or monolithic
> >> addressing spaces.
> >
> > Yes but, when you malloc you get chunk of raw memory
> > that can be indexed by integers of any type.
> > This maps 1-1 on assembler thinkology ;)
>
> Try thinking about C in its own terms. You might find it more
> rewarding than forcing it into an assembly-level model.
I understand, but when you know assembler, C and C++ programs
usually have less bugs regarding classic errors.
Thanks!
Nick Keighley
> On Wed, 24 Mar 2010 14:04:54 -0700
> Keith Thompson <ks...@mib.org> wrote:
> > If you're talking about C, it's *very* important to remember that
> > pointers are not integers, and integers are not pointers.
>
> Well digital computer is all numbers. array of 1' and 0's.
but is C required to run on such a machine? Intergers, I believe, have
to use a binary representaion. There's no requirement that pointers do
though.
> Remember, C was meant for assembler programmers.
no it wan't
> I first learned basic than assembler on spectrum 48kb.
> Then somehow C compiler was available for spectrum,
> so when I saw ++ operator, immediately recognized
> C as another assembler.
and you were mistaken. Assembler maps one-to-one (yes I know about
macro-assemblers) to machine code. C doesn't really do that.
> Especially was fascinated that
> you could crash computer with it same as in assembler.
this makes Windows NT an assembler
> Technically pointers are integers,
no.
> but understanding
> their meaning and usage on particular implementation
> and exploiting it is not portable, of course.
> But you *can* do it anyway if necessary and portability
> is not of concern.
>
> > It's possible to convert between pointer and integer types, but the
> > result of such a conversion (with the lone exception of converting a
> > constant 0 to a pointer type) is not portable.
>
> > > I think, malloc guarantees largest segment
> > > and ints are actually relative , short pointers into segment,
> > > while you can still use absolute pointers as bases.
> > > It's just a matter of realizing this.
>
> > Sorry, I don't know what "malloc guarantees largest segment"
> > is supposed to mean. The C standard, which is what defines the
> > behavior of malloc, doesn't talk about segments. C is carefully
> > designed to work on systems with either segmented or monolithic
> > addressing spaces.
>
> Yes but, when you malloc you get chunk of raw memory
> that can be indexed by integers of any type.
> This maps 1-1 on assembler thinkology ;)
so Fortran and Java are assembler?
<snip>
Nick Keighley
wrote:
> Dann Corbit <dcor...@connx.com> writes:
> > In article <1e27d5ee-a1b1-45d9-9188-
> > 63ab37398...@d37g2000yqn.googlegroups.com>,
> > nick_keighley_nos...@hotmail.com says...
>
> >> On 23 Mar, 20:56, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> >> > In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
> >> > (snip)
>
> >> > > That crossposting was, for once, not asinine. It served as a nice
> >> > > example why, even now, Leenux weenies are not correct when they insist
> >> > > that C has a flat memory model and all pointers are just numbers.
>
> >> > Well, you could also read the C standard to learn that.
>
> >> but if you say that you get accused of language lawyering.
> >> "Since IBM stopped making 360s no C program ever needs to run on such
> >> a platform"
>
> > We have customers who are running their business on harware from the mid
> > 1980s. It may sound ludicrous, but it if solves all of their business
> > needs, and runs solid 24x365, why should they upgrade?
>
> Because they could run an equivalently computationally powerful
> solution with various levels of redundancy and fail-over protection,
> with a power budget sensibly measured in mere Watts?
does it have a Coral compiler?
Ahem A Rivet's Shot
Keith Thompson <ks...@mib.org> wrote:
> Ahem A Rivet's Shot <ste...@eircom.net> writes:
> > On Wed, 24 Mar 2010 15:57:46 +0100
> > Branimir Maksimovic <bm...@hotmail.com> wrote:
> [...]
> >> Remember size_t is typedef. Can;t be float, can;t be pointer,
> >> it has to be one of available ints.
> >
> > It doesn't have to be a typedef - it usually is but it doesn't
> > have to be.
>
> How could size_t not be a typedef? It's not a keyword or a macro.
It can be a type.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Branimir Maksimovic
Nick Keighley <nick_keigh...@hotmail.com> wrote:
> On 24 Mar, 22:03, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > On Wed, 24 Mar 2010 14:04:54 -0700
> > Keith Thompson <ks...@mib.org> wrote:
>
>
> > > If you're talking about C, it's *very* important to remember that
> > > pointers are not integers, and integers are not pointers.
> >
> > Well digital computer is all numbers. array of 1' and 0's.
>
> but is C required to run on such a machine? Intergers, I believe, have
> to use a binary representaion. There's no requirement that pointers do
> though.
In my terms floats are also integers. I mean digital numbers.
> > I first learned basic than assembler on spectrum 48kb.
> > Then somehow C compiler was available for spectrum,
> > so when I saw ++ operator, immediately recognized
> > C as another assembler.
>
> and you were mistaken. Assembler maps one-to-one (yes I know about
> macro-assemblers) to machine code. C doesn't really do that.
True, but take for example this code:
bmaxa@maxa:~/armjpeg/asmtest$ gcc main.c -o main
bmaxa@maxa:~/armjpeg/asmtest$ ./main
bytes 512
0x602040 0x602000
3
5
bmaxa@maxa:~/armjpeg/asmtest$
bmaxa@maxa:~/armjpeg/asmtest$ cat main.c
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <sys/mman.h>
static char a[8192];
int main()
{
char* p = a + (4096-(size_t)a%4096);
if(mprotect(p,4096, PROT_EXEC | PROT_READ | PROT_WRITE)<0)
{
printf("mprotect %s\n",strerror(errno)); return 0;
}
int fd = open("atest.o",O_RDONLY);
if(fd<0){ printf("%s\n",strerror(errno)); return 0; }
int rc = read(fd,p,4096);
printf("bytes %d\n",rc);
void* (*fp)() = (typeof(fp)) p;
int (*fp1)(float) = (typeof(fp1)) (p+0x10);
memmove(p,p+0x40,1000);
void* b = fp();
/*
int i;
for(i=0;i<4096;++i)
{
if(!memcmp(p+i,"signature",9))break;
}
*/
printf("%p %p\n",b,p);
int k = fp1(5.14);
printf("%d\n",k);
k = fp1(8.14);
printf("%d\n",k);
close(fd);
return 0;
}
bmaxa@maxa:~/armjpeg/asmtest$ cat atest.c
static struct {
char sig[24];
int a;
float b;
} table = {"signature atest",5,3.14};
void *getDataAddr()
{
return &table;
}
int asmtest(float b)
{
int bb = table.b;
table.b = b;
return bb;
}
bmaxa@maxa:~/armjpeg/asmtest$
You can't do such things easily in other languages.
And yes, segmented model would require more work
to workout this;)
>
> > Especially was fascinated that
> > you could crash computer with it same as in assembler.
>
> this makes Windows NT an assembler
Windows NT is OS.
>
>
> > Technically pointers are integers,
>
> no.
Numbers. Ok , I think you all mean by integer mathematical
integer. My meaning for integer is digit, number.
>
> > Yes but, when you malloc you get chunk of raw memory
> > that can be indexed by integers of any type.
> > This maps 1-1 on assembler thinkology ;)
>
> so Fortran and Java are assembler?
Nope. I programed fortran iV , different thinking
not like assembler. Java also requires different
thinking.
Greets!
Branimir Maksimovic
Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Wed, 24 Mar 2010 11:49:16 -0700
> Keith Thompson <ks...@mib.org> wrote:
>
> > Ahem A Rivet's Shot <ste...@eircom.net> writes:
> > > On Wed, 24 Mar 2010 15:57:46 +0100
> > > Branimir Maksimovic <bm...@hotmail.com> wrote:
> > [...]
> > >> Remember size_t is typedef. Can;t be float, can;t be pointer,
> > >> it has to be one of available ints.
> > >
> > > It doesn't have to be a typedef - it usually is but it
> > > doesn't have to be.
> >
> > How could size_t not be a typedef? It's not a keyword or a macro.
>
> It can be a type.
>
Is there any significant difference of C size_t and C++ size_t.
I know in C++, you have to include at least cstddef or stddef.h.
Always thought that size_t is just typedef for largest unsigned int.
Peter Flass
Not any more;-) How many typedefs can dance on the head of a pin?
Sol-Terrasa mkfs ext4 da' Sussex
> bmaxa@maxa:~/armjpeg/asmtest$ gcc main.c -o main
> bmaxa@maxa:~/armjpeg/asmtest$ ./main
> bytes 512
> 0x602040 0x602000
> 3
> 5
Causes a segmentation fault on x86 :-D
--
http://www.munted.org.uk
One very high maintenance cat living here.
Nick Keighley
> On Thu, 25 Mar 2010 02:57:06 -0700 (PDT)
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > On 24 Mar, 22:03, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > > On Wed, 24 Mar 2010 14:04:54 -0700
> > > Keith Thompson <ks...@mib.org> wrote:
<snip>
> > > I first learned basic than assembler on spectrum 48kb.
> > > Then somehow C compiler was available for spectrum,
> > > so when I saw ++ operator, immediately recognized
> > > C as another assembler.
>
> > and you were mistaken. Assembler maps one-to-one (yes I know about
> > macro-assemblers) to machine code. C doesn't really do that.
the other important thing about assemblers is that they are tied to a
particular machine. Well written C can run on different machines.
<snip>
> > > Especially was fascinated that
> > > you could crash computer with it same as in assembler.
>
> > this makes Windows NT an assembler
>
> Windows NT is OS.
if you can crash a computer with it it's an assembler
you can crash a computer with Windows NT
=> Windows NT is an assembler
> > > Technically pointers are integers,
>
> > no.
>
> Numbers.
no.
> Ok , I think you all mean by integer mathematical
> integer. My meaning for integer is digit, number.
pointers aren't numbers. Not integers, sureals nor octonions.
> > > Yes but, when you malloc you get chunk of raw memory
> > > that can be indexed by integers of any type.
> > > This maps 1-1 on assembler thinkology ;)
>
> > so Fortran and Java are assembler?
>
> Nope. I programed fortran iV , different thinking
> not like assembler. Java also requires different
> thinking.
we'll just have to agree to disagree
Branimir Maksimovic
Sol-Terrasa mkfs ext4 da' Sussex <alex....@munted.org.uk> wrote:
> On Thu, 2010-03-25 at 11:16 +0100, Branimir Maksimovic wrote:
> > bmaxa@maxa:~/armjpeg/asmtest$ gcc main.c -o main
> > bmaxa@maxa:~/armjpeg/asmtest$ ./main
> > bytes 512
> > 0x602040 0x602000
> > 3
> > 5
>
> Causes a segmentation fault on x86 :-D
Of course , you have to as -R first object file ;)
Greets