[Oberon] Oberon Runtime Environment running Oberon byte-code

[Douglas G. Danforth]

"Although the concept was first implemented circa 1966 (as O-code 
<https://en.wikipedia.org/wiki/O-code> for BCPL 
<https://en.wikipedia.org/wiki/BCPL> and P - a code for the Euler 
Language 
<https://en.wikipedia.org/wiki/Euler_%28programming_language%29>),^[1] 
<https://en.wikipedia.org/wiki/P-code_machine#cite_note-1> the term 
p-code first appeared in the early 1970s. Two early compilers 
<https://en.wikipedia.org/wiki/Compiler> generating p-code were the 
*Pascal-P compiler *in 1973, by Nori, Ammann, Jensen, Hageli, and 
Jacobi,^[2] <https://en.wikipedia.org/wiki/P-code_machine#cite_note-2> 
and the *Pascal-S compiler *in 1975, by Niklaus Wirth 
<https://en.wikipedia.org/wiki/Niklaus_Wirth>."

See p-code <https://en.wikipedia.org/wiki/P-code_machine>


On 2/28/2016 7:45 PM, Srinivas Nayak wrote:
> Dear All,
>
> To my knowledge, Oberon programs needs a runtime environment with
> 1. command activation
> 2. garbage collection
> 3. dynamic loading of modules
> 4. certain run-time data structures
>
> Although not part of the language, this environment is  implied by the 
> language definition.
> And this empowers Oberon.
>
> If this is the case, like Java, would a Oberon Runtime Environment 
> running Oberon byte-code have been better?
> Is there a limitation in this scheme?
> Looks like, Michael Spivey with Oxford Oberon-2 compiler proceeded 
> with similar scheme...
> I would like to know if there is any reason, we didn't make it like 
> java...
> I hope that would have solved taking Oberon to different platform easy.
>
>
> With thanks and best regards,
>
> Yours sincerely,
> Srinivas Nayak
>
> Home: http://www.mathmeth.com/sn/
> Blog: http://srinivas-nayak.blogspot.in/
> -- 
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160228/a31a6e99/attachment.html>