Maker Pro
Maker Pro

another bizarre architecture

R

Robert Adsett

John Larkin said:
This is a snip from an embedded product program, a combination
thermocouple temperature controller and NMR gradient driver. This is a
sort of printf function.

The program was done in a couple of weeks calendar time, released as
rev A, and has been in production for about a year. There are no bugs.
A bit over 4K lines of assembly. It's an absolute, monolithic assembly
of a single source file, no libs, includes, or linkers involved.

The .SBTTL directive create an entry in the listing's table of
contents.




.SBTTL . MAKE A FORMATTED ASCII NUMERIC STRING.

; THIS IS A NON-REENTRANT VERSION, WHEREIN WE BUILD THE
; DESIRED STRING IN THE 'J0..J7' BUFFER AREA. ON ENTRY...
;
; D5 CONTAINS UNSIGNED, RANGE-CHECKED 32-BIT VALUE
; JM HOLDS SIGN CHARACTER, USER'S OPTION
; D4 CONTAINS 'FORMAT' IN RANGE 0...5: THIS IS HOW MANY
; DIGITS APPEAR TO THE RIGHT OF THE DECIMAL.
; A3 IS POINTER TO 8-BYTE OUTPUT STRING
;
; 12345 FORMAT 0 IS ' 12345'
; -98765 FORMAT 3 IS ' -98.765'


BASS: MOVEA.W # J7+1, A5 ; AIM AT *END* OF STRING
MOVE.L D5, D0 ; COPY OUR NUMERIC INPUT
MOVE.B # " ", J0.W ; POKE A NECESSARY SPACE
MOVE.L # 10, D1 ; AND NAME A POPULAR RADIX

Now that's more like it. There's no reason the original example
couldn't have been done that well. It just take a certain amount of
self discipline and pride in your work.

Robert
 
P

PeteS

Robert said:
I'm not saying you are. Just that the commenting in the example John
was given was poor. Unfortunately it appears the other examples on the
same site are worse. Not much wonder John dislikes C if that's what
he's got to go on.

Robert

Poor discipline is the bane of the industry, and I must agree with John
on this, even though I prefer to write in C.

#include <rant.h>
I have spoken with many a programmer unworthy of the name if only
because they think hardware is something that automagically does what
they need; it's the product of a great deal of hard disciplined work!

In this, incidentally, I include those who are software engineers and
computer scientists (I have yet to divine the distinction).

#undef rant

Discipline is something foreign to many software engineers (but not all,
as I can attest from personal knowledge) and is necessary if a product
is to be successful.

So the answer seems to be; a disciplined approach is likely to produce
successful results. Duh.

Cheers

PeteS
 
J

jasen

["Followup-To:" header set to sci.electronics.design.]
On a sunny day (Thu, 01 Feb 2007 21:24:37 GMT) it happened Vladimir
<[email protected]>:

FILE *fptr;

fptr = fopen("filename", "r");

fread( fptr...)
BANG if file did not exist!

It's easy to post bad code, how would you fix it?

You check the return value and look at errno.
Read the rest of the thread (and libc.info, but I know you did read that).

there's no bad consequence from doing fread() on a FILE* that
may be NULL. The real problem is ignoring the return from fread,
suppose the file is too short for instance.

Bye.
Jasen
 
J

John Larkin

So what? Comments aren't executed.

Source code isn't executed, either. A computer program is an interface
between a human programmer and two destinations: downward, to the
instruction set of a CPU: upward, to the author himself and to other
programmers who need to understand, now and in the future, what is
being done and why. The code tells what is being done, and the
comments tell why.

The very act of commenting forces a programmer to explain the program
to himself, sometimes with novel results.

It's shocking how many programmers and CS teachers don't understand
this, or do and can't be bothered.

Skipping comments is reasonable if what's going on is totally obvious,
like a nicely-contained Linux file operation. But an embedded systen
connects to real-world hardware external to the cozy world of computer
languages and operating systems, so some context can be mighty
helpful.

I'm not saying you are. Just that the commenting in the example John
was given was poor. Unfortunately it appears the other examples on the
same site are worse. Not much wonder John dislikes C if that's what
he's got to go on.

I dislike the language because I think it's ugly, but that's a
personal affectation. I dislike the culture of C because it so often
creates crap products. Fortunately, roughly half of C code, the really
bad stuff, never makes it to the street; the projects, or the
companies, fail.

John
 
R

Robert Adsett

John Larkin said:
Source code isn't executed, either.

You're right although I was referring to the larger sense in which
source code does describe the instructions to the micro wheras comments
are solely for human consumption :)
A computer program is an interface
between a human programmer and two destinations: downward, to the
instruction set of a CPU: upward, to the author himself and to other
programmers who need to understand, now and in the future, what is
being done and why. The code tells what is being done, and the
comments tell why.

