Hello Bob,

NXP took care of most of the issues long time  ago. Remaining bugs are well
documented, better than parts from other  companies without documented bug list.

Get the /01 versions of the chips. Available for around $2 in volume. Easily
available on Digikey, and dev boards are $30.95 on Sparkfun.  Free GNU tools
available, including several free OS's. Love the fact that  executables run on
different parts, one can choose based on memory  requirements.

Another one is NEC, they make a host of Microcontrollers that are  extremely
popular in Detroit. Lot's of support, high-reliability with wide temp  ranges
etc. They have units with direct LCD drive, motor control circuitry,  etc.

bye,
Said

**************The year's hottest artists on the red carpet at the Grammy
Awards. Go to AOL Music.
(http://music.aol.com/grammys?NCID=aolcmp00300000002565)

My favorite uC familly is made by Silabs.

They have a line of 8051 variants with excellent performance (up to 100
MIPS) and the SDCC compiler is free.

I have documented the main reasons for liking it there:

http://www.eds-fl.com/cgi-bin/wiki/wiki.cgi?SiLabs

(nomal ko4bb.com web site is down tonight, don't know why)

Didier KO4BB

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.6/1280 - Release Date: 2/15/2008
9:00 AM

I'll second this.  I'm kind of fond of the MCS-51 family for 8 bit
applications.  They're really nothing special, old school stuff, but
they have something like 40% of the embedded market, and once you
learn their quirks, it just kind of sticks.  Multi-source, and lots
of variants.  There's a free embeddable BASIC interpreter on the net,
SDCC C compiler, and almost 30 years worth of tools & code for it
kicking around the net.

The SiLabs mixed analog family is really amazing.  They depart for
several '51 family norms, but overall seem worth the trouble.  I like
the Atmel derivatives.  More info & resources over at www.8052.com

I regard PIC chips as something to be avoided.  Horrible little
architecture that should have died back in the 70's.  It gained a
foothold with hobbyists due to the ease with which they can be
programmed.  The modern '51's are just as easy, and in some cases
easier.  Some of them ship with bootloader that can be activated on
reset, and programmed using the onboard serial port.  Last I checked,
even the AVR's are missing out on that, though they're relatively
easy to program as well, and have an arch better suited to C.

de KC6OOM/5

On Feb 15, 2008, at 10:12 PM, Didier Juges wrote:

...

I agree on the PIC. Aside from great marketing and lots of good, old
fashioned DIP packages great for hobbyists and for prototyping, the
architecture and development tools do not have much to attract.

I like the 8051 because you are not tied to one vendor, code is everywhere
and options abound. In my job, it's good to know that if I need help, an
8051 aware software engineer is only a phone call away.

The Texas Instrument MSC1210 is an 8051 variant with some interesting
quirks. Aside from a good 24 bit ADC with 1:64 PGA, up to 32k of flash,
33MHz clock with a 4 clock core and 2 serial ports, they are programmable
via the serial port with a built-in bootloader and a VB program (I got it
from the TI rep, not sure it is on the web site, I have a copy with source
code, the API is not officially documented, but trivial to reverse engineer
using the VB source code, which is rare nowadays). They also have the
Phillips variant Port I/O where pins can be set as typical 8051 (open
collector) or 3 state/push-pull via Data Direction Register (more convenient
in my opinion). On the other hand, there is no debugging tool that I am
aware of. Getting the first piece of code running may be a challenge to the
uninitiated. A very nice chip overall.

Didier KO4BB

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.8/1288 - Release Date: 2/19/2008
8:47 PM

On Tuesday 19 February 2008 06:36:02 pm Robert Vassar wrote:

The PIC gained a foothold due to Motorola, not Hobbyists.
At the time most embedded designs were moving to the 6805 family
for the low end (small pin count) chips.  Then Motorola said
"Sorry guys.  Detroit bought all of them for the foreseeable
future."  The PIC was the only real option at the time, outside
of the Zilog Z8; 8048 & 8051 had not yet moved to small
pin counts.  If it was not for that move by Motorola the
world would be a very different place today.

I have an original PIC data book from General Instruments here,
and if you read that today, you'd wonder why anyone would
want to design in this part intended to run a Washing Machine.
The PIC18, other than the RAM bank switching, is not that bad.

Don't write off the dsPIC/PIC24, those are good parts, more like
the 68000.  Also the PIC32 is based on MISP, so even Microchip
has learned their lesson.

Almost all AVR's do have bootloader abilities, but you do have
to get the bootloader code in there with a programmer
the first time around.  That approach has the advantage
of giving you control of how you want to bootload,
IIC, SPI, Serial, CAN, etc...

--
http://www.wearablesmartsensors.com/
http://www.softwaresafety.net/ http://www.designer-iii.com/
http://www.unusualresearch.com/

In message 200802200605.47218.bob.paddock@gmail.com, Bob Paddock writes:

Any single simple sounding explanation for a complex phenomena is
more likely to be wrong than correct :-)

There are many reasons why PIC's are popular, from being virtually
indestructible to rampaging piracy of cable/sat-TV cards over
sheer idiocy on the parts of various other chip producers.

And don't forget quality of documentation here, the easier the
documentation is to understand the more mindshare a chip gets.  My
postboy for this theory is the abysmall Z-8000 which everybody
talked up a storm.

I like the fact that there are many and varied microcontrollers
available, and if anybody want to join me on one of my next
projects, you will be more than welcome:

An ADuC7020 (ARM, 1msps ADC) based LORAN-C frequency (and possibly
phase) receiver.

Poul-Henning

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

On Feb 20, 2008, at 5:05 AM, Bob Paddock wrote:

I'm sure you'll agree that there's a difference between: "gained a
foothold with hobbyists" and "gained a foothold because of
hobbyists".  Point being, that at one time it was much easier to
flash program a PIC on your kitchen counter than it was to program a
'51.

True.  But that could be said of most flash uC's.  Several of the '51
variants come with a bootloader from the factory.  Sadly, I believe
one of my favorites, the AT89C51ED2 is no longer available in 40
PDIP.  (Yea... I know... Long past time to go SMD...)

Rob

Robert Vassar wrote:

Wow!  I guess I should stop using them.  I have placed thousands of
PIC's in devices that I have built for the military, and never had
even one fail.

I program them entirely in "C", and mostly use the units that have
a 10 bit ADC, and a PCM cell on board.

The modern '51's are just as easy, and in some cases

And I assume they have them in 6 or 8 pin surface mount with 4 or 5 ADC
channels, and a built in clock oscillator that has a better than
1% accuracy over the full military/industrial temperature range?

Oh, and I forgot, a uart on every pin?

PIC's are the greatest little problem solvers in existence.

Some of them ship with bootloader that can be activated on

Who cares?  PIC's program very nicely in "C" too.  You have to remember
they are a very small machine, so stupid things like recursion are out,
but I have rarely found that I couldn't do what I wanted to do with them.

And CCS's $100 "C" compiler produces code that is as good or better than
I can do in assembler, and I am no slouch in assembler.

-Chuck Harris, Not a hobbyist!

Bob Paddock wrote:

I doubt it, the audience of these two devices is quite different.
The 6805 family could address 64K external RAM/ROM/IO.  The PIC
has no such capability.  The original PIC's had 64-128 words
of program ROM on board, and something like 32 bytes of RAM.
They could not address external RAM, ROM, or IO devices.

Because they have a "Washing Machine" sized job?

There are thousands of tasks that are marginally too big for a PAL,
and too small for a general purpose microprocessor.  The PIC is for
those jobs.

True.

I cannot imagine what lesson they needed to learn.  They made a line
of extremely easy to use microprocessors that are about as cheap as
the package they come in.  I should be so smart as they.

-Chuck Harris

On Feb 20, 2008, at 10:41 AM, Chuck Harris wrote:

Not at all.  Embedded products generally have higher quality needs
than general purpose computing as we've come to know it today.  Let's
face it, when a traffic light controller or a military device wanders
off the end of a null pointer people die.  You're a pro, you
understand these problems.  Engineering is compromise.  Use the tools
you feel comfortable with that allow you to do your job.

As a software professional that plays with uC's for fun, not work,
I'm going to choose something that doesn't use oddball word lengths,
and has a nice orthogonal instruction set with a rich set of
addressing modes.  I learned the '51 back in high school 20+ years
ago.  If someone else was going to pick up a uC arch from scratch for
hobby purposes, I would probably recommend the AVR.

SiLabs makes some very remarkable derivatives, which I've not had the
pleasure to play with.  I'm not sure they get down to the 6 or 8 pin
point.

Why on earth?  No... I don't want to know.  :-)

s/PIC's/uC's/ and we agree....

Anyone trying to make a C compiler for the chip?  Anyone concerned
about the quality of the compiler, mixed language use ala C with
assembly, or code portability?

I have to confess, I'm rather surprised at your passion for the PIC.
But hey... I spend all day working on Solaris and Linux, and use a
Mac everywhere else just to be 100% Microsoft free.  So while I'm
surprised, I can understand it.
:-)

