Post by thread:[OT]: Elegant way round C scoping problem..?

----- Original Message ----- From: Byron A Jeff <spam_OUTbyronTakeThisOuTCC.GATECH.EDU> To: <.....PICLISTKILLspam@spam@MITVMA.MIT.EDU> Sent: Friday, October 27, 2000 8:10 PM Subject: Re: Elegant way round C scoping problem..? {Quote hidden}> > > > In-Reply-To: <CMM.0.90.4.972577720.billw@flipper> > > > > William Chops Westfield <billwKILLspamcisco.com> wrote: > > > How about making your subproc local?: > > > void proc1() > > > { int b=0; > > > > > > void subproc(a) /* subproc is local to proc */ > > > {b+=a;} > > > subproc(1);subproc(2); > > > } > > > > > > > Not allowed in C. > > Actually the truth is closer to not allowed in ANSI standard C. GCC for > example allows for that example above unless the -pedantic flag is > set. > > Shocked the heckomers out of me the first one of my students showed me that > it worked. > > BAJ Of course you now insist that your students use -pedantic at all times, right :-) Wouldn't want the kids learnin' that non-standard stuff. (unless of course it comes from M$). Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > use .....listservKILLspam.....mitvma.mit.edu?body=SET%20PICList%20DIGEST > > > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu?body=SET%20PICList%20DIGEST

On Fri, 27 Oct 2000 20:27:49 -0400, you wrote: {Quote hidden}>----- Original Message ----- >From: Byron A Jeff <byronspam_OUTCC.GATECH.EDU> >To: <@spam@PICLISTKILLspamMITVMA.MIT.EDU> >Sent: Friday, October 27, 2000 8:10 PM >Subject: Re: Elegant way round C scoping problem..? > > >> > >> > In-Reply-To: <CMM.0.90.4.972577720.billw@flipper> >> > >> > William Chops Westfield <KILLspambillwKILLspamcisco.com> wrote: >> > > How about making your subproc local?: >> > > void proc1() >> > > { int b=0; >> > > >> > > void subproc(a) /* subproc is local to proc */ >> > > {b+=a;} >> > > subproc(1);subproc(2); >> > > } >> > > >> > >> > Not allowed in C. >> >> Actually the truth is closer to not allowed in ANSI standard C. GCC for >> example allows for that example above unless the -pedantic flag is >> set. >> >> Shocked the heckomers out of me the first one of my students showed me >that >> it worked. >> >> BAJ > >Of course you now insist that your students use -pedantic at all times, >right :-) > >Wouldn't want the kids learnin' that non-standard stuff. (unless of course >it comes from M$). I think it's about time ANSI standardised a 'microcontroller version' of the C standard. For example, there seems to be as many different ways of handling I/O as there are compilers! There are a few other features which would greatly improve things IMO: A 24-bit 'medium' data type. I often find that Ints are too short and Longs a bit wasteful. Direct access to the carry flag - very handy for things like rotating and detecting overflows. Nested procs (as discussed previously) to save code space. Auto inlining of procedures that are only called once. -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

{Quote hidden}> > On Fri, 27 Oct 2000 20:27:49 -0400, you wrote: > > >----- Original Message ----- > >From: Byron A Jeff <spamBeGonebyronspamBeGoneCC.GATECH.EDU> > >To: <TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU> > >Sent: Friday, October 27, 2000 8:10 PM > >Subject: Re: Elegant way round C scoping problem..? > > > > > >> > > >> > In-Reply-To: <CMM.0.90.4.972577720.billw@flipper> > >> > > >> > William Chops Westfield <RemoveMEbillwTakeThisOuTcisco.com> wrote: > >> > > How about making your subproc local?: > >> > > void proc1() > >> > > { int b=3D0; > >> > > > >> > > void subproc(a) /* subproc is local to proc */ > >> > > {b+=3Da;} > >> > > subproc(1);subproc(2); > >> > > } > >> > > > >> > > >> > Not allowed in C. > >> > >> Actually the truth is closer to not allowed in ANSI standard C. GCC = > for > >> example allows for that example above unless the -pedantic flag is > >> set. > >> > >> Shocked the heckomers out of me the first one of my students showed me > >that > >> it worked. > >> > >> BAJ > > > >Of course you now insist that your students use -pedantic at all times, > >right :-) No. I just plugged that particular hole in my paradigm and make sure to explain that functions cannot be nested. It's just that before it never occured to me that it was allowed.... {Quote hidden}> > > >Wouldn't want the kids learnin' that non-standard stuff. (unless of = > course > >it comes from M$). > I think it's about time ANSI standardised a 'microcontroller version' > of the C standard.=20 > =46or example, there seems to be as many different ways of handling I/O > as there are compilers! > There are a few other features which would greatly improve things > IMO:=20 > > A 24-bit 'medium' data type. I often find that Ints are too short and > Longs a bit wasteful. > > Direct access to the carry flag - very handy for things like rotating > and detecting overflows.=20 > > Nested procs (as discussed previously) to save code space. > > Auto inlining of procedures that are only called once.=20 Actually I have a different take on it: C really isn't suitable for embedded systems programming. It's a general purpose language applied to the task. What's really needed is an application specfic language for embedded systems programming. The students in my Language Design and Implementation class are taking a first crack at such a language. In the next couple of weeks we'll be soliciting input from the list once they finish their initial design documents. Here's the basic elements: - Event driven. Code is triggered when state conditions are met. - Embedded data types for common I/O operations including digital I/O, async/ sync serial, parallel, PWM, ADC, voltage to frequency conversion, timers, and others. These objects have attributes that bind them to particular pins. Once configured the I/O objects are accessed as normal variables. - A future ability will be to construct new/different types of objects from the embedded set. Here's a real brief example that'll map a switch (active low) to an LED (active high): ------------------------------------ bit switch addr=PORTA bitnum=4 dir=in onstate=0 // Switch reads as on when it's low endbit bit led addr=PORTB bitnum=0 dir=out endbit // Note the default onstate for a bit is high when switch=ON led=ON endwhen when switch=OFF led=OFF endwhen --------------------------------------- It's wordy on purpose, because it's a teaching language. It's also incomplete because there isn't enough time to cover all the issues in a semester. Comments? More forthcoming in a week or two... BAJ -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestEraseME.....mitvma.mit.edu

>From: Byron A Jeff <EraseMEbyronCC.GATECH.EDU> >Actually I have a different take on it: C really isn't suitable for >embedded systems programming. It's a general purpose language applied to >the task. Afaik C is a systems programming language and was designed as such and for that purpose. They did not actually know what kind of (PDP) system it was for so they made some features up on the way. It cannot be an accident that 90% of the operating systems in common use are written in C or some dialect thereof. It is not pretty and it allows you to rummage in the gearbox at will. That's what makes it so different from other 'beautiful' languages which are less good for systems programming for various reasons. I think that the highly portable nature of C is due to the machine independent 'structured assembly language' concept they had to use to accomodate the wildly varying instruction sets of the PDP machines and other monsters they were using at the time. >The students in my Language Design and Implementation class are taking a >first crack at such a language. In the next couple of weeks we'll be >soliciting I think that this is a great learning experience but my comments to the new language can be summarized in two words: VHDL and Prolog However, I'm just a guy. Peter -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads

> Afaik C is a systems programming language and was designed as such and > for that purpose. They did not actually know what kind of (PDP) system > it was for so they made some features up on the way. > : > I think that the highly portable nature of C is due to the machine > independent 'structured assembly language' concept they had to use to > accomodate the wildly varying instruction sets of the PDP machines and > other monsters they were using at the time. I think C was pretty obviously targetted toward the PDP11. There are constructs that map directly onto PDP11 architectural features... Let's not get revisionist, either. It was "ages" (more than 10 years?) before C was widely in use on anything BUT PDP11s. It never hit the PDP-8 at all (AFAIK), wasn't particularly usable on the PDP-10 till after that architecture's nominal lifetime, and BLISS was heavilly pushed for the Vax. C was available for CPM machines, but was not a big success. Much Apple Mac Software was written in Pascal dialects, and C wasn't used "much" on Wintel systems till the 386 processor fixed the architectures to be more C-friendly. C popularity on microCONTROLLERS postdates THAT - a relatively recent phenomena indeed. In a sense, this is the RISC revolution at work. The way I interpret it, the idea behind RISC is not to make processor architectures any more complex that compiler technology can generate good code for (which is a bit different than just reducing the number of instructions.) BillW -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads

On Mon, 30 Oct 2000 21:24:29 +0200, you wrote: >>From: Byron A Jeff <RemoveMEbyronEraseMEEraseMECC.GATECH.EDU> > >>Actually I have a different take on it: C really isn't suitable for >>embedded systems programming. It's a general purpose language applied to >>the task. > >Afaik C is a systems programming language and was designed as such and for >that purpose. They did not actually know what kind of (PDP) system it was >for so they made some features up on the way. It cannot be an accident >that 90% of the operating systems in common use are written in C or some >dialect thereof. It is not pretty and it allows you to rummage in the >gearbox at will. That's what makes it so different from other 'beautiful' >languages which are less good for systems programming for various reasons. > >I think that the highly portable nature of C is due to the machine >independent 'structured assembly language' concept they had to use to >accomodate the wildly varying instruction sets of the PDP machines and >other monsters they were using at the time. ..and of course the portability is a virtual non-issue for small microcontrollers - maybe a marginal advantage in not having to re-learn a new language (apart from all the target- and compiler- specific stuff...) -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

