Post by thread:First module of PIC Code Generator Released!

This is NICE!!! Nikolai Golovchenko techref.massmind.org/member/Ng--944/index.htm has undertaken to write a code generator for the PIC (and possibly other small processors in the future) that will accept a simple expression, parse it, and generate source code that will allow the PIC to evaluate the expression. As a first step, multiplication and division by a constant through a simple html form IS NOW AVAILABLE at: http://www.piclist.com/codegen/constdivmul Future enhancements may include infix math expression evaluation, basic io functions (e.g. RS232Out(USART1, PortD / 7)), timing (e.g. OnceEvery(2, minutes, LCDT6963COut((PortA & 7)*2)) and so on. We hope to standardize a method for including function definitions contributed by anyone where the chip type, clock speed and other supporting requirements, input, output, description and code are defined on a web based input form and the function is then included in a library of available functions that can be called from the code generator. Ultimately you could enter something like: RS232Out(a0,a1,printf("Flow rate: %d at %s", sin(ADCIn(b0,sigmadelta)^2)*100, Time(h,m,s))), Clock=4Mhz, Part=16F84 and get the code to read a sigma delta analog to digital converter on pin B0, do the calculation, get the time from an ISR clock, generate the text answer, and bit bang it out the serial port connected to pins A0 and A1. Please note that this is a completely made up example and in no way reflects any method we know for calculating "flow rates" <GRIN>. If anyone is interested in contributing to this project, please contact Nikolai, or James Newton. If you like what you see, please encourage us to continue expanding the PICList code generator. --- James Newton spam_OUTjamesnewtonTakeThisOuTgeocities.com 1-619-652-0593 http://techref.massmind.org NEW! FINALLY A REAL NAME! Members can add private/public comments/pages ($0 TANSTAAFL web hosting)

> We hope to standardize a method for including function definitions > contributed by anyone where the chip type, clock speed and other supporting > requirements, input, output, description and code are defined on a web based > input form and the function is then included in a library of available > functions that can be called from the code generator. > > Ultimately you could enter something like: > > RS232Out(a0,a1,printf("Flow rate: %d at %s", > sin(ADCIn(b0,sigmadelta)^2)*100, Time(h,m,s))), Clock=4Mhz, Part=16F84 > and get the code to read a sigma delta analog to digital converter on pin > B0, do the calculation, get the time from an ISR clock, generate the text > answer, and bit bang it out the serial port connected to pins A0 and A1. Just a thought, have you seen Robin Abbott's WizPIC application generator/development environment? (http://www.fored.co.uk) It does something similar through a graphic drag'n'drop interface. It'd be *really* nice if your functions were compatible with his, or at least translatable... <Unsolicited plug> I use WizPIC a *lot*, mostly for the excellent simulator (Yes. I know, James...:>) and the totally wonderful Waveform Analyser - a software, graphic logic analyser that runs within the sim. Oh yes. In case anyone was wondering, my only connection with the company is as a happy customer. </Unsolicited plug> .-. / \ .-. .-. / \ / \ .-. _ .-. / \ -/-------\-------/-----\-----/---\---/-\---/---\-----/-----\-------/ \ / \ / `-' `-' \ / \ / \ / `-' `-' \ / `-' `-' ------------------------------------------------------------------------

I looked at the screen shot (just one?) and it looks really nice. I'm not sure about the overall usefulness of the graphic pin layout display, etc.... but I really do like code generators. Compilers (that don't compile to source) try to do the programmers job for them and take away control. Code generators help the programmer get the job done, but leave them in control. In the embedded world, I think that is still important. We are trying to come up with a good format for defining how data gets into and out of each entry in a function library, what attributes of the functions we need to track to ensure then best match between the current project and the available functions and a syntax for calling functions and passing parameters. Any advice or input appreciated. I'm sort of leaning for a C like system. Any references to how C function libraries work would be nice. Re: the existing code generator: You really ought to go check it out. Its very nice. Allows you to specify how accurate you need the result to be and seriously optimizes the code. See: http://www.piclist.com/codegen/constdivmul Re: simulators, hee, hee, my reputation proceeds me.... Now, please understand, I express my opinions pretty strongly sometimes, but I do feel that each person must do what works for them. If you get good service from simulators, then by all means... My opinions are a result of the (bad) experiences I've had. I'm also a blow hard - don't take me too seriously. --- James Newton .....jamesnewtonKILLspam@spam@geocities.com 1-619-652-0593 http://techref.massmind.org NEW! FINALLY A REAL NAME! Members can add private/public comments/pages ($0 TANSTAAFL web hosting) {Original Message removed}