The very act of commenting forces a programmer to explain the program
to himself, sometimes with novel results.

It's shocking how many programmers and CS teachers don't understand
this, or do and can't be bothered.

Those with a CS inheritance aren't the only ones, just the ones with the
least excuse.
Skipping comments is reasonable if what's going on is totally obvious,
like a nicely-contained Linux file operation.

I'm not sure I completely agree. The commenting can be a lot lighter
though if you can refer to a well defined definition. As you can for
much of the standard library.
But an embedded systen
connects to real-world hardware external to the cozy world of computer
languages and operating systems, so some context can be mighty
helpful.

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?)
I dislike the language because I think it's ugly, but that's a
personal affectation. I dislike the culture of C because it so often
creates crap products. Fortunately, roughly half of C code, the really
bad stuff, never makes it to the street; the projects, or the
companies, fail.

I can't fault you for the results reasoning although I suspect that has
as much or more to do with it's popularity than anything inherit in it.
I've seen similar with C++ and Java at the very least.

Robert
 
J

Jan Panteltje

there's no bad consequence from doing fread() on a FILE* that
may be NULL. The real problem is ignoring the return from fread,
suppose the file is too short for instance.

Bye.
Jasen

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

#include <stdio.h>
#include <stdlib.h>

main()
{
FILE *fptr = 0;
char buffer[100];
size_t bytes_read;

fptr = fopen ("flipflap", "r");

// size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);
bytes_read = fread(buffer, sizeof(char), 100, fptr);

fprintf(stderr, "bytes_read=%d\n", (int)bytes_read);
}

gcc version 4.0.3 20060104 (prerelease) (Debian 4.0.2-6
grml: ~ # gcc -o test3 test3.c
grml: ~ # ./test3
zsh: segmentation fault ./test3


Use brain.
 
J

Jan Panteltje

I'm not saying you are. Just that the commenting in the example John
was given was poor. Unfortunately it appears the other examples on the
same site are worse. Not much wonder John dislikes C if that's what
he's got to go on.

Robert

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 reliability of teranews (I once payed for lifetime access to it) is such that I
stay clear of it.
 
P

PeteS

It's no illusion that professional hardware design consistantly
produces solid products and that professional software design often
produces bloated, buggy crap. As I said, I use hardware disclipines to
produce code, and that code inherits the simplicity and reliability of
the discipline.

Software should be *more* reliable than hardware, since software has
no inherent failure modes, isn't subject to temperature changes, power
glitches, parts variability or EMI, and is precisely reproducable
times a million copies... no solder joints, no part tolerances. Yet
it's the hardware that's usually most reliable. Software is buggy
because of miserable programming methodologies and practices. Mine's
not.

This is sad: FPGA design, these days, is dominated with struggling
with the software tools, trying to get the compilers to grudgingly
agree to do what you know you want done on-chip, and then trying to
get the compilers to run to completion without crashing. See
comp.arch.fpga: it's mostly about struggling against the tools. The
FPGAs themselves - the hardware - work fine. Xilinx 9.1 is just out -
a 1.5 gig download - and SP1 is already out, another gigabyte. I
wonder if they've fixed any of the memory leaks.

John

Interesting article about a book covering much of this very subject at Salon

http://www.salon.com/books/int/2007/02/03/leonard/

Cheers

PeteS
 
R

Robert Adsett

Didi said:
I did not realize this was not a common truth/practice for all
programmers
nowadays until not so long ago...

Sorry to have disillusioned you :)
Not that one cannot comment each line (or few characters...) in C,
Basic or whatever, but HLLs are designed following a "no comment
necessary" ideology, which is a major weakness they all have.

While people do work that way, I don't think any HLLs have been designed
that way.
Obviously trying to communicate a software project without using
English is doomed; so people do use some minimized comments,
which results in minimized code quality.

Well, I think maybe English is necessary if you are communicating with
English readers ;)
Other than in HLLs, writing comments using 68k (and perhaps some
others in this particular context) assembler is a de facto part
of the language, not a result of discipline.

Now her I'll disagree. I've certainly seen uncommented and poorly
commented assembly code. No assembler I've seen encouraged comments any
more than most HLLs.

The prevalance of commenting, especially meaningful commenting, appears
to have to do far more with the people writing the code than the
language they are using to write it. The exception might be graphical
languages which in my limited experience do not seem to have developed
clear commenting techniques.

Robert
 
J

Jan Panteltje

there's no bad consequence from doing fread() on a FILE* that
may be NULL. The real problem is ignoring the return from fread,
suppose the file is too short for instance.

Bye.
Jasen

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

PS,
you are probably confused with 'read()', read() accepts a fileno,
an integer, and if zero reads from stdin.

So this will always read from stdin:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

main()
{
char buffer[100];
size_t bytes_read;

bytes_read = read(0, buffer, 100);

fprintf(stderr, "bytes_read=%d\n", (int)bytes_read);
}

