Jerry Avins wrote:> > As a matter of fact (a silly clich� 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.I once walked a person through the steps necessary to edit an executable. Over the phone. 3000 miles away. He was using vi. 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. -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (703) 779-7770 Visualize whirled peas.
Blackfin two-word *fast* floating-point library
Started by ●July 19, 2003
Reply by ●July 23, 20032003-07-23
Reply by ●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!
Reply by ●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 ●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 ●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 ora> > 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 meto> > 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 ●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� 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 ora> > fool? Use of the language which performs the necessary task, seems to meto> > 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 wayat> > > > 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� 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. > �����������������������������������������������������������������������
Reply by ●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 ●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 ●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, > AndorI 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 ●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