Cheers,

Rob , "software engineer", but uC hobbyist...

Robert Vassar wrote:
...

Which you probably will never see from your C compiler.

I really enjoyed programming in 68020 assembler.  It was just like
programming in C, without the compiler.

The 68020, and its ilk, has truly is a lot of baggage for an embedded
processor to carry around and feed power to.  I prefer to make the
compiler sweat, and keep the processor lean and cheap.

I only develop the code once, but many many copies of the hardware get
made.

I learned the '51 back in high school 20+ years

I was progrmming '51's about 20 years ago too, and I never particularly
cared for them.  But back then, compilers for such tiny processors weren't
readily available... Sure, Intel had some MCS crap that would do the job,
but tied you down to one of their overly large, overly noisy, and overly
slow development stations.

When you are trying to develop a part, and you don't want to use
an emulator, or simulator, it can be handy to wire up a 1 wire
TTL RS-232 port to let you know what is going on.  With the CCS
C compiler, I can put a very tiny software UART on any pin.  So,
for instance, I can use a pin that ordinarily would run an LED
as a diagnostic port.

Many would say this is a religious issue, but I would disagree.
The 6 and 8 pin PICS are simply awesome in what they can do in
virtually no space.  The tools are cheap, or free.  The PIC's are
cheap too.

A recently I had a customer that needed to augment a single RS442
command that came from a black box, and went to another black box.
I put a little 8 pin PIC in a connector shell, and the problem
was solved.