grml: ~ # gcc -o test3 test3.c
grml: ~ # ./test3
asfweaswerwerwerwerwerw
bytes_read=24

In case of read() there is an other problem, that the higher level 'fread()'
protected us from, and a frequent make mistake is not to call read() again if
it returns EAGAIN (and lose data), from libc.info:

- Function: ssize_t read (int FILEDES, void *BUFFER, size_t SIZE)
The ead' function reads up to SIZE bytes from the file with
descriptor FILEDES, storing the results in the BUFFER. (This is
not necessarily a character string, and no terminating null
character is added.)

The return value is the number of bytes actually read. This might
be less than SIZE; for example, if there aren't that many bytes
left in the file or if there aren't that many bytes immediately
available. The exact behavior depends on what kind of file it is.
Note that reading less than SIZE bytes is not an error.

A value of zero indicates end-of-file (except if the value of the
SIZE argument is also zero). This is not considered an error. If
you keep calling ead' while at end-of-file, it will keep
returning zero and doing nothing else.

If ead' returns at least one character, there is no way you can
tell whether end-of-file was reached. But if you did reach the
end, the next read will return zero.

In case of an error, ead' returns -1. The following rrno'
error conditions are defined for this function:

AGAIN'
Normally, when no input is immediately available, ead'
waits for some input. But if the NONBLOCK' flag is set
for the file (*note File Status Flags::), ead' returns
immediately without reading any data, and reports this error.

*Compatibility Note:* Most versions of BSD Unix use a
different error code for this: WOULDBLOCK'. In the GNU
library, WOULDBLOCK' is an alias for AGAIN', so it
doesn't matter which name you use.

On some systems, reading a large amount of data from a
kernel cannot find enough physical memory to lock down the
user's pages. This is limited to devices that transfer with
direct memory access into the user's memory, which means it
does not include terminals, since they always use separate
buffers inside the kernel. This problem never happens in the
GNU system.

Any condition that could result in AGAIN' can instead
result in a successful ead' which returns fewer bytes than
requested. Calling ead' again immediately would result in
AGAIN'.

BADF'
The FILEDES argument is not a valid file descriptor, or is
not open for reading.

INTR'
ead' was interrupted by a signal while it was waiting for
input. *Note Interrupted Primitives::. A signal will not
necessary cause ead' to return INTR'; it may instead
result in a successful ead' which returns fewer bytes than
requested.

IO'
For many devices, and for disk files, this error code
indicates a hardware error.

IO' also occurs when a background process tries to read
from the controlling terminal, and the normal action of
stopping the process by sending it a IGTTIN' signal isn't
working. This might happen if the signal is being blocked or
ignored, or because the process group is orphaned. *Note Job
Control::, for more information about job control, and *Note
Signal Handling::, for information about signals.

Please note that there is no function named ead64'. This is not
necessary since this function does not directly modify or handle
the possibly wide file offset. Since the kernel handles this state
internally, the ead' function can be used for all cases.

This function is a cancellation point in multi-threaded programs.
This is a problem if the thread allocates some resources (like
memory, file descriptors, semaphores or whatever) at the time
ead' is called. If the thread gets cancelled these resources
stay allocated until the program ends. To avoid this, calls to
ead' should be protected using cancellation handlers.

The ead' function is the underlying primitive for all of the
functions that read from streams, such as getc'.

This is a bit out of context for these newsgroups, and more for
comp dot os dot linux dot development dot apps and related.
 
M

Michael N. Moran

Jan said:
Take your pills

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.

--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org

"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
 
P

PeteS

Andy said:
Its primary disadvantage is that it's a Maxim part so forget about any
support, or being able to order less than a fab-run, or ...

-a

Shades of an earlier thread ;)

Maxim is still fighting that, and unsuccessfully it seems. We look at
actions, not PR spin, of course. If it's still being discussed this way
then Maxim still hasn't mended it's ways, obviously.

Cheers

PeteS
 
P

PeteS

John said:
Thanks for the ref: I just ordered a copy.

This is profound:

"Programmers are programmers because they like to code"

That goes a long ways towards explaining the problem.

John

So true.

I have ordered a copy as well.

Perhaps this explains much of the difference; hardware designers like to
design, but due to the discipline forced upon us by the task, we ojnly
design new subsystems *when we must*.

When we need a function that already exists (whether from elsewhere or
our own library) , there has to be a compelling reason not to use it, in
contrast with the comment above where programmers will re-invent it
almost every time with all the attendant issues of something new.

Cheers

PeteS
 
P

PeteS

John said:
["Followup-To:" header set to sci.electronics.design.]
John said:
I'll typically spend about 1-2 man-weeks on an embedded product
program, generally around 4-6 klines of code, from start to formal
release of bug-free code.
But these are very small projects, in software terms. Any half-decent
programmer can do that, no matter in what language. It's the huge,
millions-of-lines codebases that break.