> From: James Newton <jamesnewtonKILLspampiclist.com> The PIC code generator is interesting. It has many compiler elements in it preserving error and resolution information to name two. > Compilers (that don't compile to source) try to do the programmers job > for them and take away control. Code generators help the programmer > get the job done, but leave them in control. In the embedded world, > I think that is still important. It is a question of what part of the curve a development is on. The high volume developer who uses a compiler are as familiar with the compiler as the casual programmer is with the code generator and for similar reasons. The Code Generator user understands the function of the code generator and with time and effort could duplicate the results. The compiler user has a similar relationship with his tools. In both cases tools save time and effort to implement an application. > > We are trying to define how data gets into and out of a function library, > what functions need and a syntax for calling functions and passing > parameters. < editing mine > > > Any references to how C function libraries work would be nice. This is actually getting more complex in C compilers. As C compilers have passed assembly language in code density they have done so in part by data flow analysis for the whole program. This has meant that each function call can be potentially different in some applications. Without global optimization you may be limited to data stack argument processing with its (relatively) high run-time overheads. Walter Banks http://www.bytecraft.com

Indeed it is an interesting idea. I would like to see it extended. It's along the same sort of lines as Scenix's Virtual Peripheral idea. I thought that was a good idea it just didn't really have any substance to it. Yeah great, modules that integrate together seamlesly. But this wasn't the case. To put 2 modules together still required a fair degree of manual massaging. However, If you had a preprocessor that used information in the modules (code generator components, virtual peripherals etc) and did the messy integration for you... The sorts of things I'd like to see it do are taking care of things such as clock speed issues, variable allocation, unique variable naming. For instance, each module would specify ISR code, the frequency it needs to be run at and if it's timing critical. Then the preprocessor would look at all the ISR code needed, and create a single ISR, the neccesary timer initialisation, add the various ISR segments and sort out their priority. In some cases it may have problems with largely incompatible frequencies but apart from that it wouldn't be too complicated. Just this would eliminate a large part of the work of integrating code modules together. In terms of module specification I would suggest that C style headers may be a little simplistic. You could follow the same style but is it suitable? I would have thought such information may better be stored as some sort of markup (property\value pairs) to the code, embedded in comments so standard compilers ignore it. Due to the variance in the sort and ammount of information stored on each module it's less suited to a fully specified C style header and more suited to a more freeform markup header (i.e. you can define new properties not just values for defined ones and still be backwards compatible). One limitation may be having to work with standard compilers. A lot of optimisation could be better done at the compilation stage with module information. For instance allocation of variables, if the modules contained basic information on variables used (e.g. if they need to be maintained between calls) then a companion compiler could more heavily optimise them based on such information. Another such situation is optimisation. In my view it would be nice if you could optimise modules for either size or speed, for instance if you choose speed, it would put commonly used portions of code inline, increasing speed at the cost of program memory. Ideally you would be able to tell the program how much program code\instruction cycles were allowable and it would minimise the other. However this would really need to be done as part of compilation. Tom. {Original Message removed}

Walter Banks <.....walterKILLspam.....BYTECRAFT.COM> wrote on Tuesday, March 14, 2000: >> From: James Newton <EraseMEjamesnewtonspam_OUTTakeThisOuTpiclist.com> > The PIC code generator is interesting. It has many compiler elements in it > preserving error and resolution information to name two. Yes, it resembles compilers to a degree. I always thought that compilers don't bother with resolution and leave it on user to decide which data type to use for a particular variable. A typical task for an assembler programmer is to develop some math stuff which has an input of n bits. In the process of computations, the variable size can grow or shrink. This is difficult to maintain in assembly as well as in C. Code generator could manage the variables size on bit level! This makes possible to optimize code even more by calling routines with exact number of loops or assuming content of some bits... Actually, code generator idea can be applied to C language too (many cases: filters, interrupts routines, initializations, etc.), though we are currently working on PIC assembly version. >> Compilers (that don't compile to source) try to do the programmers job >> for them and take away control. Code generators help the programmer >> get the job done, but leave them in control. In the embedded world, >> I think that is still important. > It is a question of what part of the curve a development is on. The high > volume developer who uses a compiler are as familiar with the compiler > as the casual programmer is with the code generator and for similar > reasons. Compilers still can't compete with a good assembly programmer in code size and speed. Give the programmer a bunch of tools and he/she will do the job as fast. I may be wrong, but seems like there is a significant number of people writing in assembler (or mix with C) on professional basis. > The Code Generator user understands the function of the code generator > and with time and effort could duplicate the results. The compiler user > has a similar relationship with his tools. In both cases tools save time > and > effort to implement an application. Yes. One more point - the goal of the code generator is to unify the wealth of good routines (like at http://www.piclist.com) under one roof and make it possible for users to add new functions as well as code generating functions for some specific tasks, like constant multiplication/division, DSP, etc. These functions will interact, for example a filter function will want to use constdivmul.exe a lot. We are trying to define the common interface, which would allow easy integration of already written functions. {Quote hidden}>> >> We are trying to define how data gets into and out of a function library, >> what functions need and a syntax for calling functions and passing >> parameters. < editing mine > >> >> Any references to how C function libraries work would be nice. > This is actually getting more complex in C compilers. As C compilers > have passed assembly language in code density they have done so > in part by data flow analysis for the whole program. This has meant > that each function call can be potentially different in some applications. > Without global optimization you may be limited to data stack argument > processing with its (relatively) high run-time overheads. > Walter Banks > http://www.bytecraft.com Nikolai

