"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message 
news:4k1fb5Fa1si4U1@news.dfncis.de...
> The problem discussed in this subthread arises only if
>
> a) the micro is Harvard, yet offers read-only access to code memory
> for storing constants
>
> b) it does this by using different *instructions*, rather than e.g. a
> special 'magic' bit in the address or more generally by using a
> non-uniform memory mapping

I don't think I'd consider a computer to have a Harvard architecture if its 
code and data memories differed only in what their addresses were.

Arcady <abaldus@hotmail.com> wrote:
> Hans-Bernhard Broeker wrote:

> > Only if the compiler vendor didn't actually implement C, but only a
> > limited subset of it.  Because if he did, he must have put in a layer
> > abstraction between a C pointer and what the CPU treats as an address.

> If we look back to the PDP-11 years - I do not remember that there
> was any programmatic way for the user program to read the I space -
> only execute commands from it. 

On such a pure Harvard architecture, the need for an abstraction
between C pointers and hardware address doesn't arise in the first
place.  If consts can never be in code space, C only needs pointers
into data space, so the "one kind of pointer fits all" approach just
works.

The problem discussed in this subthread arises only if 

a) the micro is Harvard, yet offers read-only access to code memory
for storing constants

b) it does this by using different *instructions*, rather than e.g. a
special 'magic' bit in the address or more generally by using a
non-uniform memory mapping

c) the C compiler offers support for using this, but

d) its maker decided to do it by introducing non-standard pointer
types, such as a 'int __code_memory__ MyConstant;'

The decision between portability and efficiency only happens in step
d).  A C pointer can always be implemented to store the extra bit of
information ('this is in code memory') in the pointer's
representation, at the cost of rendering any access through such an
expanded pointer more costly than if it were just an address.  Not
surprisingly, such an architecture will expose quite a few bugs in
code that's sloppy about the rules of pointer usage in C.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Hans-Bernhard Broeker wrote:

> Only if the compiler vendor didn't actually implement C, but only a
> limited subset of it.  Because if he did, he must have put in a layer
> abstraction between a C pointer and what the CPU treats as an address.

If we look back to the PDP-11 years - I do not remember that there was any programmatic 
way for the user program to read the I space - only execute commands from it. So with the 
"proper" Harvard arch (PDP-11 wasn't the HA - just for clarification) there is no way for 
program to implement such "smart pointers" - only if arch provides you with some tricks - 
definitely not the case for big (big? man, look around!) machines and vital stuff for 
micros. Even the PIC's retlw trick will do (oh, then there WAS a way - pretty expensive 
though - to read at least some data from the I space of the PDP-11!)

Jonathan Kirwan wrote:

>>
>>IIRC, early ones didn't.  Later ones did.  
> 
> 
> Yes, but arcady was saying "even from the beginning of" in regards to
> C and the PDP-11.  This doesn't mean later PDP-11's, given the timing
> of events as I understand them.

