Searching \ for 'First module of PIC Code Generator Released!' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'First module of PIC Code Generator Released!'.

Truncated match.
PICList Thread
'First module of PIC Code Generator Released!'
2000\03\13@123636 by jamesnewton

picon face
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_OUTjamesnewtonTakeThisOuTspamgeocities.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)

2000\03\14@113327 by andy howard

flavicon
face
> 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>







   .-.
  /   \           .-.                                 .-.
 /     \         /   \       .-.     _     .-.       /   \
-/-------\-------/-----\-----/---\---/-\---/---\-----/-----\-------/
         \     /       \   /     `-'   `-'     \   /       \     /
          \   /         `-'                     `-'         \   /
           `-'                                               `-'



------------------------------------------------------------------------

2000\03\14@120834 by jamesnewton

face picon face
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 .....jamesnewtonKILLspamspam@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}

2000\03\14@141906 by Walter Banks

picon face
> From: James Newton <jamesnewtonspamKILLspampiclist.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

2000\03\14@174056 by Brandon, Tom

flavicon
picon face
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}

2000\03\14@212739 by William Chops Westfield

face picon face
Antti's AVR Basic compiler allowed an interesting mix of basic statements
and assembler.  This let the compiler do all sorts of tedious things while
you still had full access to the CPU...  Sort of a nice compromise for
embedded use...

BillW

2000\03\15@022746 by Nikolai Golovchenko

flavicon
face
Walter Banks <.....walterKILLspamspam.....BYTECRAFT.COM> wrote on Tuesday, March 14, 2000:
>> From: James Newton <EraseMEjamesnewtonspam_OUTspamTakeThisOuTpiclist.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}

Nikolai

2000\03\15@022802 by Nikolai Golovchenko

flavicon
face
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 <Tomspamspam_OUTPSY.UNSW.EDU.AU> wrote on Wednesday, March 15, 2000:
{Quote hidden}

> {Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...