Instruction And Data memory

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

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!

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

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

Ohh, that must have hurt!

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

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.

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

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

John

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

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.

...

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()".

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...

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

John

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).

Oh, really? Why is M$ so inundated with buffer-overflow attacks? Why are they inundated with other Win attacks? Why have they been

"Ken Smith" wrote in message news:d7hr3l$jsm$ snipped-for-privacy@blue.rahul.net...

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.

In article , Larry Brasfield wrote: [...]

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.