Searching \ for 'Is it realy necessary to use an interpreter?' 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/index.htm?key=realy+necessary
Search entire site for: 'Is it realy necessary to use an interpreter?'.

Truncated match.
PICList Thread
'Is it realy necessary to use an interpreter?'
1998\09\11@162519 by Daniel Hjorth

flavicon
face
part 0 1392 bytes
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Please help me understand something
here...........</FONT></DIV>
<DIV><FONT color=#000000 size=2>If want to use a EEPROM(24C26) memory instead of
burning my program </FONT></DIV>
<DIV><FONT color=#000000 size=2>into a PIC(16C55) directly, do I need an
interpreter on the PIC if I compile the basicprogram into HEX before upload it
to the EEmemory?????</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 size=2>Or is the interpreter necessary to make the pic
work with its instructions</FONT></DIV>
<DIV><FONT color=#000000 size=2>stored on the memorychip? (I don't think so... I
meen it's allready in machinelanguage.)</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 size=2>/DeeAitch</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 size=2>&nbsp; </FONT></DIV></BODY></HTML>

</x-html>

1998\09\11@163957 by William Chops Westfield

face picon face
   Please help me understand something here...........  If want to use a
   EEPROM(24C26) memory instead of burning my program into a PIC(16C55)
   directly, do I need an interpreter on the PIC if I compile the
   basicprogram into HEX before upload it to the EEmemory?????

   Or is the interpreter necessary to make the pic work with its
   instructions stored on the memorychip? (I don't think so... I meen
   it's allready in machinelanguage.)

The (smallish) PICs are NOT capable of directly executing instructions from
external memory.  Therefore, the only way to use external memory is to
interpret tokens that are stored there.  Machine language is one possible
type of token, but it doesn't offer very many advantages (since the PIC has
no XCT instruction, nor an ability to execute from (internal) RAM, nor an
ability to do any kind of self-modifying code.  Machine language DOES have
disadvantages - it's 12 bits wide, and not very efficient.  As I've said
before, one of the "successes" of the basic stamp is that the creators
succeeded in defineing a particularly useful small set of primitives.

Additionally, I don't know of ANY processor that can access instructions
from serially accessed program memory - that's sort of the antithesis of
what microprocesor designers use to make things fast.

Now, a downloadable PIC with on-chip instruction RAM (rather like FPGAs)
would be a somewhat interesting beast...

BillW

1998\09\12@072258 by Dr. Imre Bartfai

flavicon
face
Hi,

Dave Dunfield (http://www.dunfield.com) has developped a virtual  machine
language called C-FLEA. It is an assembly for a non-existing processor.
However, he says, the machine code of this non-existing processor is
really easy to interpret so he offers a lot of interpreters for different
uP -s. If I recall for PIC also. He says further, the bytecode can be
stored also in serial EEPROM or whatever you want.

Imre


On Fri, 11 Sep 1998, William Chops Westfield wrote:

{Quote hidden}

1998\09\12@075015 by Peter L. Peres

picon face
 Sorry, I oopsed my mailbatch this morning so I must have missed a few
postings. Please correct me if my answers are way off. See my answer to
this message further below:

On Sat, 12 Sep 1998, Dr. Imre Bartfai wrote:

> However, he says, the machine code of this non-existing processor is
> really easy to interpret so he offers a lot of interpreters for different
> uP -s. If I recall for PIC also. He says further, the bytecode can be
> stored also in serial EEPROM or whatever you want.

Almost everyone who has run into the problem of storing a program after
production into a micro too small to have flash or a disk has invented
such a language. Very few people have published theirs for obvious
reasons. Most GSM phones for example, use just such a system although
they have flash on board...

> > The (smallish) PICs are NOT capable of directly executing instructions from
> > external memory.  Therefore, the only way to use external memory is to
> > interpret tokens that are stored there.  Machine language is one possible
> > type of token, but it doesn't offer very many advantages (since the PIC has

The trick of trying to implement an emulator of itself on any processor
is an exercise meant to open one's eyes to the problems that will occur
when an optimized language is to be devised for it, no more. That is why I
advocate (and use) this method every time I have to do such a thing and
have no previous information. It need not be done from A to Z but the
little pieces of paper that result will be worth your while when making
decisions about the more optimized language later...

> > Additionally, I don't know of ANY processor that can access instructions
> > from serially accessed program memory - that's sort of the antithesis of
> > what microprocesor designers use to make things fast.

There are some I think. All have caches of some sort inside however and
are much larger than a PIC. I think that the microprocessor FAQ (available
on the Web) carries a few references.

Peter

1998\09\12@112051 by Morgan Olsson

picon face
>> > Additionally, I don't know of ANY processor that can access instructions
>> > from serially accessed program memory - that's sort of the antithesis of
>> > what microprocesor designers use to make things fast.
>
>There are some I think. All have caches of some sort inside however and
>are much larger than a PIC. I think that the microprocessor FAQ (available
>on the Web) carries a few references.
>
>Peter
>
Texas Instruments make some little low power measurement specialised
processor with inbuilt A/D, current source etc which is if i remember
correct *intended* for reading it«s application specific program from an
external serial EEPROM.

Let me dig a moment...

Ah, here:
TSS400: 4-bit CMOS signal processor with 12bit D/A, LCD drive, etc.
Basic version is mask programmed. Two sizes: 2 or 4 ROM with 575 or 960 bit
RAM in 9 or 15 banks of 16 nibbles <G>
There is a standard version preprogrammed with an interpreter to read macro
commands from external EEPROM.  there!

available in one to plenty units. think it is cheap too?
hmmm... will look closer at it some time.
/Morgan

/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
\  spam_OUTmrtTakeThisOuTspaminame.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /

1998\09\13@193639 by Antonio L Benci

flavicon
picon face
Lets see, Stamp and Stamp II plus FEDBASIC. No doubt others which at
this point I cant recall. All of which do a good job considering the
access time for serial memory configurations. All utilise a caching
system for speed and optimum performance is achived by clever use of
subroutines and constructs. Yes I know these use interpreters but lets
face the fact, the interpreter reduces the development overhead and
although absolute speed is not what these little beasts are about, ease
of development is their biggest advantage...

Morgan Olsson wrote:
{Quote hidden}

A very specialised signals processor, not really tailored for general
purpose use...

>
> available in one to plenty units. think it is cheap too?
> hmmm... will look closer at it some time.
> /Morgan
>
> /  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
> \  .....mrtKILLspamspam@spam@iname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /

Nino...
--
******************************************************
* Antonio (Nino) Benci                               *
* Electronic Services Manager                        *
* Monash University - Dept of Physics                *
* Wellington Rd, Clayton. 3168                       *
* Victoria, Australia.                               *
* TEL - 61 3 9905 3649, FAX - 61 3 9905 3637         *
* EMAIL - nino.bencispamKILLspamsci.monash.edu.au (work)        *
*       - .....fleatechKILLspamspam.....mailexcite.com (private)          *
* WWW   - http://www.physics.monash.edu.au/                 *
******************************************************

1998\09\14@075308 by John Kirk

flavicon
face
Hi!  I had a similar problem in that we had a prototype working with a
compilied basic program loaded on a PIC 16C58A.   We researched the issue
and, basically, you have to incorporate the basic interpeter with your basic
program.   As a result I had to create a assembly language program that
duplicated the basic one.    It wasn't that hard for this application, and
the working basic prototype always told me EXACTLY how the assembly program
was supposed to behave.  Hope this helps: John Kirk

> {Original Message removed}

1998\09\14@081637 by Stuart Allen

flavicon
face
> -----Original Message-----
> From: Daniel Hjorth [SMTP:EraseMEdaniel.hjorthspam_OUTspamTakeThisOuTSWIPNET.SE]
> Sent: Friday, September 11, 1998 4:19 PM
> To:   PICLISTspamspam_OUTMITVMA.MIT.EDU
> Subject:      Is it realy necessary to use an interpreter?
>
> Please help me understand something here...........
> If want to use a EEPROM(24C26) memory instead of burning my program
> into a PIC(16C55) directly, do I need an interpreter on the PIC if I
> compile the basicprogram into HEX before upload it to the EEmemory?????
> Ê
> Or is the interpreter necessary to make the pic work with its
instructions
> stored on the memorychip? (I don't think so... I meen it's allready in
> machinelanguage.)
> Ê
> /DeeAitch
> Ê
> Ê

Hello,

The EEPROM can't be part of the PIC address space (on the low end PICs
atleast), so the PIC has to read the EEPROM via a software driver.

So lets say you have the HEX in EEPROM and you read in the first instruction
(via your software), what are you going to do with it? Whether its in W or
SRAM it doesn't matter, there is no way to execute that code. And what if
you could execute it? Well the PIC would do exactly what that instruction
tells it to do, it would jump off somewhere, set a port bit, whatever and it
would crash - the rest of the program is in EEPROM.

It would be nice if you could, for example, download entire code segments
from EEPROM and then execute them, a bit like reconfigurable FPGAs.
Effective program memory size could be increased albeit with a supervisor -
unfortunately, as program memory is ROM too and due to the PICs harvard
architecture, you can't to that either.

An interpreter could be quite straightforward to implement, but it is very
dependant on how flexible and fast it needs to be - implementation is very
application dependant

Stuart.

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