>>Of course you now insist that your students use -pedantic at all times, >>right :-) >Is there not some way of having a system wide default setting that they do not realise exists to enforce it?? Gotta >play these students at their own game ;)) Simply tell them that they have to submit source code, and that _you_ are going to compile it with --pedantic, and while we are at it, that you are going to 'lint' it at maximum sensitivity. Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

More than the syntax of the language, I feel that the major failing of embedded programming languages are as follows: A) Piss poor, inconsistent or no macro pre-processing B) Lack of USEFULL access to the generated code and to the library of routines that will be used to generate the code. C) Lack of open source. E) Lack of integration with the debugger. What we really need is a really good macro pre-processor to BUILD the language out of (99% of an assembler is just macro definitions with db's inside, and a good macro language can make all the if, thens, switch, case, do while, and whatevers you want) and a library manager that lets us keep multiple versions of routines and finds the "best fit" by looking at bit width, required accuracy, code space available, timing requirements and other items that non-embedded languages don't usually care about. And it has to be open source. And another thing... it should make it very easy to feedback improvements... For example: If you ask it to compile varA = functionA(functionB) and you look at the result and see that some of functionB's exit code can be combined with functionA's entry code, and you change it, a message describing the optimization of functionA(functionB) should be sent to a central site so that the next time someone asks for that specific combination of functions, they at least get the option to select the optimized version. Ok, am I the only person that sees it this way? --- James Newton (PICList Admin #3) RemoveMEjamesnewtonspam_OUTKILLspampiclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org {Original Message removed}

What we really need is a really good macro pre-processor to BUILD the language out of (99% of an assembler is just macro definitions with db's inside, and a good macro language can make all the if, thens, switch, case, do while, and whatevers you want) Well, there are plenty of stand-alone macro "preprocessors" that are probably suitably powerful and open source (m4, for instance?) But... lacking widespread standardization of the macros in use, this results in HORRIBLY unreadable (and not very portable) code. I knew a guy in college that had succeeded in making the local assembler look like an interesting cross between basic, fortran, and APL... Yuck. and a library manager that lets us keep multiple versions of routines and finds the "best fit" Like java's (and others?) feature that allows "add (char a, char b)" to be different code from "add (short a, short b)" ? BillW -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

I'm thinking of a "packaging" of something like M4 with a set of macros that implements a basic assembler PLUS some nice structured programming constructs like for next, if then, do while, repeat until, select case, etc... then add something like the Java feature you mentioned that does find the right version of function based on what it is being handed... ...The magic part of that is parameter matching... you either have to take all the parameters as copies or pointers or something has to "mung" the registers used by routineA over into those used by routineB. Of course if routineB only gets used once, and its code refers to <regA> instead of using a cblock or define and a register name, then the library code could replace <regA> with the register that routineA returned its value in... Nik and I and Jon Hylands have discussed this to death and ended up not doing much with it, but I'm still interested in trying it. --- James Newton (PICList Admin #3) EraseMEjamesnewtonspamspamBeGonepiclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org {Original Message removed}

>I'm thinking of a "packaging" of something like M4 with a set of macros >that implements a basic assembler PLUS some nice structured programming >constructs like for next, if then, do while, repeat until, select case, >etc... then add something like the Java feature you mentioned that does >find I dunno if M4 is up to it alone, as M4 is single pass and any assembler requires 2 passes, so you need a shell. Since you need a shell, you may not need M4 since a shell like Bash is powerful enough to write an assembler in. I am not joking. There are precedents ;-). In fact I think that some people could write an assembler using the DOS batch language only given the patience (shudder). The Java feature you mentioned is in fact type sensitive scoping as in C++ and other languages (like Basic). You can implement it using M4 or whatever, by mangling the function name internally with a simple (string) hash of the function parameters types and the return type. F.ex. int foo(char a, int b); will be munged internally to: ici_foo(a,b) Of course when you do this in a proper programming language you don't do it like this, you use a proper set of data structures instead. Peter -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use RemoveMElistservKILLspammitvma.mit.edu?body=SET%20PICList%20DIGEST