In another project, I replaced a circuit that used an opamp comparator,
and a 555 timer with a single 8 pin PIC, and was able to gain better
functionality, and keep the adjustment pots that the customer loved.

The neat part was the PIC only cost 1/2 the price of the opamp and 555,
drew less power, was more reliable, covered full industrial temperature
range, and didn't need all of the resistors and capacitors the analog
timer needed.

The program was written in C, and took about 50 lines of code.

I made a series of intelligent, rapid battery chargers using one of
the 18 pin PIC's.  It handled the charging algorithm, and housekeeping
chores, and produced the PWM used by the power supply, and by a variable
current load used in the charging process.  One PIC did it all.  The
only other components on board were a few FET's and resistors.

Oh, did I mention, it auto detected the charge adapter, and was capable
of charging every small rechargeable battery the Army used for the last
40 years?

I've done hundreds of little things like this.

The PIC being a very simple RISC processor actually makes life pretty
easy for the compiler writer.  The CCS compiler I have been using for
years is tiny in size, and generates better code than I can do in
assembler.  It has only 32 commands to juggle, and only a couple of
registers.  GCC is a monster, and is way overkill for such a tiny
processor, yet it is used on many of the 8 bit uC's.

...

I to spend my days using Linux.  There isn't a Microsoft product anywhere
around here, though that will have to change for income tax time, because
I cannot seem to get TaxCut to work under wine this year.

