Searching \ for '[OT] Re: Interpreter Engine' 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=interpreter+engine
Search entire site for: 'Re: Interpreter Engine'.

Exact match. Not showing close matches.
PICList Thread
'[OT] Re: Interpreter Engine'
1998\12\03@152335 by Rob

flavicon
face
On Thu, 3 Dec 1998, Andy Kunz wrote:

> I posted this yesterday, but no takers.  Maybe I should have said something
> to get your ire up so you could flame me?  <G>
>
> I need an interpreter for a 14-bit core which can be incorporated as part
> of a time-critical program which already exists.
>

You need to politicize this more.  Here is one idea:

1) I need a right wing interpreter for a core of socialists that can be
incorporated as part of a United Nations time critical program which
exists to overthrow all governments as we know it.

there, that oughta get plenty of responses!

Rob
(helping the list traffic one posting at a time)

1998\12\03@160658 by Zonn

flavicon
face
On Thu, 3 Dec 1998 15:20:05 -0500, Rob <spam_OUTrobzsTakeThisOuTspamHICOM.NET> wrote:

>On Thu, 3 Dec 1998, Andy Kunz wrote:
>
>> I posted this yesterday, but no takers.  Maybe I should have said something
>> to get your ire up so you could flame me?  <G>
>>
>> I need an interpreter for a 14-bit core which can be incorporated as part
>> of a time-critical program which already exists.
>>
>
>You need to politicize this more.  Here is one idea:
>
>1) I need a right wing interpreter for a core of socialists that can be
>incorporated as part of a United Nations time critical program which
>exists to overthrow all governments as we know it.
>
>there, that oughta get plenty of responses!

Hmmm...  You might have to go with an Intel (tm) Pentium Pro II (tm) processor,
running Windows 98 (tm), using Internet Explorer (tm) to run interpretive Java
(tm), to accomplish that.

-Zonn (tm)

<><><><><><><><><><><><><><><><><><><><><><><><><><><><

------              ___       Member of A.A.C.S.:
|---- |            (   )  Association for Artistically
   / /            ( () )     Challenged Signatures
  / /    //\\ //   (__)
 / ---/ //  \\    //\\ //      zonn @ zonn . com
-------|         //  \\/

1998\12\05@055828 by Peter L. Peres

picon face
On Thu, 3 Dec 1998, Rob wrote:

> On Thu, 3 Dec 1998, Andy Kunz wrote:
>
> > I posted this yesterday, but no takers.  Maybe I should have said something
> > to get your ire up so you could flame me?  <G>
> >
> > I need an interpreter for a 14-bit core which can be incorporated as part
> > of a time-critical program which already exists.
> >
>
> You need to politicize this more.  Here is one idea:
>
> 1) I need a right wing interpreter for a core of socialists that can be
> incorporated as part of a United Nations time critical program which
> exists to overthrow all governments as we know it.
>
> there, that oughta get plenty of responses!

Couldn't you just post an 'unsubscribe' mmessage like everyonw else, and
be sure of plenty of answers ? ;)

Btw, I understand exactly what Andy wants, and I did have something like
this for Z80 so I've been there.

Andy, if you feel strong, try to write it from scratch. It is not hard.
You have an instruction register that is filled from external E^2 and a
set of 8-16 operations to be done. A flag register holds the state of what
you are doing. In my thing I had a FORTH-like machine with five
arithmetical and four logical operators, four shifts, and three branch on
condition opcodes, plus an implicitly addressed input opcode (from
internal registers) and an output opcode (to the same registers).

Whenever an interrupt caught me in the middle the machine stopped and lost
major parts of its accumulator etc, served the interrupt, and re-entered
the interpreter to read the flags and the opcode and proceed.

The stack was very shallow (2 deep ;) and all ops were on 8 bits. In case
you haven't guessed yet, all these registers lived in the Z80's alternate
register set, as there was no RAM ;) ;)

hope this helps,

Peter

1998\12\05@084031 by Peter L. Peres

picon face
On Thu, 3 Dec 1998, Zonn wrote:

> Hmmm...  You might have to go with an Intel (tm) Pentium Pro II (tm) processor
,
> running Windows 98 (tm), using Internet Explorer (tm) to run interpretive Java
> (tm), to accomplish that.
>
> -Zonn (tm)

Now, *this* will get you even more responses than an unsubscibe troll ! ;)

Peter

1998\12\05@123133 by Stig Brautaset
flavicon
face
> -----Original Message-----
> From: pic microcontroller discussion list
> [.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU]On Behalf Of Peter L. Peres
> Sent: Saturday, December 05, 1998 2:04 PM
> To: PICLISTspamKILLspamMITVMA.MIT.EDU
> Subject: Re: [OT] Re: Interpreter Engine
>
>
> On Thu, 3 Dec 1998, Zonn wrote:
>
> > Hmmm...  You might have to go with an Intel (tm) Pentium Pro II

