Re: General byte-codes reference (Steve Meyer)
20 Dec 2000 17:24:02 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: General byte-codes reference (Daniel Dunbar) (2000-12-08)
Re: General byte-codes reference (2000-12-11)
Re: General byte-codes reference (2000-12-11)
Re: General byte-codes reference (Norman Culver) (2000-12-18)
Re: General byte-codes reference (2000-12-18)
Re: General byte-codes reference (Pat Caudill) (2000-12-18)
Re: General byte-codes reference (2000-12-20)
Re: General byte-codes reference (2000-12-21)
Re: General byte-codes reference (2000-12-31)
| List of all articles for this month |

From: (Steve Meyer)
Newsgroups: comp.compilers
Date: 20 Dec 2000 17:24:02 -0500
Organization: Global Network Services - Remote Access Mail & News Services
References: 00-12-030 00-12-073
Keywords: interpreter
Posted-Date: 20 Dec 2000 17:24:01 EST

On 18 Dec 2000 00:42:50 -0500, Norman Culver <> wrote:
>"Makhno" says...
>>Hi, I'm interested in learning a bit more about byte codes in
>>general. ie: If one were to write an interpreted language, what sort
>>of byte codes to use?

This might be slightly off topic but nearly all compiler writing area
conference proceedings are filled with papers on better and "faster"
"methods" for virtual machine (aka byte code) optimization. However,
as I read the papers, performance comparison is always against "slow"
current Java interpreted performance not against same program written
or compiled into C where academic optimizations would would be so
small it would not be visable on bar charts. Or am missing something?
I think at least as of now projects such as c-- are much more

>You have to take into account various factors such as CPU speed,
>memory speed and cache size. I've been doing a series of experiments
>with interpreters hand coded in assembler for some of the latest
>processors. It is possible to fit an entire interpreter into the L1
>cache (64 KB) of a 1 Ghz AMD but it won't fit into the 16 KB cache of
>a Pentium III. The Pentium IV with 12,000 trace cache entries looks
>very interesting but I don't have one to play around with.
>The choice of byte codes is highly dependent upon the CPU architecture
>so I would go with a generalized form in the object modules and let
>the loader adapt them to the run time environment.

My experience from digital hardware simulation area, where huge effort
has been put into performance, is that just reducing code size to fit
in cache does not help much. Better measure is combined data and code
cache behavior.

>Call me crazy but I think that the OS kernel may best be interpreted
>when CPU speed hits 2GHZ and above.
Steve Meyer Phone: (415) 296-7017
Pragmatic C Software Corp. Fax: (415) 296-0946
220 Montgomery St., Suite 925 email:
San Francisco, CA 94104

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.