Well, this is sci.electronics.design, not some Windows app group. But
I do see people using C++ class structures to set a bit in a parallel
port, in the name of abstraction. Why would an embedded programmer
seek abstraction, other than they don't actually like programming
hardware?

But of course the big projects break; just look at the undocumented,
uncommented, barely-tested, tangled messes they call subroutines.
Nobody can build a reliable big system from the sorts of junk modules
I see. The failures are wired into the culture.

I once wrote (as an external contractor) a module for an intranet
application. The CTO of my customer really wanted me to use Java just
because it was "that's what eveybody uses these days". But since they
couldn't find anybody else (those were dot-com boom days) they had to make
do with the guy who used a language they'd never heard of -- C.

Last thing I knew was that their application never really got going, except
for my bit which worked 100% right from the start.

I remember those panicky calls I got from them: "There's a bug in your
module". Panicking myself I rushed into their office, only to see that
--again!-- they had fed invalid data into my module. This was easily
demonstrated because it had been *me* who wrote all the specs. Billed them
big bucks for that wasted time. Now they are broke.

robert

Bad programming has killed a lot of companies, and a lot of people. We
are living in the dark ages of a mess they like to call "computer
science." The existing orthodoxy, most of the time, works poorly or
not at all.

John

So-called 'Computer science' isn't.

Just my opinion, of course

Cheers

PeteS
 
P

PeteS

Robert said:
Sorry to have disillusioned you :)


While people do work that way, I don't think any HLLs have been designed
that way.

Well, I think maybe English is necessary if you are communicating with
English readers ;)


Now her I'll disagree. I've certainly seen uncommented and poorly
commented assembly code. No assembler I've seen encouraged comments any
more than most HLLs.

The prevalance of commenting, especially meaningful commenting, appears
to have to do far more with the people writing the code than the
language they are using to write it. The exception might be graphical
languages which in my limited experience do not seem to have developed
clear commenting techniques.

Robert

Commenting code *properly* requires a certain discipline. I comment my
code as accurately as possible (and reference the original requirement
if possible) for many reasons, not least when I go back to it in 6-12
months and wonder why the F*** I did something.

Proper comments in code are a requirement for proper development just as
proper documentation in hardware design is necessary.

The fact that many lack discipline in no way changes the requirement.

Cheers

PeteS
 
J

John Larkin

So true.

I have ordered a copy as well.

Perhaps this explains much of the difference; hardware designers like to
design, but due to the discipline forced upon us by the task, we ojnly
design new subsystems *when we must*.

And because of the cost and turnaround time of an assembly, we check
our work carefully before we commit it to copper. Software, because it
can be changed in minutes, without making pads fall off boards,
usually doesn't get checked at all before it's run. So the bugs you
fix are the bugs you find.
When we need a function that already exists (whether from elsewhere or
our own library) , there has to be a compelling reason not to use it, in
contrast with the comment above where programmers will re-invent it
almost every time with all the attendant issues of something new.

I like to design new circuits, but that increases the obligation to
check/breadboard/simulate them before commiting them to layout.

John
 
J

joseph2k

jasen said:
["Followup-To:" header set to sci.electronics.design.]
On a sunny day (Thu, 01 Feb 2007 21:24:37 GMT) it happened Vladimir
<[email protected]>:

FILE *fptr;

fptr = fopen("filename", "r");

fread( fptr...)
BANG if file did not exist!

It's easy to post bad code, how would you fix it?
You must be programming for Microsoft :-(

seriously, checking for equal to zero is pointless,

The number could be so close to zero that it would have pracctically the
same result as dividing by zero (the only difference is you get
"infinite" as a result instead of "not a number")

double d = 1.2 - 0.4 - 0.4 - 0.4;

d is a small number, but, quite possibly, not 0.

Bye.
Jasen

You are embarrassing yourself by not recognizing the difference between
pointer (an integer type, where zero / nil is zero / nil and no
approximation occurs) and the floating point type (where representation
truncation based approximation does occur).
 
P

PeteS

John said:
And because of the cost and turnaround time of an assembly, we check
our work carefully before we commit it to copper. Software, because it
can be changed in minutes, without making pads fall off boards,
usually doesn't get checked at all before it's run. So the bugs you
fix are the bugs you find.


Precisely. Rather than finding the bugs that exist.

I like to design new circuits, but that increases the obligation to
check/breadboard/simulate them before commiting them to layout.

John


I love to design new things, but I must minimise risk as must you. So I
design the new stuff (and have great fun doing it) while re-using as
much as I can for the boring 'already done this' stuff.

This might need to be a new thread: Why hardware designers have more
discipline and fewer bugs.

Cheers

PeteS
 
Top