Re: Native/VM languages

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Wed, 03 Sep 2008 11:16:35 -0800

          From comp.compilers

Related articles
Native/VM languages borophyll@gmail.com (2008-08-25)
Re: Native/VM languages marcov@stack.nl (Marco van de Voort) (2008-08-27)
Re: Native/VM languages ldv@mail.com (ldv@mail.com) (2008-08-27)
Re: Native/VM languages jeremy.wright@microfocus.com (Jeremy Wright) (2008-08-28)
Re: Native/VM languages gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-08-28)
Re: Native/VM languages torbenm@pc-003.diku.dk (2008-08-29)
Re: Native/VM languages cr88192@hotmail.com (cr88192) (2008-08-30)
Re: Native/VM languages gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-09-03)
| List of all articles for this month |
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Wed, 03 Sep 2008 11:16:35 -0800
Organization: Compilers Central
References: 08-08-070 08-08-089 08-08-094
Keywords: code, interpreter
Posted-Date: 03 Sep 2008 15:21:12 EDT

(snip, I wrote)


> It seems that it should be possible to use an intermediate code,
> specific for each overall architecture, but not specialized for the
> individual implementation. It could then be used to generate the
> optimal code for the specific processor at install time, or possibly
> at run time.
(snip)


> [The intermediate code plan sounds a lot like the S/38 and AS/400.
> -John]


I suppose so, though I don't know the details of those
very well. As I understand it, IBM doesn't say much.


One that I didn't think about before that post is how to do it
independent of the OS. If the processor manufacturer generates the
conversion program, it has to be written in an OS independent fashion.


At least the details of the intermediate code should be open.
Hopefully it wouldn't make decompilation any easier, such that vendors
would be worried about secrets getting out.


-- glen
[The AS/400 architecture tightly integrates the operating system and the
architecture. There's a virtual machine language that hasn't changed
in decades, even though the physical implementation has changed from
LSI bit slice to powerpc chips. I doubt you can do this in an OS
independent way; that way lies the swamp of UNCOL. -John}







Post a followup to this message

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