PIC's get the job done.  When the job is done, I get paid.  I do embedded
work, but my definition of embedded is something I can code up in a couple
of days and ship.

The largest PIC I use generally is the 16F690.  It is a 20 pin package.
I use it for the pin count, and the gizmo's inside, not the code size.

Some consider embedded work to be stuffing a mainframe computer in
a 1/4 ATR chassis... and I have done that too... but I don't consider
it to be embedded.

-Chuck Harris

On Wednesday 20 February 2008 11:53:23 am Chuck Harris wrote:

Not sure what device you are describing, but it is not a 6805.

Chuck, I'm curious to know what other micros you have programmed?

At 06:36 PM 2/19/2008, Robert Vassar wrote...

I suppose it's a religious issue, but I have always preferred
Motorola-style (MOS, Microchip), instruction sets (more orthogonal) and
mnemonics to Intel-style ones (Atmel). It makes more sense (at least in
English) to say "put the bread on the table," than "put on the table
the bread."

And don't get me started about linear addressing and memory I/O
(Motorola) vs. butt-ugly segmented addressing (Intel).

Bob Paddock wrote:

I had thought it did, but looking on google it appears that it has
a fixed RAM and ROM space... rather capacious compared to my usual
needs.

Oh, let's see:

8008, 8080, 8085, z80, 8041, 8048, 8051, 1802, 6800, 68020, 68030, 6502,
8088, 8086, 80186, 80286, 80386, 80486, 80586, 80686, 16C731, 16C732,
16C733, 12F675, 16F676, 16F628, 16F690, ...

Does a PDP-8/E count as a micro?  How about an IBM-360 ;-)

There were others, really weird stuff, but I can't think of them off the
top of my head.

And you?

-Chuck Harris

Mike S wrote:

I suppose that you are bothered by:

X = 3000

Because that is the same as mov x,3000 in virtually all of the early assemblers.

It served a purpose.  Don't blame it on intel, blame it on DEC and
IBM.  Ever program a PDP8, or an IBM360?

When intel settled on the CS,DS,ES, SS architecture, they did so because
it made it easy to write pascal compilers.  Someone in the computer science
world told them that pascal was the way to the future.  I guess they were
wrong.

-Chuck Harris

At 09:23 PM 2/20/2008, Chuck Harris wrote...

How do you figure that? The verb is in a different place. Perhaps you
are arguing that the mnemonic should be "R mov M"?

That's no excuse.

Mike S wrote:

Humor?  Perhaps you are saying that you are omniscient?

I guess I am tiring a bit of the "my micro is better than your micro"
part of the discussion.

I agree with Chuck that PIC's are fine, especially with the CCS C
compiler, but what ever works for anyone is fine as long as it does the
job and remains obtainable. I, also, can't see any reason why I would
want to waste time by writing in assembly unless there was a good
reason. The CCS C compiler, by the way, does support inline assembly
code if you have a need.

At 10:41 PM 2/20/2008, Rex wrote...

No, but I don't buy the "pascal compiler" BS. The first common
architecture on which a Pascal compiler was implemented was the PDP-11,
a strongly orthogonal, memory-mapped I/O, "Motorola-type" architecture.
The later, common, P-system was based on a virtual stack based
architecture. Intel's segmented architecture isn't close to either, and
provides no unique benefit for a Pascal complier.

It's strange that neither the contemporaneous literature (notably the
Osborne microprocessor book series), nor current community consensus
(Wikipedia) makes any mention of Pascal as the cause of Intel's
segemented architecture.

Mike S wrote:

I'm not arguing anything at all.  Assembler in the form of
mov x,3000 meaning x=3000 has been around from the very beginning.
It precedes intel's choice by easily 30 years.

The arrangement:

 label mnemonic argument, argument

came about because it requires next to no storage when writing an
assembler...something that was once of crucial importance.  It is
also very easy to parse, something that was also very important on
early machines, including the 8008, 8080, and 8086.

If it bothers you a lot, write a couple of literals that replace
load with mov, and then you can have:

load x, 3000

Which is what zilog did with the Z80.

Or use one of the universal assemblers, or better yet, C.

The way the assembler in input is just persiflage, it doesn't have
anything to do with the actual architecture of the processor.

Intel didn't need an excuse, they were the inventors, and Pascal is
why they created the CS, DS, ES, SS architecture.  Hardware used
to be expensive.  It used to be hard to make a wide bus, and
a wide instruction set.  It would have been impossible for intel
to put a 32 bit bus and register set on a processor like the 8086
back in 1978.  It would have been impossible for any foundry at
that time.  Motorola had the benefit of being a few years later on
the design curve.  But in spite of that, Motorola still never had a
really big win.

Motorola's architecture may have been more elegant, but they lost on
price vs. performance.

-Chuck Harris

Hi Chuck,

I had forgotten these tricks, which were the norm 20 years ago when I was
too lazy to pull the 6805 emulator. Now that I am used to the full debug
capability of the Silabs chips, which uses only the reset and one other pin
on the smaller chips (the other pin being able to share debug and normal
duty), I don't have to resort to tricks like this :-) You get that
capability even with their $18 USB based "development system" that's the
size of a stick of gum.

No religion involved, I think the PIC line is unequalled when it comes to
the variations and features that are available in the small pin count
packages. Silabs only has half a handful of chips in DIP packages (is two
the same as half a handful?) but they have some pretty awesome parts in SM
packages that are 3x3 mm or so (they start at 11 pins, 10 + a tab), so if
you do not do the soldering by hand, you can't complain that there is no
room for a powerful uC.

I am getting familiar with the AVR line simply because a number of my
friends use them and speak highly of the architecture, but in general, I try
to stay with open, multi-sourced architectures, so the 8051 has a leg up on
PICs and AVRs from the start. I made that decision when Motorola forced me
out of the 68HC05, like so many others. I have not regretted it. Motorola
was not able to get me in the HC08, even though they gave it a good try. I
was not going down that road again. Burn me once, shame on you, burn me
twice, shame on me (or is it: don't burn me again?)

The Silabs chips start at a couple of $, so they are out of the sub-$1
market for sure. That's fine with me, I don't mind paying an extra $ for the
features and convenience :-)

Like many things, uC are tools. The tool that you are the most comfortable
with is often the best choice, for practical reasons, even more so when you
have to make a living out of it. For me, it's important to know that when I
start a project, I can finish it within schedule and within budget. My
familiarity with the 8051 and many of its variants (and my favorite
compiler, and the ton and a half of available code) gives me that
capability, but as you pointed out, it's not the only way. I understand you
feel the same about the PIC. That's perfectly OK.

Now, if you want an evening of fun, buy a Silabs toolstick and a base
adapter (about $28 + shipping from Mouser) and you have everything you need
(hardware and software, including demo version of the Keil C compiler) for a
fun uC project. Please note the Keil C51 compiler can be replaced with the
free and excellent SDCC compiler.

Here is an example of what you can do in an evening:
http://www.ko4bb.com/Test_Equipment/AFSignalGenerator/SigGen.html

I have built a bunch of small projects using the small Silabs target boards
directly.

Didier

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.9 - Release Date: 2/20/2008 12:00
AM

There was ONE variant of the 68HC05, the original CMOS (as opposed to the
NMOS 6805) which had an external address and data bus. It came in a 40 pin
DIP package. I never used it but I saw it in equipment I was working with at
the time. It had a few instructions that the NMOS parts did not have, but it
was supplanted by the HC05.

