Gerhard Fiedler wrote:

> >> Have you considered generating high level source
> >
> > No, I think the compiler should have full control over what is
> > generated. I have been dreaming about a construct that I'd like at least
> > in theory be able to implement: fixed-timing programming. This
> > definitely requires full control over the generated code.
>
> While we're at it, and two compiler writers are discussing about useful
> features, John Payson came up with an interesting idea in the Htsoft forum
>
http://www.htsoft.com/forum/all/showflat.php/Cat/0/Number/15352/an/0/page/0#1535
2
>
> Basically, it is a compiler that can generate both compiled code (fast) and
> interpreted (small) code. The programmer can mark every function that
> should be interpreted, and it would transparently be compiled differently
> (into something like a p code that then gets interpreted by a runtime
> engine). I found the thought intriguing.
>
> Gerhard

The only real problem that I can see with this is the relatively huge overhead
of providing an interpreter. For a small device like a PIC I think that the net
gain would be small and cost considerable effort. An alternative would be an
optimising compiler that is geared towards generating compact code instead of
efficient code. XCSB generates compact executables as a SIDE EFFECT of trying to
generate efficient code. It could generate much more compact code if efficiency
were not an issue but in some cases it would takes several times as long to
execute.

An important point to consider is that larger programs often require more
runtime variables than smaller programs. Simply increasing the size of the code
section of a program may still fail to yield a bigger program because the
variable requirements (RAM) are harder to meet.

Anyway a good method of implementing a mixed compiled / interpreted executable
would be to use function calls in place of tokens and embed data after the call.
However this would require the ability to access and modify the return address
which cannot be done using the "call" instruction of the 14 bit PICs. An
alternate call mechanism (such as the XCSB longcall mechanism) could be used but
this is not as efficient as the native "call" instruction. On the 18 series this
probem does not exist.

Using calls as tokens the amount of "interpreter kernel" pulled into the
executable could be controlled by the compiler effectively eliminating those
parts of the interpreter which are not use by the application. The main down
side would be that the interpreted (byte code) could not be held in external
memory.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist