Reply by Jerry Avins July 28, 20032003-07-28
Andor wrote:
> > Jerry Avins wrote: > ... > > > There are many criteria by which to measure code quality: execution > > > speed, memory requirement, upgradeability, modifiability, > > > reuasability, development speed, portability, etc. > ... > > I'd like to see, or hear of anecdotally, an optimal embedded system > > written in complete ignorance of the hardware it is to run on. > > Jerry, > > you did not read what I wrote. An optimal software solution needn't > neccessarily be the most efficiently running code. There can be other > criteria by which to measure quality. I've given a few above. > > Regards, > Andor
Andor, I guess I didn't express myself clearly. Even by the criterion of speed, often the first code to give an answer won't be the code that runs most quickly. My claim was that your claim didn't fit embedded apps. It's rare embedded code that runs only once, and the few examples I can think of (cruise-missle guidance, e.g.) need to make full use of processing resources. Note that I didn't write, or mean to imply, that faster is necessarily better. (I wrote professional code in indirect-threaded Forth to optimize maintainability, code size, and writing time, even though assembly was more than twice as fast.*) The example I asked for was useful embedded code, optimal by any standard, written in complete ignorance of the hardware it runs on. I expect that there is no example, but I hope I'm wrong. It would be a wonder to see. Jerry. P.S. The quote I claim doesn't apply to embedded work is, "Thus, you can produce optimal code and be completely ignorant of the hardware it runs on." _____________________________ * Optimized native-code Forths run about as fast as Gnu C, give or take ten percent, depending on the application and the programmer's skill. -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by Andor July 27, 20032003-07-27
Jerry Avins wrote:
...
> > There are many criteria by which to measure code quality: execution > > speed, memory requirement, upgradeability, modifiability, > > reuasability, development speed, portability, etc.
...
> I'd like to see, or hear of anecdotally, an optimal embedded system > written in complete ignorance of the hardware it is to run on.
Jerry, you did not read what I wrote. An optimal software solution needn't neccessarily be the most efficiently running code. There can be other criteria by which to measure quality. I've given a few above. Regards, Andor
Reply by Jerry Avins July 25, 20032003-07-25
Andor wrote:
> > "KG7HF" wrote: > > > Writing in high level language without understanding the architecture > > > will produce non-optimal code. > > > > Writing in any language, including assembly without understanding the > > architecture will produce non-optimal code. > > There are many criteria by which to measure code quality: execution > speed, memory requirement, upgradeability, modifiability, > reuasability, development speed, portability, etc. > > As a good engineer, you must be able to optimize your code for more > criteria than just execution speed. Thus, you can produce optimal code > and be completely ignorant of the hardware it runs on. > > Regards, > Andor
I believe it's unlikely for code intended to run on an embedded processor to be completely portable. Peripherals may differ in detail, and other resources may need to be shared in different ways. Do you know of any programs written for one embedded processor being ported to another not closely related, and without needing an extensive rewrite? Intel and Mac computers have well known BIOSes, and high-level programs can be compiled for either. OpenBoot (basically Forth source code) permits peripherals to carry their drivers with them, providing portability at the hardware level in Macintosh, Sun, and other platforms. I suppose a completely portable program is possible in systems that combine OpenBoot with embedded Linux, but I suspect that the number of such systems is small and not likely to increase much in the near term. I'd like to see, or hear of anecdotally, an optimal embedded system written in complete ignorance of the hardware it is to run on. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by Andor July 25, 20032003-07-25
"KG7HF" wrote:
> > Writing in high level language without understanding the architecture > > will produce non-optimal code. > > Writing in any language, including assembly without understanding the > architecture will produce non-optimal code.
There are many criteria by which to measure code quality: execution speed, memory requirement, upgradeability, modifiability, reuasability, development speed, portability, etc. As a good engineer, you must be able to optimize your code for more criteria than just execution speed. Thus, you can produce optimal code and be completely ignorant of the hardware it runs on. Regards, Andor
Reply by Jaime Andres Aranguren Cardona July 24, 20032003-07-24
"KG7HF" <KG7HF@amsat.org> wrote in message news:<7UDTa.37197$8g6.683818@news1.news.adelphia.net>...
> > Writing in high level language without understanding the architecture > > will produce non-optimal code. > > Writing in any language, including assembly without understanding the > architecture will produce non-optimal code. > >
Absolutely true!
> > > > > > Writing in high level language without understanding the architecture > > will produce non-optimal code. Otherwise, you will not see those job > > openings for DSP programmers.
And completely connected with what was stated above! JaaC
Reply by KG7HF July 23, 20032003-07-23
>The point is not to write code the hard way, but to have the skill > to use the processor's resources to the utmost when necessary.
And to know when it's not necessary to do so.
> As a matter of fact (a silly clich&#2013265929; indeed!), I have found it useful to > program in binary. The occasions were all limited to patching code > already in ROM, the code snippets were all short, but there you are.
In my particular field it's almost a requirement. Everyone on my team has quite a few binary opcodes committed to memory for the processors we work with. "Jerry Avins" <jya@ieee.org> wrote in message news:3F1DF148.475CFC7C@ieee.org...
> KG7HF wrote: > > > > Sounds like a fairly rigid and inflexible statement. So if I write my > > application in binary, skipping the assembler and linker, am I a god or
a
> > fool? Use of the language which performs the necessary task, seems to me
to
> > be a more rational choice. > > > > PD > > > > "Ramakrishnan Muthukrishnan" <rkrishnan@ti.com> wrote in message > > news:3F1ACC3C.43268D68@ti.com... > > > Jerry Avins wrote: > > > > > > > > For shame! You are to be chided for your retrogressive approach to > > > > programming. Assembler routines, indeed! That's not the modern way
at
> > > > all. Have you no professional standards to uphold? > > > > > > Real men still program DSPs in assembly and only cowards write in high > > > level languages. :-) > > > > > > -- > > > --... ...-- > > > Ramakrishnan > > First, I had hoped that the tongue in my cheek would have been evident. > Second, there are constructions and optimizations that assembler can do > but that any particular higher-level language can't; binary can do no > more. The point is not to write code the hard way, but to have the skill > to use the processor's resources to the utmost when necessary. > > As a matter of fact (a silly clich&#2013265929; indeed!), I have found it useful to > program in binary. The occasions were all limited to patching code > already in ROM, the code snippets were all short, but there you are. > > Jerry > -- > Engineering is the art of making what you want from things you can get. > &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
Reply by KG7HF July 23, 20032003-07-23
> Writing in high level language without understanding the architecture > will produce non-optimal code.
Writing in any language, including assembly without understanding the architecture will produce non-optimal code. "Ramakrishnan Muthukrishnan" <rkrishnan@ti.com> wrote in message news:3F1D605E.F11745F4@ti.com...
> KG7HF wrote: > > > > Sounds like a fairly rigid and inflexible statement. So if I write my > > application in binary, skipping the assembler and linker, am I a god or
a
> > No no. God always wrote in Lisp[1], you know? :-) So you can't be god if > you write in binary. > > > fool? Use of the language which performs the necessary task, seems to me
to
> > be a more rational choice. > > Writing in high level language without understanding the architecture > will produce non-optimal code. Otherwise, you will not see those job > openings for DSP programmers. > > If your task doesn't demand performance, you can afford to do that. Try > writing an FIR filter code for some processor which has, say more than > one MAC units, and see the assembler output. You will know. > > [1] http://www.gnu.org/fun/jokes/eternal-flame.html > -- > --... ...-- > Ramakrishnan
Reply by KG7HF July 23, 20032003-07-23
> Yeah, but tech support would be a whole lot easier if all your customers > were qualified astronauts!
I doubt it......"Mission control, is there a procedure for that?" "Matt Timmermans" <mt0000@sympatico.nospam-remove.ca> wrote in message news:JWuTa.6204$1I5.591481@news20.bellglobal.com...
> > "Jim Thomas" <jthomas@bittware.com> wrote in message > news:3F1E0519.99751CBE@bittware.com... > > It made me feel like a manly man at the time, but in retrospect, it > > doesn't compare to the deeds performed to return Apollo 13 to earth. > > Yeah, but tech support would be a whole lot easier if all your customers > were qualified astronauts! > >
Reply by Andor July 23, 20032003-07-23
Jim Thomas wrote:
...
> It made me feel like a manly man at the time, but in retrospect, it > doesn't compare to the deeds performed to return Apollo 13 to earth.
I was wondering about that movie - did they really do all that crazy stuff (inclusively the runs through the simulator) in real life?
Reply by Matt Timmermans July 23, 20032003-07-23
"Jim Thomas" <jthomas@bittware.com> wrote in message
news:3F1E0519.99751CBE@bittware.com...
> It made me feel like a manly man at the time, but in retrospect, it > doesn't compare to the deeds performed to return Apollo 13 to earth.
Yeah, but tech support would be a whole lot easier if all your customers were qualified astronauts!