Hmmm.
Pentium Pro (tm) + Pentium MMX (tm) = Pentium II (tm)   :-)

Stig

=======================================================
Stig Brautaset - .....sbrautasKILLspamspam.....c2i.net - ICQ:11052183
Student of electronics  -  http://home.c2i.net/sbrautas
=======================================================

> Now, *this* will get you even more responses than an unsubscribe troll !
;)

I believe so!

1998\12\05@185017 by Lynx {Glenn Jones}

flavicon
face
I am looking for this type of thing for an AT90S1200, but as i have seen
none prewritten, i think ill have to do the job myself. Everything seems
like it shouldnt be hard, but how about the branching instructions. I am
thinking of having a 24C32 SEEPROM hold a series of 16-bit instructions
(so many bits for the intruction and so many for the argument(s)), but in
this case id have to have a 11 bit pointer (4096 bytes/2=2^11 locations),
but that only leaves 5 bits for the command, leaving me only 32 commands
maximum. Also, what if a command needs two 8-bit arguments?

{Quote hidden}

1998\12\06@070222 by paulb

flavicon
face
Lynx {Glenn Jones} wrote:

> Everything seems like it shouldnt be hard, but how about the branching
> instructions. ... I'd have to have a 11 bit pointer (4096 bytes/2=2^11
> locations), but that only leaves 5 bits for the command, leaving me
> only 32 commands maximum.

 Look at the PIC, and the 6800, for clues.  Only two jumps use the full
address range (JMP and JSR).  Conditional branches are relative and
signed, using only 8 address bits (or indeed it could be less).

> Also, what if a command needs two 8-bit arguments?

 Use a different command.
--
 Cheers,
       Paul B.

1998\12\06@114510 by Peter L. Peres

picon face
On Sat, 5 Dec 1998, Lynx {Glenn Jones} wrote:

> I am looking for this type of thing for an AT90S1200, but as i have seen
> none prewritten, i think ill have to do the job myself. Everything seems
> like it shouldnt be hard, but how about the branching instructions. I am
> thinking of having a 24C32 SEEPROM hold a series of 16-bit instructions
> (so many bits for the intruction and so many for the argument(s)), but in
> this case id have to have a 11 bit pointer (4096 bytes/2=2^11 locations),
> but that only leaves 5 bits for the command, leaving me only 32 commands
> maximum. Also, what if a command needs two 8-bit arguments?

a) The PIC has 32 commands and they are enough ;)

b) You have 2^32 keys that can have a 11-bit implicit operand but no-one
said you have to use them like this. Select 4 keys with 11-bit operands
for branches and stay with 2^16 - 4*2^11 = 2^16 - 2^13 = 48k keys for
other operations. Assuming all the other ops have an implicit 8-bit
argument this leaves you with 48k/2^8 possible opcodes. I believe that
there are enough of them for most any purpose ? ;) ( == 192 opcodes plus
4 for branches = 196 opcodes).

Commands that need 'long' arguments are usually coded with a prefix.  The
prefix is a fixed code that means 'literal of size XX follows', or can be
a proper opcode. The code executor sees this, shifts state, and then
fetches the argument of specified size from the code stream (can be many
bytes long). See the FPU programming in assembly for x86 processors, and
most extended indirect addressing opcodes on most any processor.

FORTH is the only language that uses 'unmarked' numbers (actually marked
by the fact that they are numbers) and pushes them on the stack w/o asking
questions, first of all. But even compiled FORTH uses a literal number
marker in the code stream, and even the FORTH interpreter uses the lexer
output (number seen) for the exact same purpose.

Peter

1998\12\06@122704 by Dave VanHorn

flavicon
face
I did an interpreter in an '84 recently.

I stored the commands and parameters in the EEPROM area, as
(command)(parm)(parm)....
Each command may have zero, one or N bytes of paramter
I used a register to point to the current command. (0-63 bytes)
I also have an "execute/scan" flag

Starting from reset, the first command is in byte zero, so I load that
value from EEPROM, and then jump to the command engine, with the execute
flag set to execute.

