Grant Edwards <grante@visi.com> wrote in message news:<4177ca73$0$1313$a1866201@newsreader.visi.com>...> On 2004-10-21, Galina <galkas@mail.ru> wrote: > > > Every application has got some dead code. > > Surely your toolchain doesn't allow dead code to end up in the > ROM???Entirely possible. For example you pump a pile of individual C files through the compiler one at a time and get a pile of object files out of the other side, each C file is therefore considered in isolation and the compiler doesn't dare remove 'dead' code because one of the other C files it hasn't got to yet might rely on it. Now the linker gets a pile of object files to glue together, but can't see the source, so doesn't dare remove a function incase the compiler was being cunning and made several routines share common function returns for example. Result: dead functions in output image, Sprow.
Is UML appropriate for embedded systems ?
Started by ●October 14, 2004
Reply by ●October 21, 20042004-10-21
Reply by ●October 21, 20042004-10-21
"Ton Janssen" <djan@oce.nl> wrote in message news:1098167368.621217@news-ext.oce.nl...> Hi, > > In my opinion, UML is very wel suited for embedded systems specification, > design AND implementation. Sequence diagrams are a good help in specifying > specific behaviour, although you need more diagrams (structure and > behaviour) to completely specify the system. IMO the big advantage only > starts if your systems's model is used to generate the actual code, > otherwise you end up with a documentation tool. > > We have been using Rose Realtime C++ and C with complete codegenerationfor> several years sucessfully to implement complex embedded applications. C++ > with active classes and an underlying RTOS for the 32 bit platforms, Cwith> passive classes only and NoRTOS for the 16 bit platforms. > > Cheers, > --The company I work for uses Rose for smartcard operating systems (a few hunderd K ROM, a few K RAM). Not being the system architect, I am not very convinced by Rose. I see it as a 'glorified' interface to the source control combined with a crappy editor. The best way to use it seems to be: generate code and use IDE's to capture the syntax errors. Correct errors, test and port back to Rose (copy/paste for Java code) . Configuration management in awkward as Rose does not support hierachical packages and we are maintaining about a dozen slightly different configurations. Syncing with source control takes 40 minutes, giving me enough time to drink my coffy and read my email and several newspapers when I come in the office in the morning. The use of UML for our purpose is not obvious. Usecases are very boring as a smartcard is single proces/single treaded and the only usecase is: send command, get response. We are not using state diagrams to generate code (a smartcard does not have much state anyway and translating Open Platform and Javacard into statediagrams is possibly not worth the trouble) I only experienced quite a drop in productivity when switching from VSS + IDE to Rose. It may be useful for systems with lots of state or complicated usecases, but IMHO not for OSes or VMs My collegue in France is raving about a UML product from Telelogic or so. Wim
Reply by ●October 21, 20042004-10-21
On 2004-10-21, Sprow <news@sprow.co.uk> wrote:> Grant Edwards <grante@visi.com> wrote in message news:<4177ca73$0$1313$a1866201@newsreader.visi.com>... > >> > Every application has got some dead code. >> >> Surely your toolchain doesn't allow dead code to end up in the >> ROM??? > > Entirely possible. For example you pump a pile of individual C files > through the compiler one at a time and get a pile of object files out > of the other side, each C file is therefore considered in isolation > and the compiler doesn't dare remove 'dead' code because one of the > other C files it hasn't got to yet might rely on it. > > Now the linker gets a pile of object files to glue together, > but can't see the source, so doesn't dare remove a function > incase the compiler was being cunning and made several > routines share common function returns for example. > > Result: dead functions in output image,If that's true, then you're using a rather primitive toolchain. Gnu gcc/binutils can remove unused functions and variables regardless of what files they're in. I assumed most other toolchains did similar garbage-collection. -- Grant Edwards grante Yow! Yow! Are you the at self-frying president? visi.com
Reply by ●October 21, 20042004-10-21
Sprow wrote:> Grant Edwards <grante@visi.com> wrote in message >> On 2004-10-21, Galina <galkas@mail.ru> wrote: >> >>> Every application has got some dead code. >> >> Surely your toolchain doesn't allow dead code to end up in the >> ROM??? > > Entirely possible. For example you pump a pile of individual C > files through the compiler one at a time and get a pile of object > files out of the other side, each C file is therefore considered > in isolation and the compiler doesn't dare remove 'dead' code > because one of the other C files it hasn't got to yet might rely > on it. > > Now the linker gets a pile of object files to glue together, but > can't see the source, so doesn't dare remove a function incase > the compiler was being cunning and made several routines share > common function returns for example. > > Result: dead functions in output image,You avoid that the old fashioned way. If the files are intrinsic parts of the application, they don't have any such cruft in the first place. Otherwise you place the output code (properly modularized) in a library, and the modules only get loaded if called by the main application (or by earlier library modules loaded). For all reasonable values of 'linker'. In C you can't have "common function returns", for the same reasons that you can't have multiple entry points to a routine. -- "I support the Red Sox and any team that beats the Yankees" "Any baby snookums can be a Yankee fan, it takes real moral fiber to be a Red Sox fan" - "I listened to Toronto come back from 3:0 in '42, I watched Boston come back from 3:0 in '04"
Reply by ●October 22, 20042004-10-22
I don't have toolchain. I have an enviponment (possibly, it can be called toolchain, but I can see it this way): VB, VBA. It tolerates any dead code or variables quite happily. Galina Grant Edwards <grante@visi.com> wrote in message news:<4177ca73$0$1313$a1866201@newsreader.visi.com>...> On 2004-10-21, Galina <galkas@mail.ru> wrote: > > > It will be very interesting to read an answer, but I'd like to note > > that in a code created in usual way one never really knows, how > > correct it is (hence catching errors after implementation), how much > > memory resource it will require (God knows!) and whether or not you > > have any dead code (surely you do. Every application has got some dead > > code). > > Surely your toolchain doesn't allow dead code to end up in the > ROM???
Reply by ●October 22, 20042004-10-22
On 22 Oct 2004 06:31:56 -0700, galkas@mail.ru (Galina) wrote:>I don't have toolchain. I have an enviponment (possibly, it can be >called toolchain, but I can see it this way): VB, VBA. It tolerates >any dead code or variables quite happily. >GalinaAre you joking, or do you really use VB and VBA for embedded system work?>Grant Edwards <grante@visi.com> wrote in message news:<4177ca73$0$1313$a1866201@newsreader.visi.com>... >> On 2004-10-21, Galina <galkas@mail.ru> wrote: >> >> > It will be very interesting to read an answer, but I'd like to note >> > that in a code created in usual way one never really knows, how >> > correct it is (hence catching errors after implementation), how much >> > memory resource it will require (God knows!) and whether or not you >> > have any dead code (surely you do. Every application has got some dead >> > code). >> >> Surely your toolchain doesn't allow dead code to end up in the >> ROM???-- Al Balmer Balmer Consulting removebalmerconsultingthis@att.net
Reply by ●October 22, 20042004-10-22
On 2004-10-22, Galina <galkas@mail.ru> wrote:>>> It will be very interesting to read an answer, but I'd like to note that in >>> a code created in usual way one never really knows, how correct it is >>> (hence catching errors after implementation), how much memory resource it >>> will require (God knows!) and whether or not you have any dead code (surely >>> you do. Every application has got some dead code). >> >> Surely your toolchain doesn't allow dead code to end up in the >> ROM??? > > I don't have toolchain. I have an enviponment (possibly, it can be > called toolchain, but I can see it this way): VB, VBA. It tolerates > any dead code or variables quite happily.Firstly, any toolchain can "tolerate" dead code and variables. The problem is that dead code/variables are using up memory better spent on "live" stuff. Secondly, if you're using Visual Basic for embedded stuff, you've got _way_ bigger problems that dead code. -- Grant Edwards grante Yow! Now I'm concentrating at on a specific tank battle visi.com toward the end of World War II!
Reply by ●October 22, 20042004-10-22
On 21 Oct 2004 14:40:51 GMT, Grant Edwards <grante@visi.com> wrote: [...]> >Surely your toolchain doesn't allow dead code to end up in the >ROM???It's been a number of years, but I have worked on a system where I would have been unhappy if "dead code" were not included in the ROM. Because the code wasn't actually "dead," it just wasn't used by that application. Another application (burned in the same ROM) required it. Sort of, but not exactly, like a BIOS. Though I suppose I could have worked around it in assembly if it had come to that... Regards, -=Dave -- Change is inevitable, progress is not.
Reply by ●October 22, 20042004-10-22
On 2004-10-22, Dave Hansen <iddw@hotmail.com> wrote:>>Surely your toolchain doesn't allow dead code to end up in the >>ROM??? > > It's been a number of years, but I have worked on a system where I > would have been unhappy if "dead code" were not included in the ROM. > Because the code wasn't actually "dead," it just wasn't used by that > application. Another application (burned in the same ROM) required > it. Sort of, but not exactly, like a BIOS.No problem. With gnu ld you just tell the linker to keep those functions or files even if they aren't used.> Though I suppose I could have worked around it in assembly if it had > come to that...No assembly required, just an extra command in the linker script file. -- Grant Edwards grante Yow! I will establish at the first SHOPPING MALL in visi.com NUTLEY, New Jersey...
Reply by ●October 22, 20042004-10-22
Grant Edwards <grante@visi.com> wrote:> If that's true, then you're using a rather primitive toolchain. > Gnu gcc/binutils can remove unused functions and variables > regardless of what files they're in.Are you very sure about that? And that it won't break the program completely, in the presence of function pointer usage? Of function pointer arithmetic (--> jump tables)? -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
