another bizarre architecture
in [Embedded]
|
From: PeteS on 4 Feb 2007 16:08 Robert Adsett wrote: > In article <1170585110.650611.149170(a)q2g2000cwa.googlegroups.com>, Didi > says... >> On Feb 4, 3:37 am, John Larkin >> <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >>> The very act of commenting forces a programmer to explain the program >>> to himself, sometimes with novel results. >> 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 > 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
From: joseph2k on 4 Feb 2007 17:56 Paul Keinanen wrote: > On Fri, 02 Feb 2007 12:26:59 -0800, John Larkin > <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>But it's seldom the CPU or the memory that fails; > > Hardware will fail quite often due to radiation, EMC problems, UPS > failure or simply capacitor "rot". > >>it's the software itself. > > I try to write my software so that it wont't fail until I am retired. > >>Memories don't leak, but memory allocators/deallocators do. > > 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 -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens. --Schiller
From: PeteS on 4 Feb 2007 17:59 Michael N. Moran wrote: > Jan Panteltje wrote: >> 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. > Some are deliberately belligerent, perhaps. I like to think we can disagree professionally (although vehemently). Cheers PeteS
From: jasen on 5 Feb 2007 01:36 On 2007-02-04, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >>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: Yes I was. sorry. -- Bye. Jasen
From: David Brown on 5 Feb 2007 03:45
John Larkin wrote: > On Fri, 02 Feb 2007 15:13:53 GMT, Vladimir Vassilevsky > <antispam_bogus(a)hotmail.com> wrote: > >> >> Jan Panteltje wrote: >> >> >>>> It is better to stay on the earth rather then fall on somebody's head. >>>> Masking the errors is the worst practice. >>> >>> Yes that is true. >>> But you have to try one day to fly.... Errors will show you where to improve. >> Deadlines. That's another reason for the software to be the far from >> perfect. > > > 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. |