In the execute mode, the command engine simply uses the parm bytes, does
it's thing, and exits with the pointer set to the next command, which of
course follows the first (and it's parms) immediately.

Scan only becomes useful when you branch. I used a simple "skip"
command, followed by the number of commands to skip. Some other commands
also caused branching, like "Skip N if input is active" where N could be
+ or -

In order to branch forward, we simply scan commands until we locate the
Nth command. Starting wherever we currently are, we set a register to
the number of commands to skip, and look at the next command (This is
always the next byte in EEPROM, as the current command would have
interpreted it's parms already.) We set the execute/scan flag to scan,
and call the appropriate command engine. Each command engine knows
wether the command has a parameter, and how long it is. In the case of a
variable length command parm, then the command engine scans forward till
it finds a null (end of parm marker) and returns the address of the next
command (null address +1) In the case of fixed length commands, it
simply increments the pointer and returns.
After each command returns, we decrement the skip register, and when it
is zero, we set the execute/scan flag to execute, and call the next
command.

Branching in reverse is a little more interesting, actually, you can't,
because the parms are variable length. How would you know to find the
previous command? (Without wasting memory on flags!)

What I did to implement this is to dedicate another register to hold the
current command number.
This is incremented during scan or execute. When I encounter a negative
skip, then I subtract the appropriate number from the current command
register, set thc scan/execute flag to scan, and then start from zero
and scan forward to command X-N, and set the scan/execute flag back to
execute, and carry on.

The commands are sanity checked, in that any address that's outside the
EEPROM causes a reset to zero. Something like Skip -10 at command 5
would be trapped this way, without the skip command engine having to
test the parm for positional sanity.

The parms are the responsibility of the command engines, and in this
implementation, I relied on a PC loader program to convert user input to
binary, and to sanity-check the values, so the command engines simply
"shut up and soldier"

I wedged this interpreter engine, an ASCII to morse converter, and a
bunch of fun commands, a uart (to talk to the loader) all into an '84.
You can see the docs for this system at http://www.agrelo.com/upll.html

1998\12\06@150040 by Marc

flavicon
face
> I am looking for this type of thing for an AT90S1200, but as i have seen
> none prewritten, i think ill have to do the job myself. Everything seems
> like it shouldnt be hard, but how about the branching instructions. I am
> thinking of having a 24C32 SEEPROM hold a series of 16-bit instructions
> (so many bits for the intruction and so many for the argument(s)), but in
> this case id have to have a 11 bit pointer (4096 bytes/2=2^11 locations),
> but that only leaves 5 bits for the command, leaving me only 32 commands
> maximum. Also, what if a command needs two 8-bit arguments?

I have designed a small interpretative language in C for an 8051 project
once.  It supports loops, if/then/else and all the basic stuff you need
to write scripts. But it can be tokenized easy, and the interpreter core
is very small. C-like functions (several arguments, one result) can
be added and used in the script everywhere.

In that language, I used 8 bit tokens. Every command is 8 bits wide.
Additional bytes can be added when required (arguments usually). Some
commands offer storage space in their token, such as

       "STORE TO VAR"  token: b'010xxxxx

It stores something in one of 32 8-bit variables (xxxxx is the index to
the var-memory). What is to be stored is defined in the following byte.
It either is

       another variables content       000xxxxx

       or an 8 bit literal             00100000 xxxxxxxx
       or an 6 bit literal             01xxxxxx

       or one of 128 functions         1xxxxxxx ...
       (...) are 0-N arguments, depending on function

Other stuff can be placed into the 001xxxxx range, such as IO registers.
My script language was really a script language, not a stamp replacement :-)


All those lookups/functioncalls resulted in an 8 bit result, which could
then be stored/added/forwarded to a function/etc. That was the key thing of
the language. It was compact, yet very flexible due to that fact.

Gotos were just another opcode, like
       b'000xxxxx              5 bit relative
       b'001xxxxx xxxxxxxx     13 bit relative

The destination of the last write (usually a var) was remembered. A lot
of commands just accessed that last destination, to save bit space in
the opcode field.  For example the ADD command:

       b'11100000' <value>

evaluates the following value (as above, one or several bytes depending
on type) to an 8 bit result, and ADDs that to the last write destination.

Stuff like      = A +5 - testfunc(3,1);    was encoded to

       CLR A
       ADD literal 5
       SUB function# of testfunc, 3, 1

(7 bytes)

Straigt and easy tokenizer, but a little unfamiliar look (=A instead of A=).

Easy shortcuts such as

       ++;

to increment the last write destination made script writing a convenient
job.

1998\12\06@151319 by Lynx {Glenn Jones}

flavicon
face
Well, thank you all for your input. I think what im going to do is make a
tiny RPN style stack calculator, mainly because i love RPN and i am very
experienced with it. Thanks again.

------------------------------------------------------------------------------
A member of the PI-100 Club:
3.1415926535897932384626433832795028841971693993751
058209749445923078164062862089986280348253421170679

1998\12\06@212614 by Marc

flavicon
face
> Branching in reverse is a little more interesting, actually, you can't,
> because the parms are variable length. How would you know to find the
> previous command? (Without wasting memory on flags!)
>
> [...]
>
> The parms are the responsibility of the command engines, and in this
> implementation, I relied on a PC loader program to convert user input to
> binary, and to sanity-check the values, so the command engines simply
> "shut up and soldier"

I wonder why on one hand you rely on the PC tokenizer to supply you with
syntax checked data, and on the other hand not simply store the EEPROM
address of the SKIP destination (precomputed by the tokenizer).

BTW That would also give the extra benefit of Labels & GOTO.

1998\12\06@220540 by Dave VanHorn

flavicon
face
> I wonder why on one hand you rely on the PC tokenizer to supply you with
> syntax checked data, and on the other hand not simply store the EEPROM
> address of the SKIP destination (precomputed by the tokenizer).
>
> BTW That would also give the extra benefit of Labels & GOTO.


Didn't think of it.

1998\12\06@220604 by Dave VanHorn

flavicon
face
> I wonder why on one hand you rely on the PC tokenizer to supply you with
> syntax checked data, and on the other hand not simply store the EEPROM
> address of the SKIP destination (precomputed by the tokenizer).
>
> BTW That would also give the extra benefit of Labels & GOTO.


I should add that the time from "so this is a pic" to release was six
weeks.

1998\12\07@182551 by John Payson

flavicon
face
|Well, thank you all for your input. I think what im going to do is make a
|tiny RPN style stack calculator, mainly because i love RPN and i am very
|experienced with it. Thanks again.

I was thinking of doing something sorta PostScript-ish.  All data
would be integers (unlike PS's strong typing) but other things would
remain largely as in PS.  For example, if I wanted to set "c" equal
to the maximum of a or b, the code would be something like:

       a b gt {/c a set} {/c b set} ifelse

The {} operator places the routine inside (actually a pointer to it) on
the operand stack, and the ifelse function selects one of the top two
items off the stack based upon the contents of the third one (popping
all three items) and then executes it.  The "a" and "b", without any
punctuation before them, push the contents of those variables while the
"/c" (with the slash) pushes the address.

Depending upon the desired speed/codesize tradeoffs, the "{" could either
be handled by the compiler (and replaced with the literal address where the
code resides) or by the interpreter (in which case it should push the address
following the "{" on the operand stack and then search for the matching "}".)
Although pushing the code address would probably require one more byte than
using the "{" and "}" operators, the PC-based scanner would be able to look
for {}'s containing identical code and delete all but one copy--this could
easily save for memory than the pushed addresses take.


Attachment converted: wonderland:WINMAIL.DAT (????/----) (00020B39)

1998\12\08@025328 by Antti Lukats

flavicon
face
there are several interpreter engines done for AT90S1200, one of
them comes with full source code

antti



On Sat, 5 Dec 1998, Lynx {Glenn Jones} wrote:

{Quote hidden}

1998\12\10@220252 by Javier

flavicon
face
Sorry, but what is RPN ??
Thanks
Javier

-----Mensaje original-----
De: Lynx {Glenn Jones} <EraseMEjones_glspam_OUTspamTakeThisOuTEFN.ORG>
Para: PICLISTspamspam_OUTMITVMA.MIT.EDU <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Fecha: Domingo 6 de Diciembre de 1998 17:11 p.m.
Asunto: Re: [OT] Re: Interpreter Engine


>Well, thank you all for your input. I think what im going to do is make a
>tiny RPN style stack calculator, mainly because i love RPN and i am very
>experienced with it. Thanks again.
>
>---------------------------------------------------------------------------
---
>A member of the PI-100 Club:
>3.1415926535897932384626433832795028841971693993751
>058209749445923078164062862089986280348253421170679

1998\12\10@221739 by beking

picon face
Reverse Polish Notion.  A very efficient stack based postfix expression
syntax.  Made particularly popular way back by Hewlett Packard handheld
calculators.  How's 13 instructions on an HP-67C using a tweaked sieve
method for calcualting primes?


Regards,

Barry

{Quote hidden}

1998\12\10@231329 by Lynx {Glenn Jones}

flavicon
face
Reverse Polish Notation. you have a stack on which you perform operations,
for example, if i want to do the algebraic notation 2+2, i use the
folowing command sequence
2 <enter>
2 <+>
and i get back 4. its more eficiant, espescially when it comes to Big
algebraic equations like ((x+1)^2)/((x-1)^2)
for an interpreter engine Id have the various stack levels be represented
by registers, then have operations which could be performed on them.

------------------------------------------------------------------------------
A member of the PI-100 Club:
3.1415926535897932384626433832795028841971693993751
058209749445923078164062862089986280348253421170679

On Sat, 10 Jan 1998, Javier wrote:

{Quote hidden}

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