Didier KO4BB

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.9 - Release Date: 2/20/2008 12:00
AM

Mike S escribió:

Exactly the two reasons that made me say '6805 and 6811 were fun' and 'I
did not liked the 8051 at that time' :)

Regards,

Javier

--

Javier Herrero                            EMAIL: jherrero@hvsistemas.com
HV Sistemas S.L.                          PHONE:        +34 949 336 806
Los Charcones, 17A                        FAX:          +34 949 336 792
19170 El Casar - Guadalajara - Spain      WEB: http://www.hvsistemas.com

At 12:03 AM 2/21/2008, Chuck Harris wrote...

One could equally say "move 3000,x meaning x=3000." What's your point?

Repeating something doesn't make it so. Authoritative citations, please
(preferably contemporaneous with the release of the architecture, and
not current rationalizations).

Yet only a year later, in 1979, Motorola introduced the 68000 with a
full 32 bit architecture.

mov one,few

They lost for one reason, and one reason only. IBM chose to base the PC
architecture on Intel.

Mike S wrote:

Blaming intel for an assembler language construct that had been in common
usage for 30 years is unreasonable.  They were just conforming to a style
that programmers already understood.  If you didn't like it, it was trivial
to change even in the earliest intel 8080 assemblers.

I cannot find any reference for the Pascal connection, so it is likely
that I am misremembering something.  It does seem a bit odd, in face of
the fact that intel never even produced a Pascal compiler, that they would
have even thought of Pascal when designing the 8086.

I will go with the thought that the 8086 was a 16 bit machine, and as such
directly addressed 64K.  The different segment registers allowed it to
be maximally relocatable within a 20 bit address space.

In this regard, it was exactly like the old DEC PDP-11/74.  It too was a 16 bit
machine, and could only directly address 64K.  It too had a 64K I, and a 64K D
space.  It was not a 32 bit machine in any way shape or form.

The 8086 was clearly designed with compilers in mind, evidenced by the heavy
support of stack frames.

Sorry, but that is not so.  The 68000 was a 16 bit machine, both internally, and
externally, with 32 bit registers and some 32 bit instructions.

Here is a wiki quote:

"The 68000 grew out of the MACSS (Motorola Advanced Computer System on Silicon) project, begun in 1976 to develop an
entirely new architecture without backward compatibility. It would be a higher-power sibling complementing the existing
8-bit 6800 line rather than a compatible successor. In the end, the 68000 did retain a bus protocol compatibility mode
for existing 6800 peripheral devices, and a version with an 8-bit data bus was produced. However, the designers mainly
focused on the future, or forward compatibility, which gave the M68K platform a head start against later 32-bit
instruction set architectures. For instance, the CPU registers are 32 bits wide, though few self-contained structures in
the processor itself operate on 32 bits at a time. The 68000 may be considered a 16-bit microprocessor which is
microcoded to accelerate 32-bit tasks. The MACSS team drew heavily on the influence of minicomputer processor design,
such as the PDP-11 and VAX systems, which were similarly microcoded."

It wasn't until 1984, with the 68020, that Motorola made a 32 bit microprocessor.
Here is a wiki quote:

"The 68020 added many improvements to the 68010 including a 32-bit arithmetic logic unit (ALU), external data bus and
address bus, and new instructions and addressing modes. The 68020 (and 68030) had a proper three-stage pipeline."

Sorry, not so, again wiki:

"The original MC68000 was fabricated using an HMOS process with a 3.5-micron feature size. Initial engineering samples
were released in late 1979. Production chips were available in 1980,"

and again wiki:

"The 8086[1] is a 16-bit microprocessor chip designed by Intel and introduced on the market in 1978,"

I realize that "introduced on the market" is a nebulous term, but having
lived through the the introduction in 1978, I can tell you that intel was
well beyond samples at that time.

IBM's website:

"Next came the 8088, the processor for the first IBM PC. Even though IBM engineers at the time wanted to use the
Motorola 68000 in the PC, the company already had the rights to produce the 8086 line (by trading rights to Intel for
its bubble memory) and it could use modified 8085-type components (and 68000-style components were much more scarce)."

That gave IBM two things they desperately needed, one, the ability to
second source the parts, if necessary, and two, the ability to use available
parts in the design.  The 68000 was a pipe dream as far as peripheral parts
went when the PC was being designed.

It is interesting to muse over how different things might have been had IBM
waited a couple of years for the 68000 to be usable, instead of settling for
the 8088.

Anyway, that is enough from me on this side track.  Back to favorite
microcontroller modules.

-Chuck Harris

Hi Didier,
.., I can use a pin that ordinarily

It's sort of funny, 20 years ago, I was flush with emulators, and used them
for most of my development.  The had their place back then, as my projects
were spiraling out of control in terms of complexity.

Now, I just do PICS, and don't need such things.  I can debug most effectively
with either simple diagnostic messages, or a scope.

I don't miss how code that would work with the emulator bombed without the
emulator ... and vice versa.

Now that I am used to the full debug

PIC's will do the same thing.  I just haven't had the need to yet.

True, they have made a number of wins.

I tried to learn the HC10, but I could find no compelling reason to learn
yet another processor.

I have one around here someplace.  I was frustrated because I couldn't get it
to work under linux and wine.  CCS has a native linux compiler, and their windows
compiler works nicely under wine.  I am having some trouble with Microchip's
programmer under the current wine release, but it has worked in the past, I'll
get it working again.

Your server seems to be down right now.

-Chuck Harris

At 10:17 AM 2/21/2008, Chuck Harris wrote...

Your Intel bias is really showing now. Enough with trying to change the
subject. The discussion was in regard to architecture, not
implementation.

Your original claim was "It would have been impossible for intel to put
a 32 bit bus and register set on a processor like the 8086 back in
1978." That was in support of Intel's segmented memory architecture.

That claim is disproved by the fact that the 68000, which first shipped
in 1979, had a 32 bit architecture. That the first implementation
didn't bring everything at once is beside the point. The programming
model was 32 bit, which very significantly distinguishes it from the
8086 architecture. Perhaps you want to call the 8088 an 8 bit
processor?

8086: 16 bit registers, 16 bit data bus, 16 bit addressing with
segmentation extensions.
8088: 16 bit registers, 16/8 bit data bus, 16 bit addressing with
segmentation extensions.
68000: 32 bit registers, 32/16 bit data bus, 32/24 bit linear
addressing.
68008: 32 bit registers, 32/8 bit data bus, 32/20-22 bit linear
addressing.
(architecture/physical implementation)

Mike S wrote:

But not a 32 bit bus (as you have quoted me (above) saying was impossible).
The parallel bus structure, with all of its attending registers, ALU's, and
wiring is what was beyond Intel, and Motorola in 1978 and 1979.  They just
couldn't make a die that big, and meet the needed reliability, heat removal,
and cost requirements of a successful commercial processor.

You have my words right there, but for some reason you felt the need to
misrepresent them.

I liked programming on Motorola 68020's.  It was easy, and I never felt
like I had to work at all to solve a problem.  But at the same time, it
was glacially slow.  We got significantly better performance with the same
programs running under the 386 and 486 processors of the day.  The compilers
made smaller code for the intel processors than they did for the Motorola,
and the Motorola lost all of the benchmarks we ran.  We were undoubtedly
running the wrong benchmarks, and using the wrong compilers, but they were
representative of what we needed done.

That the first implementation

No, I would call it a mistake, but that is just me.  I put a number of
8086's in designs, but never an 8088.  I used fast Z80's instead.  One
of my all time favorite embedded intel processors was the 80C186.  It was
powerful, small, and easy to integrate into designs.

...

-Chuck Harris