another bizarre architecture

[Ben Jackson]

So-called 'Computer science' isn't.

Computer programming is a LOT like science. You form a hypothesis about
why your program doesn't work, then you do an experiment to test your
theory. Software *engineering* isn't.

 

[joseph2k]

Hardware will fail quite often due to radiation, EMC problems, UPS
failure or simply capacitor "rot".


I try to write my software so that it wont't fail until I am retired.


You have memory leak problems only if you use deallocators .

A program can use allocators at startup, but should avoid them during
the next decades the program is running.

Paul

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

 

[PeteS]

Why have the people in this thread been so
belligerent? Most of us in this group (c.a.e) can
remain civil in spite of our disagreements.

In this case CBF was simply making a point,
not insulting anyone.

Some are deliberately belligerent, perhaps.

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

Cheers

PeteS

 

[jasen]

You are wrong, and I posted an example, here it is again:

Yes I was. sorry.

 

[David Brown]

So, you will actually release software that you know is buggy, or that
you haven't tested, because of some schedule? Please tell me who you
work for, so I can be sure to never buy their stuff.

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.

 

[David Brown]

["Followup-To:" header set to sci.electronics.design.]

Yup. Freescale would like to kill it, but there are enough users that
they can't.

That's seomthing I'll never understand. Why would they want to kill it?
Everything's just there; all they have to do is just make the damn things.
It doesn't cost them a bit, so why stop?

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.

 

[David Brown]

John Devereux wrote:
... snip ...

Look at the documentation for your version control system. There
is almost certainly a way of automatically updating a version
comment when the source is checked in. No pain whatsoever.

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.

http://subversion.tigris.org/faq.html#version-value-in-source
http://subversion.tigris.org/faq.html#log-in-source

 

[Rich Grise]

Indeed, especially since some people have been known to produce
functions that look like the standard functions but are either
incomplete or behave slightly differently. (maybe we can call those
homonym functions?)

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

 

[Rich Grise]

On a sunny day (Sat, 3 Feb 2007 17:54:47 -0500) it happened Robert Adsett


You are partly right in my view.
If I buy a book in English (I am Dutch), can I require that plent of Ducth lines
are inserted so I can read it if my English is broken?

If you are going to do some reading of C files, do you not think you should _AT_LEAST_
be able to read the language fluently?
Even more when writing in C.
C, written in the right way, other then if cryptic use of variables and functions in made,
is very readable.
I have worked myself throught tons of sourcefiles that had zero comments, something you
learn when using open source.....
Sometimes comments just distract.

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

 

[Vladimir Vassilevsky]

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.

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

http://www.abvolt.com

 

[krw]

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

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.

 

[Vladimir Vassilevsky]

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.

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

 

[krw]

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.

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

 

[John Larkin]

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

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

 

[Rich Grise]

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.

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

 

[Rich Grise]

On Mon, 05 Feb 2007 18:32:28 GMT, Vladimir Vassilevsky


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

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

Cheers!
Rich

 

[Mark Borgerson]

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

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

 

[Ken Smith]

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

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.

 

[John Larkin]

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

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

 

[John Larkin]

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

Sorry, there's no demand.

John