----- Original Message ----- From: Gerhard Fiedler To: Microcontroller discussion list - Public. Sent: Sunday, February 20, 2005 3:27 PM Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library? > Sergio Masci wrote: > > >> 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 > > > 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. > > I also thought what Wouter wrote: that possibly the net gain is not that > big, with today's good optimizing compilers. Anyway, it would be something > for the bigger processors. I'm sorry but I'm a bit confused. Are you saying I've missed something? > > The other thing Wouter wrote, about control, I think in this case the > control would be the same a programmer has with any interpreted code. It's > less (or it is a bit more complicated to get), but that's interpreters. Ok, well I've definately missed the post you are refering to here. But yes I agree, interpreters are generally not re-enterent. Interrupting one and trying to get it to execute some other high level code can be a big problem unless the facility is built in from the start. Even then there may be unacceptable latency issues. > > > > An alternative would be an optimising compiler that is geared towards > > generating compact code instead of efficient code. > > Or where the goal can be controlled, by function (or file). "optimise for efficiency" and "optimise for size" tend to work against each. Allowing the user too much control over which functions are optimised in which way would probably end up generating executables that are not optimised in either way (result is both slow and big). > > > > 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. > > I guess the not needed parts of the interpreter could be eliminated even > with standard p code -- keep in mind that in this scenario, the > compiler/linker would generate the interpreter at the same time it > generates the p code. Forget p-code. p-code is stack based and uses a dynamic runtime stack. To generate really efficient native PIC code a compiler needs to generate code based on a static stack. The static stack used by the compiler is at odds with the dynamic runtime stack used by p-code. Your mixed compiler / interpreter system would need to emulate a bigger register based processor as the kernel of your interpreter (e.g. subset of TI9900). Your native PIC compiled code would then be able to operate on the interpreter emulated registers as though they were variables belonging to the app the user wrote. e.g. byte j int a, b[5], c[5] a = b[j+1] + c[j+1] incf j,w ; native PIC code movwf ireg1+1 ; access interp kernel R1 clrf ireg1+1 call interp ; <-- enter interp mode mov R0, b(R1) ; ti9900 code add R0, c(R1) mov a, R0 bl R11 ; <-- exit interp mode MOST importantly you should be able to enter and exit the emulated processor and modify the emulated registers directly in native mode without needing to change the execution context of the emulated processor (e.g. setup a stack pointer or stack frame before entry, or clean up the stack on exit). 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