Thanks Tom for your suggestions. Unique variable naming can be achieved by adding a prefix to the local variable name. The prefix could be the function name that must be unique. I'm a bit uncertain about variables allocation. There is going to be a temporary area for local variables. How about this: cblock Abc, Def //global variables Temp0, Temp1, ..., TempN //local variables endc Fun1_x equ Temp0 Fun1_y equ Temp1 Fun2_a equ Temp0 Fun3_t0 equ Temp2 Fun3_t1 equ Temp3 Fun3_t2 equ Temp4 We plan to include options in the code generator for processor type, clock frequency, possible optimization options are code size, speed, used RAM size. Probably the optimization options should be passed individually to each function to fine tune the optimization in addition to global settings. Nikolai Brandon, Tom <Tomspam_OUTPSY.UNSW.EDU.AU> wrote on Wednesday, March 15, 2000: {Quote hidden}> Indeed it is an interesting idea. I would like to see it extended. It's > along the same sort of lines as Scenix's Virtual Peripheral idea. I thought > that was a good idea it just didn't really have any substance to it. Yeah > great, modules that integrate together seamlesly. But this wasn't the case. > To put 2 modules together still required a fair degree of manual massaging. > However, If you had a preprocessor that used information in the modules > (code generator components, virtual peripherals etc) and did the messy > integration for you... > The sorts of things I'd like to see it do are taking care of things such as > clock speed issues, variable allocation, unique variable naming. For > instance, each module would specify ISR code, the frequency it needs to be > run at and if it's timing critical. Then the preprocessor would look at all > the ISR code needed, and create a single ISR, the neccesary timer > initialisation, add the various ISR segments and sort out their priority. In > some cases it may have problems with largely incompatible frequencies but > apart from that it wouldn't be too complicated. Just this would eliminate a > large part of the work of integrating code modules together. > In terms of module specification I would suggest that C style headers may be > a little simplistic. You could follow the same style but is it suitable? I > would have thought such information may better be stored as some sort of > markup (property\value pairs) to the code, embedded in comments so standard > compilers ignore it. Due to the variance in the sort and ammount of > information stored on each module it's less suited to a fully specified C > style header and more suited to a more freeform markup header (i.e. you can > define new properties not just values for defined ones and still be > backwards compatible). > One limitation may be having to work with standard compilers. A lot of > optimisation could be better done at the compilation stage with module > information. For instance allocation of variables, if the modules contained > basic information on variables used (e.g. if they need to be maintained > between calls) then a companion compiler could more heavily optimise them > based on such information. Another such situation is optimisation. In my > view it would be nice if you could optimise modules for either size or > speed, for instance if you choose speed, it would put commonly used portions > of code inline, increasing speed at the cost of program memory. Ideally you > would be able to tell the program how much program code\instruction cycles > were allowable and it would minimise the other. However this would really > need to be done as part of compilation. > Tom. > {Original Message removed}