Instruction And Data memory

[Roger Hamlett]

IIRC, I once scoured the PIC datasheet - _A_ PIC datasheet - to see how
hard a lookup table would be. Turns out it's a SOB.

Thanks,
Rich

Depends how big the table needs to be, and whether it is a conventional
PIC, or one of the 'flash' models. If the table is under one page bank
size, then you just have a list of RETLW instructions with the required
values, and a 'header', adding the value you want to look up to the
program counter. If it is over a page, it has to be split into multiple
sections, and becomes a SOB. On the latter flash chips, most support a
direct 'read' operation in the program memory, using a pointer register,
which makes it simple.

Best Wishes

 

[Spehro Pefhany]

IIRC, I once scoured the PIC datasheet - _A_ PIC datasheet - to see how
hard a lookup table would be. Turns out it's a SOB.

Thanks,
Rich

Got to be the only micro architecture that requires an application
note to describe how to implement a LUT.

Newer models are better, BTW, but you still have to be a bit careful
compared to Von Neuman parts like the HC05/08.


Best regards,
Spehro Pefhany

 

[Fred Bloggs]

Because you're ignorant, doesn't mean everyone else is.

Your terminology is meaningless and that is all there is to it.

 

[keith]

Your terminology is meaningless and that is all there is to it.

The terminology isn't meaningless at all. It describes the differences in
architecture quite well. Since you have no other point...

You're ignorant, and that's the end of that tune. Phbbbtt!

 

[Fred Bloggs]

The terminology isn't meaningless at all. It describes the differences in
architecture quite well. Since you have no other point...

You're ignorant, and that's the end of that tune. Phbbbtt!

No one who is serious about a thorough comparison of the technical
differences between any two particular architectures would be satisfied
with your dumb and meaningless Princeton/Harvard nonsense. And as for
your little jab about ignorance, that would have impact only a
memoryless target.

 

[Keith Williams]

No one who is serious about a thorough comparison of the technical
differences between any two particular architectures would be satisfied
with your dumb and meaningless Princeton/Harvard nonsense.

It's not "my" terminology, rather came to the biz long before I.

And as for
your little jab about ignorance, that would have impact only a
memoryless target.

Ohh, that must have hurt!
[/QUOTE]

 

[Keith Williams]

[...]
Not at all. There is a rather big difference between the two. A modern
x86 doesn't do well with self-modifying code, but it can. An 8051 OTOH.
The first is clearly Princeton and the latter clearly Harvard.

The PIC is a better example for Harvard. The 8051 uses the same bus but a
different command signal. The PIC has a bus just for instuctions.

IIRC, I once scoured the PIC datasheet - _A_ PIC datasheet - to see how
hard a lookup table would be. Turns out it's a SOB.

Thanks,
Rich

Got to be the only micro architecture that requires an application
note to describe how to implement a LUT.

Newer models are better, BTW, but you still have to be a bit careful
compared to Von Neuman parts like the HC05/08.

Yeah, the '51 bends the Harvard rules by having a MOVC to do LUTs.

 

[Fred Bloggs]

Ohh, that must have hurt!

Not at all- you are shy on the intelligence factor as well then...

 

[John Larkin]

PeteS <[email protected]> wrote in sci.electronics.design:

[instruction memory vs. data memory]

I'd make explicit that there is no technical difference between
instruction memory and data memory, in case that was what the
intent of the OP's question. They are the same kind of RAM since
drum storage was scrapped. Any differences in behavior are by design,
not by the nature of one or the other.

Not necessarily. Instruction memory can be quite different than data
memory in a Harvard Architecture processor.

Ah, okay...

Instruction memory runs with von Neumann's blessings, data memory
doesn't.

Not on purpose anyway. ;-)

It is a strange, if off-topic, observation that von Neumann made modern
computing possible by bridging the gap between instructions and data,
but modern computing does everything to make them as clearly distinct
as possible.

Yes, indeed. AMD introduced the No-Execute bit in the page table on
x86 processors to further segregate data and memory.

PDP-11s and VAXes had full I and D-space separation, and read-only
page attributes, DECades ago.

John

 

[keith]

[instruction memory vs. data memory]

I'd make explicit that there is no technical difference between
instruction memory and data memory, in case that was what the
intent of the OP's question. They are the same kind of RAM since
drum storage was scrapped. Any differences in behavior are by design,
not by the nature of one or the other.

Not necessarily. Instruction memory can be quite different than data
memory in a Harvard Architecture processor.

Ah, okay...

Instruction memory runs with von Neumann's blessings, data memory
doesn't.

Not on purpose anyway. ;-)

It is a strange, if off-topic, observation that von Neumann made modern
computing possible by bridging the gap between instructions and data,
but modern computing does everything to make them as clearly distinct
as possible.

Yes, indeed. AMD introduced the No-Execute bit in the page table on
x86 processors to further segregate data and memory.

PDP-11s and VAXes had full I and D-space separation, and read-only
page attributes, DECades ago.

Sure, so did the S/360 forty years ago. The NX bit extends this a bit
(sorry) further than just R/O, which has other uses too.

 

[John Larkin]

[instruction memory vs. data memory]

