Searching \ for '[PIC] P-code/Toeknizer (was: C syntax in assembler' 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/microchip/languages.htm?key=c
Search entire site for: 'P-code/Toeknizer (was: C syntax in assembler'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] P-code/Toeknizer (was: C syntax in assembler'
2011\01\01@222308 by Neil Cherry

flavicon
face
On 01/01/2011 10:03 PM, William "Chops" Westfield wrote:

> Whatever happened to P-code (for pascal), anyway?  It seems (?) that  
> interpreters in general have advanced in the relatively recent past;  
> were there enough advantages in the p-code runtime environment to  
> think about doing that again, or have the (older) advances made in  
> compiler technology made it uninteresting anyway?  (I never noticed  
> whether P-code added run-time capabilities to a typical CPU, or was  
> just a crutch so people wouldn't have to write code generators.)

Odd you should mention it, I've been thinking about doing a BASIC
stamp like environment for a few networked uCs. So far I've not
gotten past taking a look at some tokenizers and wondering if this
is such a good idea.

-- Linux Home Automation         Neil Cherry       spam_OUTncherryTakeThisOuTspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummie

2011\01\02@002114 by Harold Hallikainen

face
flavicon
face

> On 01/01/2011 10:03 PM, William "Chops" Westfield wrote:
>
>> Whatever happened to P-code (for pascal), anyway?  It seems (?) that
>> interpreters in general have advanced in the relatively recent past;
>> were there enough advantages in the p-code runtime environment to
>> think about doing that again, or have the (older) advances made in
>> compiler technology made it uninteresting anyway?  (I never noticed
>> whether P-code added run-time capabilities to a typical CPU, or was
>> just a crutch so people wouldn't have to write code generators.)
>
> Odd you should mention it, I've been thinking about doing a BASIC
> stamp like environment for a few networked uCs. So far I've not
> gotten past taking a look at some tokenizers and wondering if this
> is such a good idea.
>

Wasn't the p-code idea to give portability? Isn't a similar thing now done
in Java? Many years ago, I did a lot of work with the Microsoft 6800 Basic
interpreter. After each line was keyed in, the line was tokenized,
converting known key words to single bytes with the msb set. When the
program was run, these tokens would index into a jump table to call the
appropriate code for the desired function. Only key words were tokenized.
Text strings and literals stayed as ascii. In interpreting math, it did
recursive calls to the inner most parenthesis, then evaluated its way back
out. Line numbers were stored as a 16 bit number at the start of the line.
The next byte was the length of the line. A goto or gosub would cause the
interpreter to search from the beginning if the destination line number
was less than the current line number, or from the current position if the
destination was a higher line number than the current line. Returns and
for/next loops stored the actual address to return to. This allowed
returns to the middle of multi-statement lines (and was faster). All in
all, it was interesting code to work with.

Harold



-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\01\02@030536 by Tamas Rudnai

face picon face
On Sun, Jan 2, 2011 at 5:21 AM, Harold Hallikainen
<.....haroldKILLspamspam@spam@hallikainen.org>wrote:

> Wasn't the p-code idea to give portability? Isn't a similar thing now done
> in Java?


That is exactly my point too -- AppleSoft Basic was ding the same as .NET
and JavaVM including garbage collection...



> Many years ago, I did a lot of work with the Microsoft 6800 Basic
> interpreter. After each line was keyed in, the line was tokenized,
> converting known key words to single bytes with the msb set. When the
> program was run, these tokens would index into a jump table to call the
> appropriate code for the desired function. Only key words were tokenized.
>
....

Everything you wrote is exactly how AppleSoft Basic works! That was
developed by Microsoft if I am not mistaken, so I can imagine they were only
implementing the existing code from the 6502 to the 68000. By that time it
was not in their mind to make the code portable, but to save memory (Apple
II had only 64k address space where the ROM occupied 12k and 4k of I/O
address space, giving you a max of 48k RAM). There were financial softwares
running on that comp! The interesting thing is that now we have faster and
bigger microcontrollers, and we are still crying for bigger and faster ones
even though not developing financial softwares on them :D

Tama

2011\01\02@081051 by alan.b.pearce

face picon face
> > On 01/01/2011 10:03 PM, William "Chops" Westfield wrote:
> >
> >> Whatever happened to P-code (for pascal), anyway?  It seems (?) that
> >> interpreters in general have advanced in the relatively recent past;
> >> were there enough advantages in the p-code runtime environment to
> >> think about doing that again, or have the (older) advances made in
> >> compiler technology made it uninteresting anyway?  (I never noticed
> >> whether P-code added run-time capabilities to a typical CPU, or was
> >> just a crutch so people wouldn't have to write code generators.)
> >
> > Odd you should mention it, I've been thinking about doing a BASIC
> > stamp like environment for a few networked uCs. So far I've not
> > gotten past taking a look at some tokenizers and wondering if this
> > is such a good idea.
> >
>
> Wasn't the p-code idea to give portability?
Yeah, UCSD Pascal was the one that proclaimed P-Code as the 'new way' and had versions for C/PM compatible machines, and I think a 6800 based machine. Then along came the IBM PC, and everyone said 'I already have the development system for my C/PM compatible, I just want to purchase the runtime module for the IBM PC' and UCSD said 'No to get that you need to purchase the whole development system for the PC' which made it an instant Lead Balloon (TM). I don't know how long UCSD Pascal kept going, but that was a prime mistake on their part.
-- Scanned by iCritical.

2011\01\02@133825 by Bob Ammerman

flavicon
face
> That is exactly my point too -- AppleSoft Basic was ding the same as .NET
> and JavaVM including garbage collection...

Actually, AppleSoft (and many other forms of) Basic simply tokenized keywords. The code was still interpreted from the thus-tokenized source.

True p-Code was used by the UCSD Pascal system. The Pascal source was compiled to the machine language of a virtual machine (the P-machine) which was then emulated by an interpreter. Modern p-Code-like systems include Java and .Net, both of which often get closer-to-native performance by using a backend code generator (ofter a Just-In-Time (JIT) compiler) to convert the p-Code to native machine language.

-- Bob Ammerman
RAm Systems

2011\01\03@030136 by Tamas Rudnai

face picon face
On Sun, Jan 2, 2011 at 6:38 PM, Bob Ammerman <rvammermanspamKILLspamroadrunner.com>wrote:

> Modern p-Code-like systems include Java
> and .Net, both of which often get closer-to-native performance by using a
> backend code generator (ofter a Just-In-Time (JIT) compiler) to convert the
> p-Code to native machine language.
>

That technology only makes it faster, but will never get any close to a
native application in terms of speed. .NET is actually not too bad, but
still, far from a native speed.

What they should do is to compile the code when installing the software and
job is done. Maybe installation would be much slower, so they could cache
the binaries of the most popular platforms to help on it -- so then they are
slowly going back to the traditional cross compilation procedure what Linux
is doing today :-)

Tama

2011\01\03@102110 by Bob Ammerman

flavicon
face

{Quote hidden}

..NET actually supports pre-compiling to machine language, either at development time or installation time. However, very few people bother to use this as it generates (IIUC) the same code as the Jitter, but requires a lot more hassle. Under normal circumstances the Jitter only runs the first time a method is called, and even then it is pretty fast.

-- Bob Ammerman
RAm Systems

2011\01\03@122313 by Bob Ammerman

flavicon
face
> .NET actually supports pre-compiling to machine language, either at
> development time or installation time. However, very few people bother to
> use this as it generates (IIUC) the same code as the Jitter, but requires
> a
> lot more hassle. Under normal circumstances the Jitter only runs the first
> time a method is called, and even then it is pretty fast.
>
> -- Bob Ammerman
> RAm Systems

Responding to my own post...

I incorrectly stated that the translation to native code could happen at development time. I apparently am mistaken. It can only be done at (or after) installation on a target computer. See the "NGEN" utility.

-- Bob Ammerman
RAm  Systems

2011\01\03@130121 by Pete Restall

flavicon
face
On Mon, 3 Jan 2011 08:01:35 +0000, Tamas Rudnai wrote:

> What they should do is to compile the code when installing the
> software and job is done. Maybe installation would be much slower, so
> they could cache the binaries of the most popular platforms to help on
> it -- so then they are slowly going back to the traditional cross
> compilation procedure what Linux is doing today :-)

I believe the MS JIT compiler compiles a method at a time; the hit is
taken the first time the method is called.  There are pre-compilers,
such as ngen, that allow you to pre-compile, but they don't tend to be
used - the main way I've seen them used is for pre-compiling high-volume
websites so that the first hit doesn't trigger a huge JITting spree and
load the server down.

Pre-compiling at installation time is very suboptimal; you lose the
benefit of software upgrades to the JIT compiler, which could result in
tighter or more secure code being generated, etc.  You would have to
install everything, too - no good for plugins and the like, where you
should just be able to 'xcopy' deploy DLLs.  And you are also left with
a sub-optimal executable image if you were to change your processor or
other hardware.  Not to mention support for generics would be difficult,
if at all possible in their current incarnation.

In theory, the JIT compiler could also change its already-compiled code
on the fly if metrics showed that there would be more suitable
optimisations to apply for the pattern of execution.  I'm not aware of
this actually happening, but I seem to remember reading some MS
documentation a while ago that was flinging all sorts of cool
possibilities about.

Regards,

Pete Restall

2011\01\03@132107 by N. T.

picon face
Bob Ammerman wrote:
> I incorrectly stated that the translation to native code could happen at
> development time. I apparently am mistaken. It can only be done at (or
> after) installation on a target computer. See the "NGEN" utility.

I am not an expert in all that "NGEN" / "JIT" things, but from the
basic logic if "translation to native code can't happen at development
time", how could be possible to run apps under development, that is
from Visual Studio

2011\01\03@133831 by N. T.

picon face
N. T. wrote:
> Bob Ammerman wrote:
>> I incorrectly stated that the translation to native code could happen at
>> development time. I apparently am mistaken. It can only be done at (or
>> after) installation on a target computer. See the "NGEN" utility.
>
> I am not an expert in all that "NGEN" / "JIT" things, but from the
> basic logic if "translation to native code can't happen at development
> time", how could be possible to run apps under development, that is
> from Visual Studio?
>

Adding to my own post...
Talking about "development time", It looks like even very Visual
Studio is not necessarily “NGEN’d” when installed:

weblogs.asp.net/scottgu/archive/2010/04/12/visual-studio-2010-and-net-4-released.aspx
***
The VS 2010 and .NET 4 installs add a bunch of new managed assemblies
to your machine.  Some of these will be “NGEN’d” to native code during
the actual install process (making them run fast).  To avoid adding
too much time to VS setup, though, we don’t NGEN all assemblies
immediately – and instead will NGEN the rest in the background when
your machine is idle.  Until it finishes NGENing the assemblies they
will be JIT’d to native code the first time they are used in a process
– which for large assemblies can sometimes cause a slight performance
hit.

If you run into this you can manually force all assemblies to be
NGEN’d to native code immediately (and not just wait till the machine
is idle) by launching the Visual Studio command line prompt from the
Windows Start Menu (Microsoft Visual Studio 2010->Visual Studio
Tools->Visual Studio Command Prompt).  Within the command prompt type
“Ngen executequeueditems” – this will cause everything to be NGEN’d
immediately.
***

2011\01\07@205619 by William \Chops\ Westfield

face picon face

On Jan 2, 2011, at 10:38 AM, Bob Ammerman wrote:

>> That is exactly my point too -- AppleSoft Basic was ding the same  
>> as .NET
>> and JavaVM including garbage collection...
>
> Actually, AppleSoft (and many other forms of) Basic simply tokenized
> keywords. The code was still interpreted from the thus-tokenized  
> source.

I was mainly curious/surprised that the original "virtual machine"  language (Pascal) no longer seemed to ever be implemented that way,  and was wondering what had happened and why not...

I did a bit more research, and it looks like the original (UCSD) P- code was more of generalized machine language, designed for simplicity  and portability more than efficiency, safety, security, or even  language support.  A sort of compiler-writer's simplistic view of  hardware.  I suspect that this ended up being too different from  actual CPUs to hold the interest of compiler vendors (perhaps this is  another reason why C ended up succeeding.  Its "model" of how a CPU  worked turned out to be much closer to reality than other languages.

Note that this is much different than tokenizing at the high level  language level.

Apparently Smalltalk also used a similar virtual machine, so it's not  like the idea has been totally neglected in between the UCSD P-system  and Java...

BillW

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