another bizarre architecture
in [Embedded]
|
From: John Devereux on 2 Feb 2007 13:38 John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> writes: > On Thu, 01 Feb 2007 22:50:35 +0000, John Devereux > <jdREMOVE(a)THISdevereux.me.uk> wrote: > >>John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> writes: >> >>> On Thu, 01 Feb 2007 19:10:42 +0000, John Devereux >>> <jdREMOVE(a)THISdevereux.me.uk> wrote: >>> >>>> >>>>You do realise that this is an implementation of the C standard >>>>library? The behaviour of the functions is spelled out, in detail, in >>>>the C standard, and any number of C reference books and online >>>>references. >>> >>> Suppose it turns out to have a bug. There's no indication of a >>> revision level, so every time you want to use this implementation you >>> have to (or certainly should) add your own comments as to where you >>> found it and when. And if a bug is ever found, will the one on the web >>> just change, so that you'd have to check every character against the >>> old one to see if anything has changed? >> >>You use a version control system. A library like this would be >>maintained and released as a unit, i.e. there will be an overall >>version number like e.g libc 2.1. >> >>Using a version control system it is easy to see exactly what has >>changed between revisions, anywhere in the library. This saves having >>to examine each file individually to see if its version number has >>changed. > > If your vc system tells you that two subroutine sources differ, what > do you do? It certainly can't tell you *why* they differ, or how they > might behave differently. Yes it can. The source files contains comments describing them. A diff performed on two copies of the library will show exactly the differences in the comments, as well as in the code. > For that, you must either read the comments > and revision notes (lots of luck finding them!) or compare the code > character-by-character and try to figure out what's going on. Or just > use the latest one, on the assumption that any bugs aren't your fault. Comments are in the source file. > Now, what do you do when 12 versions differ? You can run a "diff" command on the whole library, or on any subset thereof, to show all the differences between any version and any other. The Changelog will also contain comments saying what changed and why. >>If you really want to you could use the version control system to >>automatically insert a comment with the file version number, but I >>think this is not used much these days. At least I don't; it clutters >>up the file. > > Yes, comments are nasty things. Of course I comment the source code - I was just making the point that you don't always want some "version" number written as a comment in the C source file. There can be better ways to handle revision control than typing a number into each source file. -- John Devereux
From: Rich Grise on 2 Feb 2007 13:55 On Fri, 02 Feb 2007 08:26:47 -0800, John Larkin wrote: > On Fri, 02 Feb 2007 15:13:53 GMT, Vladimir Vassilevsky >>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. > Apparently so. Did you miss the part where he expressed his desire to be a member of the MS crew? Given his post, I'd sure never hire the guy. "However not checking the return code is the very common mistake. The exception mechanism was invented to prevent this sort of mistakes." No, Vladimir. Learning how to program properly was invented to prevent this sort of mistakes[SIC]. "Exceptions" just add another level of bloat to protect scriptkiddies from their ignorance. And who's to say the guy who wrote the exception routines wasn't just as sloppy of a "programmer" as the idiot who's depending on the machine to do his thinking for him? Thanks, Rich
From: jasen on 2 Feb 2007 13:34 On 2007-02-01, Vladimir Vassilevsky <antispam_bogus(a)hotmail.com> wrote: > What a shamefull nonportable, unsafe and murky piece of code. at least it's C. > This is a way to go: not in C it's not. Bye. Jasen
From: CBFalconer on 2 Feb 2007 12:58 Vladimir Vassilevsky wrote: > John Larkin wrote: > .... snip ... >> >> One of my best customers makes jet engines. The engine control >> computers are mounted under the engine cowling, in the airstream, >> and the engine fuel runs through the computer before being burned, >> to moderate the CPU's temperature swing. The programs have no bugs, >> because they are careful, > > What a bullshit. > > If you take a closer look to those systems, you will find the same > pile of lousy code as everywhere. Well, it is more or less tested > so the major bugs are unlikely. > If you *really* know how the car or the aircraft is build, you will > never drive it or fly by it. The code may or may not be lousy, in terms of clarity and maintainability. However, it will not be buggy. You are obviously unfamiliar with what it takes to get instrumentation certified for airworthiness. The specifications may have been foolish (i.e. the Airbus fiasco). -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> "A man who is right every time is not likely to do very much." -- Francis Crick, co-discover of DNA "There is nothing more amazing than stupidity in action." -- Thomas Matthews
From: Nico Coesel on 2 Feb 2007 14:53
John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >This looks really weird to me... > >http://www.maxim-ic.com/appnotes.cfm/appnote_number/3960 > >Does it resemble anything you've ever seen? It looks truly ghastly to >program. For example, allowing printf() to use floats adds 3500 bytes >to a program binary. It looks like yet-another-risc-processor which doesn't program well using c . Where other players in the field (like TI) discovered programming a risc processor takes a lot of code to do something. The MSP430 series is extremely efficient when it comes to code size. -- Reply to nico(a)nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nl |