Hi, John! It is almost impossible to prevent your code from being stolen,=20 regardless of the processor or scheme. In the olden days, before we began living in glass houses, we ground off=20 the programming pins after we programmed the PIC, but nowadays the code=20 can be read by nefarious companies who probe the raw chip. The entire chip fab process needs to be rethought such that the cost to=20 steal code becomes excessive. Burying the actual chip layout under=20 several silicon layers wouldn't hurt, as would obscuring key sections of=20 the chip. Its possible that a thin insulating layer that also obscured=20 anything below it might be enough, because any effort to break through=20 the obscuring layer would cause the chip itself to be broken in the process= .. --Bob A --=20 >> On May 28, 2014, at 7:59 AM, Isaac Marino Bavaresco wrote: >> >> Em 28/05/2014 08:58, Byron Jeff escreveu: >>> Actually this sort of changes my mind on it (which is why I prefaced th= e >>> entire statement with "may or may not" to begin with...). Since tokens = were >>> in a different space than values, it's trivial to determine that the fi= rst >>> token after an end is a variable if the top bit is not set. >>> >>> That would make the LET redundant, and clearly occupying valuable space= .. >>> >>> BTW I too wish that I had come across FORTH early on instead of 6 or so >>> years ago. I'm in the process of putting together a completely self hos= ted >>> FORTH development system for the PIC24F series of chips. It would have >>> saved me the trouble of trying to write my own tokenized C-like >>> cross-compiler oh so many years ago. >> >> I too am in a pursuit for some sort of interpreted/scripting language >> for embedded systems for a long time. >> >> My motivation it to allow the users of my boards to customize their >> operation or write their own routines. The problem is that I don't want >> them to be able to run native code because it would allow someone to >> steal my own code. >> That protection could be done with dsPIC's CodeGuard, but it is not >> available for other platforms, and I don't know how secure it is indeed. >> >> Some years ago, I tried XPL0 (). It is a language >> created in 1976 by Peter J. R. Boyle and maintained by Loren Blaney. >> There is a compiler that generates 80x86 code and another that generates >> a psudo-code called I2L. The original I2L interpreter was written in >> 80x86 assembly and I wrote a very portable new one in C to use in my >> boards. The performance was acceptable, although not great. >> It worked, but I wasn't satisfied with the fact that it is one more >> language to be learned and it is very obscure. That would prevent its >> adoption by my customers. >> >> I'm working now in a Thumb emulator written in C, that can be compiled >> for a lot of platforms (even 8-bit, although the performance would be >> awful). This emulator creates a virtual ARM processor (Thumb1 >> instructions only) that won't allow any access outside its private >> memory pool. System calls, common library functions and other predefined >> operations are implemented natively and called with the Thumb "svc" >> instruction. >> >> I managed to convince the ARM-GCC to generate code for this virtual >> processor and it seems very promising. The user's applications can be >> written in any language with a compiler that generates Thumb code. >> >> Right now I don't have time to polish it, but I'm excited about the >> possibilities. >> >> Isaac >> >> >> >> >> --=20 >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .