Searching \ for 'Funniest...8x88 and PIC addressing' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Funniest...8x88 and PIC addressing'.

Truncated match.
PICList Thread
'Funniest...8x88 and PIC addressing'
1999\01\15@172526 by John Payson

flavicon
face
Note: Yes this does have to do with PICs... see below.

|  My point being that Intel (as usual) made some DUMB choices in there -
|they *chose* to only create/bring out 20 address lines from the 808x
|chips, and to only make the chip capable of accessing 1 Mb of memory
|(*I* for one didn't hold a gun to their head.)

Intel wanted to produce a chip which which was similar to their
8080, but which could access more memory (and be better in a num-
ber of other ways as well).  Since they didn't want to use larger-
than-16-bit registers, they needed a way to combine registers to
access memory.

The approach they came up with was to create four new 16-bit reg-
isters called "segment registers".  Every memory operation computes
a 16-bit address and then adds it to a segment register which has
been shifted left 4 bits.  As a result, accessing address $1234
with a segment register containing $5678 will access

 $ 1234
+ $56780
-------
 $579B4

location $579B4.  Using this scheme, any paragraph(*)-aligned block
up to 64K in size may be addressed the same as any other.

(*) Paragraph = 16 bytes

Regardless of what naysayers may mumble about Intel, the memory
architecture of the 8x88 was really pretty good.  The only inher-
ent limitation is that the highest addressable address is $10FFEF
($FFFF0 + $FFFF) which, on a part with a 20-bit address bus would
of course wrap to $0FFEF.

This is not to say that everything else on the chip was as well
designed.  The instruction set includes lots of good features and
the designers apparently had compiler authors in mind when they
designed the chip's addressing modes.  Unfortunately, there are a
few significant warts in the instruction set:

[1] The segment registers may be copied to and from other registers
   or memory; they may not be loaded with an immediate constant,
   nor can any arithmetic instructions operate upon them.

[2] Conditional branches are limitted to an 8-bit relative offset.

[3] The only forms of the input/output instructions use DX or an
   8-bit constant for the address and AX (or AL) for the data.

In general, though, the instruction set does a decent job at provid-
ing 20-bit addressibility on a 16-bit machine.  The 80286, on the
other hand, does a poor job of extending the 8086: the only way(*) to
access memory above $10FFEF is to enter "protected mode", in which
segment registers work totally differently, and the only way to return
to having segment registers work normally is to reset the chip.  The
IBM AT provides a hardware means of resetting the CPU, and the BIOS
startup routine checks a "non-boot" flag which indicates that it
should resume normal program execution (rather than doing a warm or
cold boot).  **THAT**, rather than anything to do with the 8086 arch-
itecture, is the biggest source of headaches for accessing large mem-
ory within DOS mode.

|Motorola's earlier processors were designed
|smarter in some ways than Intel (I've always sorta wished I had Dos for
|a 68030.  No segmentation <G>)

Yeah, but look at the 68HC16's addressing.  They added a 16-bit reg-
ister which functions as four 4-bit address extensions for the index
registers.  Although they nicely provided instructions to do math on
the full 20 bits of the extended index registers, the only way to load
or save a single full 20-bit index register is to use the B register to
transfer the high 4 bits.  Although pointer arithmetic works great if
you can keep your pointers in registers, any pointer operations which
can't be handled entirely in registers and which could cross a 64K
boundary must either have special-case code to deal with that, or must
do a laborious load/save operation after each step, e.g. to code some-
thing like:

struct {
 char x,y,z;
} *p;

       (p++)->y = 5;

requires something like:

       ldb     p       ; High 4 bits of pointer
       tbxk            ; Load them into the extension register
       ldx     p+1     ; Motorola likes big-endian format
       lda     #5      ; The constant '5' above
       sta     1,x     ; Offset into structure is 1
       leax    3,x     ; Add 3 to X [full 20-bit version]
       txkb            ; Move high 4 bits of pointer back into B
       stb     p       ; And then store it
       stx     p+1     ; Store the low half

On the 8x88, provided that p will only be used to access the first
64K of any particular data object, the above code could be written
as:

       les     bx,[p]
       mov     byte es:[bx+1],5
       add     word [p],3

Although a lot of people have said they like the HC16 instruction
set, it creates 'hard' 64K boundaries whereas the 8x88 manages to
avoid them.

** NOW WHAT DOES THIS HAVE TO DO WITH PICS **

PICs are, as anyone here most certainly should recognize, all 8-bit
parts.  On the new 18Cxx line, however, Microchip is planning to
increase the data addressing space to 4K and the code addressing space
to 128K.  It will be interesting to see what approach they use to
boost their addressing space.  Anyone who's done much programming with
PICs should be well aware that the banking schemes Microchip has used
have generally been less than convenient (at times it would be fair
to describe them as a royal pain in the tusch).  It'll be interesting
to see if they manage anything as [generally] convenient as Intel's.

Of course, the use of 16-bit addresses by 8-bit CPU's is hardly any-
thing new.  The 6502 has no 16-bit registers other than the program
counter [and address latch] but it can use up to 128 16-bit pointers
stored in the first 256 bytes of RAM to access memory; in addition,
it can add up to 255 to one of those pointers before using it as an
address.  This approach, however, would not work well on a PIC since
it requires several steps to be performed for a memory access.

As for my view, here's what I'd like to see on the 18Cxx:

[1] A two-word, two-cycle, means of loading any register from any
   other register or with an 8-bit constant, without affecting W.
   The simplest way to provide this function would be to have an
   8-bit "register" [i.e. latch] for this purpose, and instructions
   to load/store that latch.  If the latch is only allowed to be
   used for this purpose, and if interrupts are locked out between
   a load and the following instruction, then this would not add
   to the register saving requirement of ISR's.  Although this
   feature is not "directly" related to addressing, it is essential
   to the effective use of same.

[2] Two or more 16-bit FSR's (each split between two registers).  The
   use of 16 bits (rather than 12) would allow for expansion, and
   would also have other uses [see below].

[3] For each FSR, three special locations which would always read zero
   but would have special effects when written: f0plus, f0minus, and
   f0signed [or f1plus, etc.].  Writing any value to f0plus would cause
   that value to be added to added to fsr0 (8-bit unsigned); writing
   any value to fsrminus would cause it to be subtracted from fsr0.
   Writing any value to fsrsigned would cause it to be treated as a
   signed quantity and added to fsr0.  Note that, e.g., bsf f0plus,3
   would add 8 to fsr0 (read 0, write 8) thereby allowing the fsr's
   to be moved by any power-of-two value in one instruction.  In add-
   ition, given [1] above it would be possible to add any 8-bit quan-
   tity (constant or variable) to an fsr using 2 words and 2 cycles.

[4] In addition to their usefulness for addressing, FSR's set up as
   described above could also be very handy for performing some kinds
   of arithmetic calculations.  To add together a bunch of 8-bit num-
   bers, for example, simply move them all to 'f0plus'.  Voila!

|  I DO agree that hindsight's easier than foresight, but let's see how
|it would be if Intel ran Microchip.  </Facetious ON>

|  If Intel ran Microchip:

|  Every time a new PIC part came out, you'd have to ship your Picstart
|Plus to Intelchip so new hardware with the capability to program that
|new chip could be installed.  And pay for that "privilege" - of course!
|(Free Firmware upgrades are nice, aren't they?  And at least no hardware
|upgrades are necessary, for most new parts.)

Where do you get this idea?  Intel uses the same programming method
for all their microcontrollers within their 8x51 family, and their
8x86's are either programmed with a normal EPROM burner or in-circuit.

|  Every time additional memory space was added to an existing part, you
|would need to learn some new addressing scheme - so a 16C62 program
|ported to a 16C63 or 16C66 would require massive re-writes if it grew
|much at all, plus the addition of a proprietary and expensive memory
|management library that had to be licensed at considerable expense from
|someone.  (Paging's a MINOR annoyance, by comparison, to this!)  And
|newer parts would not (of course!) ever be pin-compatible with previous
|parts - all such "features" installed for your safety, of course.

The progression from the 8088/8086 to the 80286 was pretty clunky.
I'll defend the 8088's architecture but the 80286 is IMHO just plain
annoying.  As for the 80386, it can access all of system memory in
the same way as the 80286 (whereas the 80286 can only access the first
meg using anything resembling 8088 methods), though it adds an altern-
ative method which works much more smoothly (just use a 32-bit number
as a pointer, since full 32-bit math abilities are supported).

|  Opcodes would be picked out by rolling 26-sided dice (I always liked
|Zilog's opcodes better than Intel's, back in the Z80 days.  Sigh <G>)

The 8x86 opcode names make a lot more sense than those of many other
CPU's.  To subtract AX from BX, you would write:

       sub     BX,AX           ; Destination,source

To do so with propagated carry/borrow flag

       subb    BX,AX

|  And finally, any new PIC chip would have initially cost $500 or more,
|until a competitor came on the market, then and only then have been
|reduced in price <G>  (Pricing could be lower, but it's not THAT bad, on
|PICs.)

You mean you could actually BUY a PIC which ran more than 5 million
instructions per second?

I personally, for the most part like PICs.  IMHO, however, Microchip
has not done too well in their efforts to extend the PIC line.  If
PICs had good upward compatibility, the answers to the following
'quiz' would be much more consistent.  If you think you know the PICs
well, answer the following as completely as possible, considering the
entire line from 16C5x to 17Cxx:

-1- Can the TRIS instruction be used to set the I/O mode of all the
   port pins?  Is there any other method?  Are all I/O port address-
   es in the same page?

-2- Is any user memory available in all pages that contain I/O reg-
   isters?  Does any user memory map identically between pages?

-3- What is the relationships between GOTOs, CALLs, MOVs to PCL, and
   the upper bits of the program counter (real or "latched")?

-4- Can ISR's do anything useful without a full context save?  What
   must they save/restore and what can they leave alone?  How can
   such 'saves' be performed?

-5- In memory accessed via FSR, what sized contiguous address ranges
   are available?

-6- Is there any relation between the memory page accessed via FSR and
   that accessed with direct moves?

-7- Are all I/O pins available as digital inputs on reset?  If not,
   what needs to be done to make them so?

-8- Is the EPROM data register in the same bank as the I/O ports?

-9- What flags are affected by incf/decf?  How about clrf?

-10- Is it possible to load W with any (currently banked) memory
    location and set Z based upon its value?

Certainly, the inconsistencies in the above are not insurmountable, but
they can make porting code among different parts more difficult than it
would otherwise need to be.  Certainly, it's possible to code defens-
ively to avoid most of these pitfalls, but I'd be surprised if many of
the PIC experts here could complete the quiz above for the entire range
of PICs without failing to mention some potentially serious "gotchas".

FYI, I've been caught "by surprise" by -3-, -7-, -9-, and -10- when
code didn't operate as expected.  The rest aren't likely to cause
oops'es when writing new code, but could still easily cause difficul-
ties porting existing code among PICs.

1999\01\15@233936 by Gerhard Fiedler

picon face
At 16:25 01/15/99 -0600, John Payson wrote:
>[1] A two-word, two-cycle, means of loading any register from any
>    other register or with an 8-bit constant, without affecting W.
>    The simplest way to provide this function would be to have an
>    8-bit "register" [i.e. latch] for this purpose, and instructions
>    to load/store that latch.  If the latch is only allowed to be
>    used for this purpose, and if interrupts are locked out between
>    a load and the following instruction, then this would not add
>    to the register saving requirement of ISR's.

but on the other hand, if they had such a register, and you could use it
only for this purpose, somebody would come up and in this application
really would like to use it in a more general way, and not really see the
reason why not -- since he would be more than pleased to pay the penalty of
saving that register for the interrupts, since they are not critical in his
application... and then it comes out like the two general registers some
cpus have, which is a nice feature sometimes.

>[3] For each FSR, three special locations which would always read zero
>    but would have special effects when written: f0plus, f0minus, and
>    f0signed [or f1plus, etc.].

this is a cool idea. have you seen it implemented somewhere?

>I personally, for the most part like PICs.  IMHO, however, Microchip
>has not done too well in their efforts to extend the PIC line.

the smallest i've done before i came to the pics was intel's 8051 family,
and compared to them, pics are actually troublesome and i was pretty
surprised that anybody would become so popular with such an architecture.
(but of course it's not the architecture per se that made them popular...)

the 8051 family has a pretty good structure, and it's fairly
straightforward to program even in assembler, without the twists and turns
you need to do on the pics, but still has some nice out-of-line features
like the multiple register banks. (do i need to say i'm sooo glad to have a
good c compiler for the pics? :-) but then they're a bit above them, at
least pricewise :-)


thanks for your thoughts (in a general sense, not only for this message),

ge

1999\01\16@011108 by Mark Willis

flavicon
face
John Payson wrote:
>
> Note: Yes this does have to do with PICs... see below.

 Same here, though I admit visiting other topics enroute <G>

{Quote hidden}

 Know all that, liked the 4004 not much, liked the Z80 better than the
8080 than the 8008, etc. <G>

{Quote hidden}

 Yep, know all too well about segmentation, OLD history, disagree with
their choices;  They chose 20 bits AFACT arbitrarily;  Poor arbitrary
choices, is my opinion.  They could have used segment registers shifted
8, 12, or 16 bits left, as all of us know, giving us far more address
range, far easier; part of my gripe is that 16-byte paragraphs are tiny
for most PC type apps, even back during CP/M days I occasionally used
arrays of 256 bytes or larger <G>  (Yes, 64k beats the IBM mainframe's
4k page sizes!  But...)  We could have 256 byte paragraphs, just as
easily, or 4k paragraphs, and still have segmentation - or have just
gone to linear addressing and "shot the moon".  For a desktop PC, why
not try to make it easily expandible?  (I agree for embedded processors,
but I was talking desktop CPU's, admittedly these can resemble one
another sometimes!  <G>)

{Quote hidden}

 I agree that they did a good job of limiting the 808x to **20 bit
addresses**;  If we had 32-bit addressing, this wouldn't be germane,
would it?  Certainly not arguing that the result is useless - just that
the "thought aforethought" was lacking in some ways.

> |Motorola's earlier processors were designed
> |smarter in some ways than Intel (I've always sorta wished I had Dos for
> |a 68030.  No segmentation <G>)
>
> Yeah, but look at the 68HC16's addressing.

 I'm talking 680x0's, not 68HC16's <G>  Yeah, I know <G>  Whatever, I
think we're successfully misunderstanding each other here...

{Quote hidden}

 I don't do numerical analysis of really huge arrays or do
memory-mapped IO to huge disk files (for a couple examples where
segmentation has seriously ANNOYED me!) - on PICs; I am entirely FOR
different solutions for different processors - An axe doesn't make a
very good screwdriver, nor vice versa!  For a laptop or desktop PC I
feel we want linear addressing - especially with bloatware going the way
it's going - on a microcontroller, it shouldn't be expected unless you
want to pay far more, sure.  Paging is a pain, but really it's the same
general thing as segmentation - just different division of your address
space, into fewer, more fixed pages as opposed to many, overlapping
pages (aka segments.)  For that matter I like self-modifying code when
done right (obviously NOT something I can use on a PIC very often <G>)

{Quote hidden}

 Interesting suggestions!

{Quote hidden}

 You've missed entirely that I'm talking Intel PC family habits (how
they treat 80x86 *PC* CPU buyers), versus Microchip Microcontrollers,
I'm guessing?  (I think we're MIS-communicating here <G>

 You may've missed some Intel hardware bugs where they initially
insisted folks "just buy a new CPU" etc. if they really wanted parts
that worked right, didn't have "significant" hardware math bugs, etc.
etc. <G>

{Quote hidden}

 </Cruel ON> Do some Desktop PC game programming <Cruel OFF>;  <G>
Instead of memory access methods being supplied by Intel, lots of people
just BUY pricey memory access libraries so they can use memory easily in
real-time games such as Doom / Quake / UnReal etc.  All those
texture-mapped colored moving surfaces need lots of large-chunk data
accesses in RAM, quickly, and for non-embedded PC users it's the PITS!
Different usage than embedded machines, I agree!

 Also:  Microchip writes APP notes & gives it to buyers, free;  Intel's
mostly busy building the next generation of hardware <G>  (This
difference between Cathedral method, and the Bazaar method, is even more
noted with the recent "let the CPU do all the work, you don't need
peripherals in your home PC" insanity IMHO <G>)  If you haven't read
this article, (the Cathedral/Bazaar one) do - interesting!

{Quote hidden}

 Personal preference for Zilog opcodes is all, here.  On the 8080/Z80,
this is the difference (in effect) between Parallax and Microchip
opcodes - same object code, different but equivalent assembler
instructions.  I'm not talking about different CPU's (though if you want
easiest to teach to assembler newbies, I'd vote for the old CDC
mainframes' assembler as it's about the best I've ever seen.)  Personal
taste always IS personal, o'course <G>

> |  And finally, any new PIC chip would have initially cost $500 or more,
> |until a competitor came on the market, then and only then have been
> |reduced in price <G>  (Pricing could be lower, but it's not THAT bad, on
> |PICs.)
>
> You mean you could actually BUY a PIC which ran more than 5 million
> instructions per second?

 I mean that Microchip treats it's customers better than Intel treats
it's customers, mostly <G>  We heard rumors recently of a recall of a
certain new windowed part - I did not hear anyone laughing their head
off!  It was taken as a very likely possibility here on the list, if
there was a real hardware problem in the /JW parts!

 Intel would have said "that's not a serious flaw" initially in the
past, then "sorry, try buying some more, newer parts" once they fixed
the flaw, to you & I, same as they did in the Pentium math bug <G> and
unless you either really screamed loud or were a large enough buyer, you
might have to really push to get an actual recall, or wait for a lawsuit
to go through;  Looked to me like everyone here took the possibility of
a Microchip /JW recall as being a quite likely happening.

 To me, IF a part comes out with problems, and is recalled and replaced
with good parts, that means I can trust that company to not abuse me -
Charge a little more than I might like, maybe, but not to rob me blind
in return for junk.  And I appreciate that, and vote with my money.
(It's not that Microchip's the only good guy here - other micro and
microcontroller companies are nice as well! - It's just that Intel has
messed up SO badly in the past, and I'm still not amused by their
bahavior.)

{Quote hidden}

 Same as with any micro, we do have to watch the "Gotchas" - as Seymour
Cray said, "backwards compatible with all past mistakes", huh?  IMHO
Consistency is definitely GOOD, and Microchip has not been perfect here,
I agree.

 My solution is to focus on those chips most likely to give me what I
need, and get really familiar with those;  Not ideal (I agree, it'd be
nice if Microchip was perfect <G>) but it does beat trying to memorize
more than a human brain can remember...

 It is nice to have so many choices, but overwhelming at the same time.

 Mark, spam_OUTmwillisTakeThisOuTspamnwlink.com

1999\01\16@200559 by John Payson

flavicon
face
At 16:25 01/15/99 -0600, John Payson wrote:
>[1] A two-word, two-cycle, means of loading any register from any
>    other register or with an 8-bit constant, without affecting W.
>    The simplest way to provide this function would be to have an
>    8-bit "register" [i.e. latch] for this purpose, and instructions
>    to load/store that latch.  If the latch is only allowed to be
>    used for this purpose, and if interrupts are locked out between
>    a load and the following instruction, then this would not add
>    to the register saving requirement of ISR's.

|but on the other hand, if they had such a register, and you could use it
|only for this purpose, somebody would come up and in this application
|really would like to use it in a more general way, and not really see the
|reason why not -- since he would be more than pleased to pay the penalty of
|saving that register for the interrupts, since they are not critical in his
|application... and then it comes out like the two general registers some
|cpus have, which is a nice feature sometimes.

I said the "simplest" way to provide a means of moving reg->reg
without side effects involving W or flags.  In fact, I'd also
like the ability to do more than that, and as I've posted quite
a number of times before, here's how I would--in fact--go about
providing reg->reg functions:

 Add an 8-bit latch which is loaded from the ALU output and
 is mux-able into the ALU in place of W.  Add to the PIC's
 instruction set two instructions which will load that latch
 with either a constant or the contents of any register, and
 which will cause that latch to be used in place of W as the
 source operand for the next instruction.

 This would allow (using two words/two cycles) operations such
 as reg1=reg2, reg1=reg1+reg2, reg1=reg1-reg2, reg1=reg1+const,
 etc. to be performed without affecting W.  Additional goodies
 could be added as well, though interactions with interrupts and
 conditional code execution would need to be defined.

>[3] For each FSR, three special locations which would always read zero
>    but would have special effects when written: f0plus, f0minus, and
>    f0signed [or f1plus, etc.].

|this is a cool idea. have you seen it implemented somewhere?

Not yet [hoping the people in Arizona picked up on it when I sugg-
ested it quite a while back...]

Another thing I'd like to see in PICs that I forgot to mention...
a conditional jump instruction which would use all of the bits of
the next instruction word as a destination address (or else null
out the next instruction if the jump was not taken).  Not only
would this allow addresses to be specified directly without paging,
but it would probably allow conditional jumps to be performed one
cycle faster (when the CPU executes the sequence:

       btfss   reg,bit
        goto   bar

by the time the CPU decodes the 'goto' instruction it has already
fetched the following instruction.  The CPU thus has to spend an
extra cycle fetching the next instruction it should execute before
program execution can resume.  With a conditional jump 2-word ins-
truction, the execution unit would know to perform a jump before
fetching the instruction following the destination address word
(i.e. the instruction two away from the conditional-jump opcode).

While I wouldn't want to give up the test-and-skip instructions, a
conditional jump would be extremely useful (if I were designing a
new 14-bit architecture, I'd use the opcode space currently occupied
by goto/call for conditional jumps, using bit 13 of the next instr-
uction to distinguish between a jump and a call).

>I personally, for the most part like PICs.  IMHO, however, Microchip
>has not done too well in their efforts to extend the PIC line.

|the smallest i've done before i came to the pics was intel's 8051 family,
|and compared to them, pics are actually troublesome and i was pretty
|surprised that anybody would become so popular with such an architecture.
|(but of course it's not the architecture per se that made them popular...)

If you don't have to worry about paging, the PIC's instruction set
is actually quite useful and functional.  It would be nice to have
add-with-carry and load-W-without-affecting-flags, but for the most
part its instruction set does what is needed without a lot of fluff;
the use of FSR/IND as 'just another register' which works with all
instructions is much nicer than providing indirect addressing modes,
but only for select opcodes.

|the 8051 family has a pretty good structure, and it's fairly
|straightforward to program even in assembler, without the twists and turns
|you need to do on the pics, but still has some nice out-of-line features
|like the multiple register banks. (do i need to say i'm sooo glad to have a
|good c compiler for the pics? :-) but then they're a bit above them, at
|least pricewise :-)

The 8x51 has a reasonably-decent instruction set, though there are
a few significant weaknesses and oddities; the list of allowable
modes for 'cjne' is, to put it politely, bizarre.

|thanks for your thoughts (in a general sense, not only for this message),

You're welcome.

1999\01\16@204622 by John Payson

flavicon
face
|their choices;  They chose 20 bits AFACT arbitrarily;  Poor arbitrary
|choices, is my opinion.  They could have used segment registers shifted
|8, 12, or 16 bits left, as all of us know, giving us far more address
|range, far easier; part of my gripe is that 16-byte paragraphs are tiny
|for most PC type apps, even back during CP/M days I occasionally used
|arrays of 256 bytes or larger <G>  (Yes, 64k beats the IBM mainframe's
|4k page sizes!  But...)  We could have 256 byte paragraphs, just as
|easily, or 4k paragraphs, and still have segmentation - or have just
|gone to linear addressing and "shot the moon".  For a desktop PC, why
|not try to make it easily expandible?  (I agree for embedded processors,
|but I was talking desktop CPU's, admittedly these can resemble one
|another sometimes!  <G>)

The 8086's memory architecture easily allows arrays of up
to 64K bytes, aligned on any 16-byte boundary.  Why do you
seem to believe that creating data structures larger than
one paragraph is at all difficult?  While it would have
been possible for Intel to have used 256-byte paragraphs,
one of the advantages of the segment architecture is that
any paragraph-aligned data structure can be up to 64K,
*STARTING AT ADDRESS ZERO WITHIN ITS SEGMENT*.  Paragraph-
aligning data structures (when paragraphs are 16 bytes) will
cause a moderate, but not unreasonable, waste of space.  To
increase the paragraph size to 256 bytes would have meant
that more space would be wasted when paragraph-aligning
things.

Arguing that paragraphs should have been larger would be like
arguing--in the days of 40MB disk drives--that disk clusters
should be 32K in size (to allow partitions up to 2gig).  If
you don't have much storage, the theoretical ability to access
huge quantities of storage is far less useful than the real ab-
ility to access what you do have /efficiently/.

{Quote hidden}

|  I agree that they did a good job of limiting the 808x to **20 bit
|addresses**;  If we had 32-bit addressing, this wouldn't be germane,
|would it?  Certainly not arguing that the result is useless - just that
|the "thought aforethought" was lacking in some ways.

The 8086 is not a 32-bit processor.  Linear addressing is great
if your address space is no bigger than your CPU registers, but
is often not so great otherwise.  As for expandibility, the his-
torical problem was not just that upper memory couldn't be acc-
essed using the same mechanisms as the first meg, but that it
was hard to access **AT ALL** without breaking code that expected
to access stuff within the first meg the same was as it always
had.

> |Motorola's earlier processors were designed
> |smarter in some ways than Intel (I've always sorta wished I had Dos for
> |a 68030.  No segmentation <G>)
>
> Yeah, but look at the 68HC16's addressing.

|  I'm talking 680x0's, not 68HC16's <G>  Yeah, I know <G>  Whatever, I
|think we're successfully misunderstanding each other here...

The 68000 is a 32-bit processor.  As such, it is much better than
16-bit processors at accessing >64K data structures.  It's also a
relatively nice chip all around.

You were talking, though, about Motorola's earlier processors.  Al-
though I don't know when the HC16 came out, it's the only non-32-bit
processor of theirs I'm at all familiar with that can access >64K of
memory.  I mentioned it to further my point that accessing more than
64K of memory on a machine with 16-bit registers will necessarily
involve compromises.  IMHO, Intel did a far better job at forging
such compromises than any other CPU I've seen.

{Quote hidden}

|  I don't do numerical analysis of really huge arrays or do
|memory-mapped IO to huge disk files (for a couple examples where
|segmentation has seriously ANNOYED me!) - on PICs; I am entirely FOR
|different solutions for different processors - An axe doesn't make a
|very good screwdriver, nor vice versa!  For a laptop or desktop PC I
|feel we want linear addressing - especially with bloatware going the way
|it's going - on a microcontroller, it shouldn't be expected unless you
|want to pay far more, sure.  Paging is a pain, but really it's the same
|general thing as segmentation - just different division of your address
|space, into fewer, more fixed pages as opposed to many, overlapping
|pages (aka segments.)  For that matter I like self-modifying code when
|done right (obviously NOT something I can use on a PIC very often <G>)

I'm not quite sure what you mean when you describe paging
as 'the same general thing as segmentation'?  True, both
are means of trying to expand a limitted address space,
but that's about the extent of it.

{Quote hidden}

|  You've missed entirely that I'm talking Intel PC family habits (how
|they treat 80x86 *PC* CPU buyers), versus Microchip Microcontrollers,
|I'm guessing?  (I think we're MIS-communicating here <G>

The microcontroller and PC markets are very different.  It
would seem like Intel's behavior if they ran Microchip would
more likely resemble their behavior with regard to the 8x51
than their behavior with regard to the 8x86.

|  You may've missed some Intel hardware bugs where they initially
|insisted folks "just buy a new CPU" etc. if they really wanted parts
|that worked right, didn't have "significant" hardware math bugs, etc.
|etc. <G>

Intel really botched the PR on that one.  What they should
have said from the start is what they would eventually offer
a free replacement to everyone with a 'bad' CPU, but that
because of limitted production capacity people who would not
likely be hurt by the Pentium bug were not a high priority.

{Quote hidden}

|  </Cruel ON> Do some Desktop PC game programming <Cruel OFF>;  <G>
|Instead of memory access methods being supplied by Intel, lots of people
|just BUY pricey memory access libraries so they can use memory easily in
|real-time games such as Doom / Quake / UnReal etc.  All those
|texture-mapped colored moving surfaces need lots of large-chunk data
|accesses in RAM, quickly, and for non-embedded PC users it's the PITS!
|Different usage than embedded machines, I agree!

Under any 32-bit operating system, there is no problem with
any program accessing as much memory as it can get its hands
on.  I've actually written some code (when testing algorithms)
with lines like the following:

       long foo[1000000];

That's an array that takes up almost 4 megs of RAM, but I access
it no differently from any other.  When using 32-bit registers
for memory access, such things just work out wonderfully.

The reason people use goofy things like DOS 4/GW, etc. is that
they want to be able to use 'big memory' from within programs that
mostly use the old-style techniques to access memory.  Again, the
problem is not that accessing 'big memory' requires different tech-
niques than accessing memory under a meg; the problem is that the
CPU makes it hard to access the upper memory without entering a
special mode which is incompatible with everything else.

|  Also:  Microchip writes APP notes & gives it to buyers, free;  Intel's
|mostly busy building the next generation of hardware <G>  (This
|difference between Cathedral method, and the Bazaar method, is even more
|noted with the recent "let the CPU do all the work, you don't need
|peripherals in your home PC" insanity IMHO <G>)  If you haven't read
|this article, (the Cathedral/Bazaar one) do - interesting!

Where should I find that article?

{Quote hidden}

|  Personal preference for Zilog opcodes is all, here.  On the 8080/Z80,
|this is the difference (in effect) between Parallax and Microchip
|opcodes - same object code, different but equivalent assembler
|instructions.  I'm not talking about different CPU's (though if you want
|easiest to teach to assembler newbies, I'd vote for the old CDC
|mainframes' assembler as it's about the best I've ever seen.)  Personal
|taste always IS personal, o'course <G>

I know the 8080 opcodes were notorious, but Intel seems to
have made their opcodes for subsequent CPU's much better.

> |  And finally, any new PIC chip would have initially cost $500 or more,
> |until a competitor came on the market, then and only then have been
> |reduced in price <G>  (Pricing could be lower, but it's not THAT bad, on
> |PICs.)
>
> You mean you could actually BUY a PIC which ran more than 5 million
> instructions per second?

|  I mean that Microchip treats it's customers better than Intel treats
|it's customers, mostly <G>  We heard rumors recently of a recall of a
|certain new windowed part - I did not hear anyone laughing their head
|off!  It was taken as a very likely possibility here on the list, if
|there was a real hardware problem in the /JW parts!

Again, I think it's a function of which market (PC vs micro-
controller).  Of course, unless your name is "Ford" you're apt
to find that Motorola's treatment of customers makes many other
companies appear saintly.

1999\01\17@031854 by paulb

flavicon
face
John Payson wrote:

>>  Also:  Microchip writes APP notes & gives it to buyers, free;
>> Intel's mostly busy building the next generation of hardware <G>
>>  (This difference between Cathedral method, and the Bazaar method, is
>> even more noted with the recent "let the CPU do all the work, you
>> don't need peripherals in your home PC" insanity IMHO <G>)  If you
>> haven't read this article, (the Cathedral/Bazaar one) do -
>> interesting!

> Where should I find that article?

 Try:
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ points to:
www.tuxedo.org/~esr/writings/cathedral-paper.html
 And along the same lines,
http://www.opensource.org/
 And the *essential* reference:
www.tuxedo.org/~esr/jargon/jargon_toc.html
--
 Cheers,
       Paul B.

1999\01\17@063957 by Gerhard Fiedler

picon face
At 19:47 01/16/99 -0600, John Payson wrote:
>The microcontroller and PC markets are very different.  It
>would seem like Intel's behavior if they ran Microchip would
>more likely resemble their behavior with regard to the 8x51
>than their behavior with regard to the 8x86.

actually, it seems to me that intel left most of the 8051 market to other
companies which were more creative in integrating interessant peripherals
and enhance it otherwise, eg. philips, siemens, dallas. but at least they
didn't screw it up :-)

ge

1999\01\17@212529 by Mark Willis

flavicon
face
John Payson wrote:
{Quote hidden}

 Know all that, John;  I talk about having coded for large sparse
arrays/numerical analysis using way over 640k of ram, you assume I don't
know how to do blocks sized larger than a paragraph?  (4k or 8k blocks
are most efficient in the Dos file system, btw.)  Whatever, I don't want
to play the "I have coded more in assembler/C than you have" contest
game.  Please don't put words in my mouth here.

 What I'm saying is that, Using memory over 640k is quite
un-necessarily a pain, OBVIOUSLY, or game designers wouldn't be paying
3rd party companies royalties for the code to USE the memory over 640k
for any large-memory application.  The folks who wrote Doom, for
example, aren't horribly incompetent <G> - yet their application uses a
3rd party memory manager.  (I won't comment on the people who wrote Dos
or Windoze.  <G>)

> Arguing that paragraphs should have been larger would be like
> arguing--in the days of 40MB disk drives--that disk clusters
> should be 32K in size (to allow partitions up to 2gig).  If
> you don't have much storage, the theoretical ability to access
> huge quantities of storage is far less useful than the real ab-
> ility to access what you do have /efficiently/.

 Whereas, pesonally, I'd argue that cluster sizes should be
configurably smaller than 32k (if the operating system coders were
competent, the user should have choices and options here.)  I really
don't want to play "put words in my mouth" any more here.  If you're
going to argue that I'm saying something I'm not, I'll just stop trying
to have a constructive conversation.  We're OT in this listserve
anyways, and I have much to do in the real world.

 Mark

1999\01\18@100706 by Andy Kunz

flavicon
face
>example, aren't horribly incompetent <G> - yet their application uses a
>3rd party memory manager.  (I won't comment on the people who wrote Dos
>or Windoze.  <G>)

They just stole the code, then bought the company when they sued MS.

Andy

  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...