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) mailto:jamesnewton@piclist.com 1-619-652-0593 PIC/PICList FAQ: http://www.piclist.com or .org -----Original Message----- From: pic microcontroller discussion list [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Byron A Jeff Sent: Saturday, October 28, 2000 06:06 To: PICLIST@MITVMA.MIT.EDU Subject: Re: [OT]: Elegant way round C scoping problem..? > > On Fri, 27 Oct 2000 20:27:49 -0400, you wrote: > > >----- Original Message ----- > >From: Byron A Jeff > >To: > >Sent: Friday, October 27, 2000 8:10 PM > >Subject: Re: Elegant way round C scoping problem..? > > > > > >> > > >> > In-Reply-To: > >> > > >> > William Chops Westfield 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.... > > > >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 mailto:piclist-unsubscribe-request@mitvma.mit.edu -- 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