I'd make explicit that there is no technical difference between
instruction memory and data memory, in case that was what the
intent of the OP's question. They are the same kind of RAM since
drum storage was scrapped. Any differences in behavior are by design,
not by the nature of one or the other.

Not necessarily. Instruction memory can be quite different than data
memory in a Harvard Architecture processor.

Ah, okay...

Instruction memory runs with von Neumann's blessings, data memory
doesn't.

Not on purpose anyway. ;-)

It is a strange, if off-topic, observation that von Neumann made modern
computing possible by bridging the gap between instructions and data,
but modern computing does everything to make them as clearly distinct
as possible.

Yes, indeed. AMD introduced the No-Execute bit in the page table on
x86 processors to further segregate data and memory.

PDP-11s and VAXes had full I and D-space separation, and read-only
page attributes, DECades ago.

Sure, so did the S/360 forty years ago. The NX bit extends this a bit
(sorry) further than just R/O, which has other uses too.

What's surprising the extent that the Intel x86 architecture and
Windows were designed in ignorance of existing practice, and how they
are slowly "introducing" security features that were taken for granted
thirty and even forty years ago.

John

 

[keith]

[instruction memory vs. data memory]

I'd make explicit that there is no technical difference between
instruction memory and data memory, in case that was what the
intent of the OP's question. They are the same kind of RAM since
drum storage was scrapped. Any differences in behavior are by design,
not by the nature of one or the other.

Not necessarily. Instruction memory can be quite different than data
memory in a Harvard Architecture processor.

Ah, okay...

Instruction memory runs with von Neumann's blessings, data memory
doesn't.

Not on purpose anyway. ;-)

It is a strange, if off-topic, observation that von Neumann made modern
computing possible by bridging the gap between instructions and data,
but modern computing does everything to make them as clearly distinct
as possible.

Yes, indeed. AMD introduced the No-Execute bit in the page table on
x86 processors to further segregate data and memory.


PDP-11s and VAXes had full I and D-space separation, and read-only
page attributes, DECades ago.

Sure, so did the S/360 forty years ago. The NX bit extends this a bit
(sorry) further than just R/O, which has other uses too.

What's surprising the extent that the Intel x86 architecture and
Windows were designed in ignorance of existing practice, and how they
are slowly "introducing" security features that were taken for granted
thirty and even forty years ago.

To be fair, I think the hardware architects know what they're doing but
haven't had the silicon for long to do it. M$, on the other hand...

 

[Larry Brasfield]

To be fair, I think the hardware architects know what they're doing but
haven't had the silicon for long to do it. M$, on the other hand...

One of the old-timers at Microsoft related to me the
efforts that their engineers made to persuade Intel to
put 32-bit flat addressing and support for virtual
memory into the 80386.

The notion that Microsoft's software engineers are
ignorant of existing practise is folly, latched onto by
people who get their jollies from it for sick reasons.

A good example of "existing practise" that was left
behind, for good reason, in the Win32 API, is the
support of multitasking via the blunt instrument
known as "fork()".

 

[keith]

One of the old-timers at Microsoft related to me the
efforts that their engineers made to persuade Intel to
put 32-bit flat addressing and support for virtual
memory into the 80386.

The '386 was a *long* time ago. Transitors were not cheap then, and flat
addressing wasn't a deal. Hell it was BillyG that pushed for the 8088 for
the original PC (not that I think that was all bad).

The notion that Microsoft's software engineers are
ignorant of existing practise is folly, latched onto by
people who get their jollies from it for sick reasons.

Oh, really? Why is M$ so inundated with buffer-overflow attacks? Why are
they inundated with other Win attacks? Why have they been
*SO* slow to close these holes? Good grief, you must work for M$.

A good example of "existing practise" that was left behind, for good
reason, in the Win32 API, is the support of multitasking via the blunt
instrument known as "fork()".

<yawn>

 

[John Larkin]

The notion that Microsoft's software engineers are
ignorant of existing practise is folly, latched onto by
people who get their jollies from it for sick reasons.

Ah, the geniuses who, after a decade of dedicated effort, managed to
allow a JPEG file virus to take over Windows XP.


http://www.cultdeadcow.com/cDc_files/cDc-351/


John

 

[Ken Smith]

One of the old-timers at Microsoft related to me the
efforts that their engineers made to persuade Intel to
put 32-bit flat addressing and support for virtual
memory into the 80386.

The old timer may be misremembering about virtual memory. IRRC the 286
could do a 16Meg address space VM when running with 1Meg of RAM.

 

[Larry Brasfield]

The old timer may be misremembering about virtual memory. IRRC the 286
could do a 16Meg address space VM when running with 1Meg of RAM.

My terminology and memory may be flawed here, but
my recollection is that the 286 could not handle many
"pages". Segment selectors were either strictly limited
in number or had to be slowly reloaded from memory
if lots of small segments were used to simulate a modern,
paged VMM. Virtual memory with pages too large to be
likely paged out is more of a gimmick than a benefit.

I seem to recall that it was the 386 (among x86 uPs)
that first managed to get instruction retry upon fault to
work right. Virtual memory without on-demand paging
is also closer to gimmickry than utility.