I would like this one :P : "- Create a generic structure for each variable, with pointers to the read and write function. Pass the address of this struct to procedures and use it to operate on the vars. This will give quite some overhead, but is very powerful and will probably support all functionality the JAL compiler provides. "
Specially because of the last part: "but is very powerful and will probably support all functionality the JAL compiler provides" Vasi(funlw65) On Apr 23, 12:16 am, Joep Suijs <[email protected]> wrote: > 2010/4/22 William <[email protected]>: > > >> Log: JAL Blink-a-led demo on Arduino board with > >> AtMega168http://code.google.com/p/jallib/source/detail?r=1968 > > > Very cool! > > Yes it is, isn't it :) > It has been just over a year since Seb brought this up > (http://groups.google.com/group/jallib/browse_thread/thread/cadc571bc8...) > and it took two weeks to get this far. > And especially the Antlr part was informative and fun, so thank you > for bringing this to my attention! > > At this point, the translator covers most of the generic part of the > language - procedure and function definition (only in-vars though), > calling of procedures and functions, expressions and all flow control. > Variable support is limited to 8,16 and 32 bits and 'at', 'is' and > 'alias' are not supported. > > Variable handling is the next topic to addres and I checked out some > code generated by the JAL compiler. In normal cases, the calling > procedure puts the calling values into specific locations of the > destination procedure, execute the call and then takes the value back > (or not, depending on in/out). > However, when a procedure param is volatile, it seems pseudo-variables > are created and these are actually passed to the procedure that gets > called. > > With C, you get the parameter passing on stack 'for free', but there > are many different situations to be handeled: > - call by reference or value (in/out or in) > - odd-sized variables (multi-byte but not 8,16 or 32 bits) > - bit variables (including the multi-bit ones) > - aliasses and at (lets ignore 'is' for now). > > And all this cases do affect each use the varialbe - reading it, > writing it, passing it to a procedure. So how can we handle this? > > I see a few options: > - Stick to the current variable types supported by C and only add > call-by value / reference. This gives pretty efficient code, but many > jal features won't be supported. > - Mimic the jal compiler by storing the values in a specific place and > always call by rereference. Not so efficient, but would allow for > odd-sized vars. > - Create a generic structure for each variable, with pointers to the > read and write function. Pass the address of this struct to procedures > and use it to operate on the vars. This will give quite some overhead, > but is very powerful and will probably support all functionality the > JAL compiler provides. > > What do you guys think? > > Joep > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/jallib?hl=en. -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
