another bizarre architecture

That can be made to work well in embedded systems, i have seen them that do it that way, i have even written some very small ones. It does not work well when there are a multitude of programs that run frequently to rarely in response to any of several users discretion. YMMV

--
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller

Some are deliberately belligerent, perhaps.

I like to think we can disagree professionally (although vehemently).

Cheers

PeteS

Yes I was. sorry.

--

Bye.
   Jasen

John, this is comp.arch.embedded - the answer is *always* "it depends". For some products, it is vital to hit the schedule - even if there are known bugs or problems. Perhaps you ship the hardware now, and upgrade the software later - perhaps you ship the whole thing even with its outstanding problems. For other products, you have to set the highest possible standards, and quality cannot be lowered for any purpose. I have no idea what sort of systems VV works with - they could well be of the sort where issues such as cost and timing are more important than quality and reliability.

It's a production issue (as far as I understand the situation). The MC68332, like many older designs, is made using a large process and can't easily be scaled. Newer fabs are incapable of producing large process devices, so Freescale has to keep older production lines running to keep making these sorts of devices. So while they can make an MCF5235 on any modern line, the MC68332 can only be produced on a few (or maybe just the one) old line, at higher cost (being physically bigger). Modern cores like the ColdFire are synthesisable, so moving to a newer process is basically a matter of re-compiling the design source code and re-qualifying the electrical characteristics - moving the MCF68332 to a new process would involve far more work.

That is a "feature" supported by some version control systems, and not others - and it is debatable whether it is a good thing. Some people like it, others think the job of the version control system is to provide safe and reliable storage for different versions of your code, not to modify it on the fly.

In C++, that's called "Overloading".

If John thinks plain ol' C is "ugly", we should protect him from ever seeing any C++ - He'd get apoplexy! ;-)

I disagree that C is "ugly", but as they say, "de gustibus non disputandum est." (no accounting for taste.) :-)

But, even though there are uglier languages, I can see John's point - from a hardware/assembly-level guy's POV, the 68xxx have always been very pleasant to work with. I don't know exactly where it goes on the "prettiness" scale, however. :-)

Cheers! Rich

lines

_AT_LEAST_

functions in made,

something you

The worst are comments that don't tell you anything, usually caused by some supervisor ordering a bunch of code grunts, "Your code WILL be commented!" and you get this:

LABEL1: MOV BP,SP ; move the contents of the stack pointer to the base ; pointer register

Another major complaint I've heard is about "programmers" who comment in jive.

And so on. I'm sure you get the point. :-)

Cheers! Rich

I have seen the comments like "I don't know why, but this variable should be set to 1, otherwise it doesn't work..."

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

A very useful comment. It tells me that someone doing maintenance on this code didn't know his ass from a hole in the ground. As such, the entire procedure should be treated as suspect.

--
  Keith

No. This kind of comment typically happens when a programmer is supposed to initialize a hardware device. What he does he grabs an appnote and copy-pastes the code from there. Once it works, it is nobody's care.

VLV

Ok, the original programmer didn't know his ass from a hole in the ground. As such, the entire program is suspect.

--
  Keith

That seems like a very valuable comment to me. It alerts future programmers that there may be a problem somewhere. Even worse would be if the situation went undocumented.

We sometimes write a comment like "this chip seems to need a wait after loading the control register. 1 millisecond seems to work, so we used three just for luck."

John

DEFINE DEBUGGING 1

... ; code

#IFDEF DEBUGGING ; this is supposed to be set to one. If not, there's an error here ; that needs to be trapped #ELSE ; this variable will have been set to one by the calling routine. It's ; used for ..... #ENDIF

Cheers! Rich

So, when's the book, "How To Write Understandable and Maintainable Code" coming out? ;-)

Cheers! Rich

With the number of mistakes in that example (no '#' before DEFINE, mixup of constants and variables, etc.), I hope it was intended as a humorous example!

Mark Borgerson

In article , Rich Grise wrote: [....]

Many years ago, a friend of mine made a nice little joke program. You could feed uncommented code into it and it would produce code with very nice comments. It would look at two instructions and look up phrases based on them and the random number generator. You knew you were in trouble when they seemed to be making sense.

--
--
kensmith@rahul.net   forging knowledge

The PDP-11 was stunningly beautiful in its cleanliness and symmetry. The preferred radix was octal, and the instruction set and addressing modes fit perfectly into octal digits. I can still assemble a bit from memory...

123722 = add byte, source absolute address, destination indirect register 2, autoincrement

Its instruction set was the basis for C. 68K has more registers and is a 32-bit machine, but is less orthogonal and nothing you can easily assemble from memory. Only its MOVE instruction has the source/destination symmetry that nearly all PDP-11 opcodes had.

John

Sorry, there's no demand.

John