I pretty much believe that you understand timing incorrectly. From now few years 
separating the early PDP-11 where C has been developed (and those where with the MMU 
indeed) and later models where separate I/D spaces have been introduced definitely looks 
like "the same time" - unfortunately for me it is :( As I remember - C compiler did work 
on the common I/D but even lint - did not... So, no lint on 11/34!

> 
> Also, I happen to have a manual set for the PDP-11/70 (a somewhat
> later PDP-11 with memory management) and the purpose of the memory
> extensions was as much to just extend the physical memory on the
> system as anything else.  It is mostly about "mapping" and
> constructing a virtual address space for programs, and not (as far as
> I can see) about separate code and data spaces.  What I see is read
> only and read/write controls, for example.

11/70 is later one with 22 bit of physical address, earlier ones had only 18 bits. And 
unix did not work w/o the MMU so there where the MMUs at the time when unix and C have 
been introduced (essential for unix but not for C). And separate I/D spaces where to 
extend the VIRTUAL address - limited to 16 bits no matter what the amount of memory we had.

I took Grant's notice about the constants - but my words weren't about the micros - it was 
about the harvard arch in generic - so no limitations for preloaded data in the Data space!

> I am just not at all sure what arcady was trying to say.

You think I do?

Thanks,
Arcady

On Thu, 10 Aug 2006 03:30:02 -0000, Grant Edwards <grante@visi.com>
wrote:

>On 2006-08-09, Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>
>>>Unix on the 80268 worked pretty much the same way: a 64K data
>>>segment and a 64K text segment.
>>
>> Well, that is a horse of a different color.
>
>Actually it was almost identical to the PDP-11 that I used for
>a couple years (from a user point of view).

No, I meant that the 286 (I assumed you meant the 80286, when saying
80268) includes a protection scheme that has quite another purpose to
it.  Code space that can be set to execute-only, which begins to look
a little like a separate memory but without the benefits of separate
address and data buses.

I've worked with the x86 series for many years of course, including
chipset register programming, MTRRs and MSRs, etc., and in multi-cpu
systems using APIC.  And never did I feel anything similar as when I
was programming PDP-11's.  The differences are manifest.

>Each process saw a
>64-bit text space and a 64-bit data space.  When the scheduler
>switch processes, both spaces were swapped for those of the new
>processes.  As long as everything fit in physical RAM, then all
>that was changed were the segment control registers: it went
>quite smoothly. As soon as you stared swapping to disk, things
>got very slow.

Let's just agree to disagree.  How a scheduler handled things isn't
what I was thinking about, I guess.

Jon

On 2006-08-09, Jonathan Kirwan <jkirwan@easystreet.com> wrote:

>>Unix on the 80268 worked pretty much the same way: a 64K data
>>segment and a 64K text segment.
>
> Well, that is a horse of a different color.

Actually it was almost identical to the PDP-11 that I used for
a couple years (from a user point of view).  Each process saw a
64-bit text space and a 64-bit data space.  When the scheduler
switch processes, both spaces were swapped for those of the new
processes.  As long as everything fit in physical RAM, then all
that was changed were the segment control registers: it went
quite smoothly. As soon as you stared swapping to disk, things
got very slow.

-- 
Grant Edwards                   grante             Yow!  My DIGITAL WATCH
                                  at               has an automatic SNOOZE
                               visi.com            FEATURE!!

On Wed, 09 Aug 2006 15:44:07 -0400, Walter Banks
<walter@bytecraft.com> wrote:

>The first released PDP-11's mostly shipped to research centers.  My lab at
>U of Waterloo had serial numbers 186 and 216 that were labelled PDP-11's
>By serial number 500 or so they were labelled PDP-11/20's same
>computer. These computers had a linear address space with 56K bytes RAM
>max and 8K of I/O space.

That's approximately my recollection.  I specifically mentioned the
PDP-11/20 because that is the one I recall as being "earliest."  My
memory could have been wrong on that point, and you have clarifed the
details some in my own mind.  Thanks.

>For nostalgia folks out there. I bought core memory for these computers at
>the then unheard of price of a $1 / Byte. This would be sometime in
>the early 70's . Yep the memory card that comes with your camera
>would have been worth millions.

I personally paid about $300 each for 4k dynamic ram cards from MITS
that didn't even work right because they were designed wrong.  That
was my first, and forced, serious foray into the wonderful world of
electronic design.  I fixed them.  But it took a month of learning and
doing.  That was... I think end of 1975, maybe early 1976.  Not quite
$1/byte, but not cheap and it came out of my meager (very meager)
pocketbook.

Jon

On Wed, 09 Aug 2006 18:23:18 -0000, Grant Edwards <grante@visi.com>
wrote:

>On 2006-08-09, Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>> On Wed, 09 Aug 2006 06:25:34 GMT, Arcady <abaldus@hotmail.com> wrote:
>>
>>>mc wrote:
>>>
>>>> 8051, PIC, etc., in this respect.  Among microcontrollers, the 68HC11 and 
>>>> MSP430 have Von Neumann architecture; almost all larger computers do 
>>>> (Pentium, VAX, etc.).
>>>
>>>Even from the beginning of the C on the PDP-11 it pretty well worked with separate I/D 
>>>spaces (and that is exactly how the Harvard architecture is visible for the programmer).
>>
>> As I understand the history, C was being developed before the PDP-11
>> was actually a product.  Am I reading you correctly as suggesting that
>> early PDP-11s (such as the PDP-11/20) had/have separate instruction
>> and data memory spaces?
>
>IIRC, early ones didn't.  Later ones did.  

Yes, but arcady was saying "even from the beginning of" in regards to
C and the PDP-11.  This doesn't mean later PDP-11's, given the timing
of events as I understand them.

Also, I happen to have a manual set for the PDP-11/70 (a somewhat
later PDP-11 with memory management) and the purpose of the memory
extensions was as much to just extend the physical memory on the
system as anything else.  It is mostly about "mapping" and
constructing a virtual address space for programs, and not (as far as
I can see) about separate code and data spaces.  What I see is read
only and read/write controls, for example.

I am just not at all sure what arcady was trying to say.

>Unix on the 80268 worked pretty much the same way: a 64K data
>segment and a 64K text segment.

Well, that is a horse of a different color.

Jon

Grant Edwards <grante@visi.com> wrote:

> The problem isn't separate I/D space, it's the need for
> non-volatile, read-only data.  

Suffice it to say that const exists.

> On Harvard architecture uC's usually the only way that can be
> accomplished is to put the "const" data into the "code" address
> space.

But it's not actually the only way, and it's not necessarily the best
way, either.  I.e. this usual choice is dubious.

> Once you've done that, you've got the whole mess of dealing two
> different flavors of pointers, two different flavors of memcpy, four
> flavors of memcmp, etc.

Only if the compiler vendor didn't actually implement C, but only a
limited subset of it.  Because if he did, he must have put in a layer
abstraction between a C pointer and what the CPU treats as an address.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

The first released PDP-11's mostly shipped to research centers.  My lab at U of Waterloo had serial numbers 186 and 216 that were labelled PDP-11's By serial number 500 or so they were labelled PDP-11/20's same computer. These computers had a linear
address space with 56K bytes RAM max and 8K of I/O space.

For nostalgia folks out there. I bought core memory for these computers at the then unheard of price of a $1 / Byte. This would be sometime in the early 70's . Yep the memory card that comes with your camera would have been worth millions.

w..


Jonathan Kirwan wrote:

> On Wed, 09 Aug 2006 06:25:34 GMT, Arcady <abaldus@hotmail.com> wrote:
>
> >mc wrote:
> >
> >> 8051, PIC, etc., in this respect.  Among microcontrollers, the 68HC11 and
> >> MSP430 have Von Neumann architecture; almost all larger computers do
> >> (Pentium, VAX, etc.).
> >
> >Even from the beginning of the C on the PDP-11 it pretty well worked with separate I/D
> >spaces (and that is exactly how the Harvard architecture is visible for the programmer).
>
> As I understand the history, C was being developed before the PDP-11
> was actually a product.  Am I reading you correctly as suggesting that
> early PDP-11s (such as the PDP-11/20) had/have separate instruction
> and data memory spaces?
>
> Jon