Thoughts and Opinions or something like that

Thoughts and Opinions or something like that

[chris.danx]

Hi,
    Someone on these news groups suggested to someone that in order to make a
reliable Virtual Machines, they needed the opinions of many programmers in many
languages.  {Can't remember who, some of those threads get huge and i get lost!
Good idea who ever it was!}

I'm involved in a project to develop a VM and i was looking for peoples thoughts
on this.  I've started with a simple RISC machine that's not finished yet.  I
will complete this soon, but i've been thinking my approach is flawed.  Not to
say RISC is bad, but maybe it's too simplistic or lacks specific support for
features that'd make it A:more efficient and B:easier to program.


The language project will support the following imperative features:

-    For/While loops
-    Procedures
-    side effect enabled programming (variables)
-    "tidy" pointers
-    modes for parameters (only for procedures, functions nonmodified params)
-    Generitcity (polymorphism)


and the following functional features

-    pattern matching
-    side effect free programming (values)
-    higher order functions
-    guards
-    Algebraic types
-    N-Tuples
-    Genericity (polymorphisism)

and the following "not sure" or "in many paradigms" features

-    Units bound to values/variables
-    Lists                         []
-    Arrays                        <>
-    Records
-    Sets (and Records as Sets)    {}
-    Enumeration types (with extensiblity and subtyping)
-    Subtyping
-    Relational programming (some paper i really liked described it, prologish
     but somewhat different)


This list is quite exhaustive and i know it doesn't look that nice now, but the
work i've done so far seems to indicate this is all possible and looks nice too.
The major stumbling block is state->stateless programming but i'm looking and
trying ideas out.  Something will be done; whether or not it's pretty is another
matter.

I know many folks get annoyed when they here about "yet another new language"
but this is not about the language itself.  It is about me learning about all
this stuff and seeing what i can do with a big collection of (sometimes
unrelated) issues and see what can come of it.

The real problem is the VM, so i'm looking for peoples thoughts on this.  What
concepts would you have found useful, and what you'd rule out.

Please feel free to ignore this if you don't want to contribute (i know you will
anyway).


Regards,
Chris

Re: Thoughts and Opinions or something like that

[Ted Dennison]

In article <HtiF6.5582$Tv2.757613@news6-win.server.ntlworld.com>, chris.danx
says...
>will complete this soon, but i've been thinking my approach is flawed.  Not to
>say RISC is bad, but maybe it's too simplistic or lacks specific support for
>features that'd make it A:more efficient and B:easier to program.

My memory from my architecture courses in college (maybe I'm no expert, but I
took that damn course 3 times...) on RISC is:

o  RISC is not *supposed* to be easy to program. Its supposed to give compiler
writers the minimal tools they will need. Programmers are supposed to use the
compilers, not RISC. If you are writing assembly language RISC code, you are
either writing a compiler, or you are fighting the system.

o  What is efficient depends on the rest of the architecture; particularly on
where the bottlenecks are. In this day and age, the bottleneck is in accessing
memory. Thus you want a lot of register-to-register instructions, and memory
accesses should be the last resort. Also, efficency requres that you "pipeline"
instructions, like on an assembly-line. Doing that, using hardware, without
having one in-progress instruction screw up another, is very complicated. To
make it achievable, you don't want to have lots of instructions, and you don't
want the ones you have to do very much.

Now the question you should be asking is, "Do these design goal make sense for
my virtual machine?" Unless you have an eye on making it an acutal machine, or
performing one-to-one transformations into the target platform's RISC code, I'd
guess the answer would be "no".

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Thoughts and Opinions or something like that

[chris.danx]

Hi Ted,

> says...
> >will complete this soon, but i've been thinking my approach is flawed.  Not
to
> >say RISC is bad, but maybe it's too simplistic or lacks specific support for
> >features that'd make it A:more efficient and B:easier to program.
>
> My memory from my architecture courses in college (maybe I'm no expert, but I
> took that damn course 3 times...) on RISC is:
>
> o  RISC is not *supposed* to be easy to program. Its supposed to give compiler
> writers the minimal tools they will need. Programmers are supposed to use the
> compilers, not RISC. If you are writing assembly language RISC code, you are
> either writing a compiler, or you are fighting the system.
>
> o  What is efficient depends on the rest of the architecture; particularly on
> where the bottlenecks are. In this day and age, the bottleneck is in accessing
> memory. Thus you want a lot of register-to-register instructions, and memory
> accesses should be the last resort. Also, efficency requres that you
"pipeline"
> instructions, like on an assembly-line. Doing that, using hardware, without
> having one in-progress instruction screw up another, is very complicated. To
> make it achievable, you don't want to have lots of instructions, and you don't
> want the ones you have to do very much.
>
> Now the question you should be asking is, "Do these design goal make sense for
> my virtual machine?" Unless you have an eye on making it an acutal machine, or
> performing one-to-one transformations into the target platform's RISC code,
I'd
> guess the answer would be "no".
>

The reason i started with a RISC Architecture was that i originally planned to
have kind of generic assembly language that could be translated to native
hardware easily.  A smart conversion program would be able to figure out
improvements in CISC machines -- e.g. instead of loading from memory and adding,
fold them into one.  I don't really know if this smart optimisation would be
benefitial.  For RISC machines the translation would be fairly straight forward
i think.

Then i realised that one of the goals i wanted was interactive program
development.  This means i can supply sample arguments and watch what the
program does with it in a _virtual environment_ -- VE is primarily for safety
reasons (i'm not as competent at assembly as i'd like to be).  This is for later
but it occured to me that the VM approach would work for me on this.  If i could
avoid VMs i would, i planned way way back to not use them for portability, and
use a kind of hybrid description-assembly language, that could be optimised for
native platforms.


I'd looked at the JVM, but it's not a model i like.  It has too much dependance
on the stack, which is good for VM but not good for optimisations and other
things.  The crued method support also annoyed me.  I was planning to port Ada
to JVM before JGNAT became available.


*For simulation the VM seems to win.  For portability RISC seems to win.*


Then i thought about doing more an Architecture specific to the concepts i
wanted in the language.  When i read the post somewhere i thought since i have
little experience(just a CS Student who programs for uni and as a hobby) in
comparison to all the veterans out there, it seemed like a good idea to ask all
the folk out there.  Chicken and egg...


My plan for the language goes along a similar path.  Start with a simple
prototype, test it out, study results.  Build another prototype, test it out,
study results.  Build new prototype integrating main points of results and see
how they glue, test it out, study results, and keep going.  Of course planning
is important and if correctly done, many features may integrate without much
trouble.

The language testing will probably be done on the current RISC vm, but in the
interests of efficiency it might be best once the language is _stable_ for a
more specific VM, to be developed.  I like to plan ahead, hence this post.


Chris

Re: Thoughts and Opinions or something like that

[Andrew Cooke]

Things I'd like from a VM (off the top of my head - I don't use VMs
directly and I have no idea whether the following are possible):

- garbage collection
- support for coroutines (no single stack restrictions)
- support for tail recursion

(the last two are known problems with the JVM, I believe).

If you want to concentrate on your language, rather than writing the VM,
you could target an existing machine - apart from the obvious .net and
JVM, you might consider C--

Andrew

"chris.danx" wrote:
> 
> Hi,
>     Someone on these news groups suggested to someone that in order to make a
> reliable Virtual Machines, they needed the opinions of many programmers in many
> languages.  {Can't remember who, some of those threads get huge and i get lost!
> Good idea who ever it was!}
> 
> I'm involved in a project to develop a VM and i was looking for peoples thoughts
> on this.  I've started with a simple RISC machine that's not finished yet.  I
> will complete this soon, but i've been thinking my approach is flawed.  Not to
> say RISC is bad, but maybe it's too simplistic or lacks specific support for
> features that'd make it A:more efficient and B:easier to program.
> 
> The language project will support the following imperative features:
> 
> -    For/While loops
> -    Procedures
> -    side effect enabled programming (variables)
> -    "tidy" pointers
> -    modes for parameters (only for procedures, functions nonmodified params)
> -    Generitcity (polymorphism)
> 
> and the following functional features
> 
> -    pattern matching
> -    side effect free programming (values)
> -    higher order functions
> -    guards
> -    Algebraic types
> -    N-Tuples
> -    Genericity (polymorphisism)
> 
> and the following "not sure" or "in many paradigms" features
> 
> -    Units bound to values/variables
> -    Lists                         []
> -    Arrays                        <>
> -    Records
> -    Sets (and Records as Sets)    {}
> -    Enumeration types (with extensiblity and subtyping)
> -    Subtyping
> -    Relational programming (some paper i really liked described it, prologish
>      but somewhat different)
> 
> This list is quite exhaustive and i know it doesn't look that nice now, but the
> work i've done so far seems to indicate this is all possible and looks nice too.
> The major stumbling block is state->stateless programming but i'm looking and
> trying ideas out.  Something will be done; whether or not it's pretty is another
> matter.
> 
> I know many folks get annoyed when they here about "yet another new language"
> but this is not about the language itself.  It is about me learning about all
> this stuff and seeing what i can do with a big collection of (sometimes
> unrelated) issues and see what can come of it.
> 
> The real problem is the VM, so i'm looking for peoples thoughts on this.  What
> concepts would you have found useful, and what you'd rule out.
> 
> Please feel free to ignore this if you don't want to contribute (i know you will
> anyway).
> 
> Regards,
> Chris

Re: Thoughts and Opinions or something like that

[chris.danx]

Hi,

>
> Things I'd like from a VM (off the top of my head - I don't use VMs
> directly and I have no idea whether the following are possible):
>
> - garbage collection

Garbage collection is good in theory and in practise too.  The problem is that
it is complex to implement.  I will be including some support for it, but i
completely forgot about the technique.  Thanks for reminding me Andrew.


> - support for coroutines (no single stack restrictions)
>

I don't understand what you mean by "coroutines" but i assume from what comes
next it's got something to do with multiple stacks.  I suppose i could try
something like having more than one SP in the RISC version and see how that
goes.  Pop S2, for pop stack 2.  Or more generically Pop An, where An is an
address register pointing to the stack.  Then i could integrate more a specific,
better design in the WillowVM (VM version 2).

> - support for tail recursion
>

This is something i never got my head round.  I get primitive recusion, which
involves just recurring a function (e.g. a factorial function), but i know this
is innefficient.  Tail recursion has to do with finishing the computution before
calling another smaller version of the computation.  This means the system can
use the same frame over for the function i think?

Sounds like a good idea in theory, but how would one implement this in practise?
I would implement something like this if i could, because functional programs
tend to rely on tail recursion a lot.  My Haskell is currently limited to only
primitive recursion, but i'm still learning.

> (the last two are known problems with the JVM, I believe).
>


> If you want to concentrate on your language, rather than writing the VM,
> you could target an existing machine - apart from the obvious .net and
> JVM, you might consider C--

I think i will use the simple RISC machine at the start and when i know what
features are going to be in the language i will develop a VM.  The good thing
about the implementation of the RISC VM is that the VM is currently 100%
portable Ada.

There are problem coming from interface to system for files, etc.  I haven't
been able to think of a good way to do this yet, and all the schemes i devised
for representing calls in assembly have been too complex.  Need something
simpler, and i've been working towards this.  This too will hopefully be 100%
portable Ada thanks to Ada's standard packages.  I'm not holding my breathe
though.


Thanks,
Chris.

Re: Thoughts and Opinions or something like that

[Warren W. Gay VE3WWG]

"chris.danx" wrote:
> 
> Hi,
>...snip... 
> > - support for coroutines (no single stack restrictions)
> >
> 
> I don't understand what you mean by "coroutines" but i assume from what comes
> next it's got something to do with multiple stacks.  I suppose i could try
> something like having more than one SP in the RISC version and see how that
> goes.  Pop S2, for pop stack 2.  Or more generically Pop An, where An is an
> address register pointing to the stack.  Then i could integrate more a specific,
> better design in the WillowVM (VM version 2).

Co-routines require multiple stacks, in the same way that threads do. What
happens in practice, some arbitrary amount is offsetted from the current
stack pointer (or its root), to start a new stack. In other words, one
stack is subdivided into many, to accomodate additional co-routines 
(or additional threads).

However, there is no law that says you have to implement stacks in this way,
but there are sometimes performance benefits to this, depending upon your
platform (memory pages behind the virtual pages are physically allocated 
as the stack grows deeper for example).  However, you could accomodate the
same effect with malloc() if your platform supports lazy virtual memory
allocation (I believe *BSD and Linux do this).

In any event, the bottom line is that you still have to decide on stack
sizes at some point :< , or accept them by default.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Thoughts and Opinions or something like that

[Marcin 'Qrczak' Kowalczyk]

Followup-To: comp.lang.functional

Wed, 25 Apr 2001 11:42:02 +0100, chris.danx <chris.danx@ntlworld.com> pisze:

> I don't understand what you mean by "coroutines" but i assume from
> what comes next it's got something to do with multiple stacks.
> I suppose i could try something like having more than one SP in
> the RISC version and see how that goes.  Pop S2, for pop stack 2.
> Or more generically Pop An, where An is an address register pointing
> to the stack.  Then i could integrate more a specific, better design
> in the WillowVM (VM version 2).

I guess that coroutines don't need the model when each stack operation
names the stack - it is not known locally which stacks will be in use -
but the ability to switch stacks, where each thread has its stack.

> This is something i never got my head round.  I get primitive
> recusion, which involves just recurring a function (e.g. a factorial
> function), but i know this is innefficient.  Tail recursion has to
> do with finishing the computution before calling another smaller
> version of the computation.  This means the system can use the same
> frame over for the function i think?

Glasgow Haskell Compiler uses tail calls exclusively. "Normal" calls
where the caller wants to process the value returned by the callee
before returning it are expressed as tail calls with the continuation
as a parameter.

Generally, since Haskell is lazy, an important operation is evaluation
of an object. This is unified with applying a function. It is performed
by jumping to the first word of the object. This is a jump without
return. The "what to do next" pointer is passed as one of arguments.

When a source function wants to perform evaluation of multiple objects,
its code is physically split into pieces between evaluations. Each
evaluation is passed the address of the next piece, except the last
which is passed the "what to do next" pointer which our caller gave us.

GHC almost doesn't use the system stack. It manages its own stack
for passing arguments and return values, which grows and shrinks
independently of the calling sequence. There is some gcc magic to
keep stack and heap pointers in registers.

This model is quite different from C-style calls with return address
on the stack, so there are various hacks to implement it on different
backends. This is for C backends (assembler code generated by the C
compiler is later mangled which includes erasing some stuff):

/* -----------------------------------------------------------------------------
 * $Id: TailCalls.h,v 1.7 2001/02/14 10:33:05 simonmar Exp $
 *
 * (c) The GHC Team, 1998-1999
 *
 * Stuff for implementing proper tail jumps.
 *
 * ---------------------------------------------------------------------------*/

#ifndef TAILCALLS_H
#define TAILCALLS_H

/* -----------------------------------------------------------------------------
   Unmangled tail-jumping: use the mini interpretter.
   -------------------------------------------------------------------------- */

#ifdef USE_MINIINTERPRETER

#define JMP_(cont) return(stgCast(StgFunPtr,cont))
#define FB_
#define FE_

#else

/* -----------------------------------------------------------------------------
   Tail calling on x86
   -------------------------------------------------------------------------- */

#if i386_TARGET_ARCH

extern void __DISCARD__(void);

/* Note about discard: possibly there to fool GCC into clearing up
   before we do the jump eg. if there are some arguments left on the C
   stack that GCC hasn't popped yet.  Also possibly to fool any
   optimisations (a function call often acts as a barrier).  Not sure
   if any of this is necessary now -- SDM

   Comment to above note: I don't think the __DISCARD__() in JMP_ is 
   necessary.  Arguments should be popped from the C stack immediately
   after returning from a function, as long as we pass -fno-defer-pop
   to gcc.  Moreover, a goto to a first-class label acts as a barrier 
   for optimisations in the same way a function call does. 
   -= chak
   */

/* The goto here seems to cause gcc -O2 to delete all the code after
   it - including the FE_ marker and the epilogue code - exactly what
   we want! -- SDM
   */

#define JMP_(cont)			\
    { 					\
      void *target;			\
      __DISCARD__();			\
      target = (void *)(cont);    	\
      goto *target; 	    	    	\
    }

#endif /* i386_TARGET_ARCH */

/* -----------------------------------------------------------------------------
   Tail calling on Sparc
   -------------------------------------------------------------------------- */

#ifdef sparc_TARGET_ARCH

#define JMP_(cont)	((F_) (cont))()
	/* Oh so happily, the above turns into a "call" instruction,
	   which, on a SPARC, is nothing but a "jmpl" with the
	   return address in %o7 [which we don't care about].
	*/

/* Don't need these for sparc mangling */
#define FB_
#define FE_

#endif /* sparc_TARGET_ARCH */

/* -----------------------------------------------------------------------------
   Tail calling on Alpha
   -------------------------------------------------------------------------- */

#ifdef alpha_TARGET_ARCH

register void *_procedure __asm__("$27");

#define JMP_(cont)	    	    	    	\
    do { _procedure = (void *)(cont);    	\
         goto *_procedure;    	    	    	\
       } while(0)

/* Don't need these for alpha mangling */
#define FB_
#define FE_

#endif /* alpha_TARGET_ARCH */

/* -----------------------------------------------------------------------------
   Tail calling on HP

Description of HP's weird procedure linkage, many thanks to Andy Bennet
<andy_bennett@hp.com.no.spam>:

I've been digging a little further into the problem of how HP-UX does
dynamic procedure calls. My solution in the last e-mail inserting an extra
'if' statement into the JMP_ I think is probably the best general solution I
can come up with. There are still a few problems with it however: It wont
work, if JMP_ ever has to call anything in a shared library, if this is
likely to be required it'll need something more elaborate. It also wont work
with PA-RISC 2.0 wide mode (64-bit) which uses a different format PLT.

I had some feedback from someone in HP's compiler lab and the problem
relates to the linker on HP-UX, not gcc as I first suspected. The reason the
'hsc' executable works is most likely due to a change in 'ld's behaviour for
performance reasons between your revision and mine.

The major issue relating to this is shared libraries and how they are
implented under HP-UX. The whole point of the Procedure Label Table (PLT) is
to allow a function pointer to hold the address of the function and a
pointer to the library's global data lookup table (DLT) used by position
independent code (PIC). This makes the PLT absolutely essential for shared
library calls. HP has two linker introduced assembly functions for dealing
with dynamic calls, $$dyncall and $$dyncall_external. The former does a
check to see if the address is a PLT pointer and dereferences if necessary
or just calls the address otherwise; the latter skips the check and just
does the indirect jump no matter what.

Since $$dyncall_external runs faster due to its not having the test, the
linker nowadays prefers to generate calls to that, rather than $$dyncall. It
makes this decision based on the presence of any shared library. If it even
smells an sl's existence at link time, it rigs the runtime system to
generate PLT references for everything on the assumption that the result
will be slightly more efficient. This is what is crashing GHC since the
calls it is generating have no understanding of the procedure label proper.
The only way to get real addresses is to link everything archive, including
system libraries, at which point it assumes you probably are going to be
using calls similar to GHC's (its rigged for HP's +ESfic compiler option)
but uses $$dyncall if necessary to cope, just in case you aren't.

   -------------------------------------------------------------------------- */

#ifdef hppa1_1_hp_hpux_TARGET

#define JMP_(cont)                              \
    do { void *_procedure = (void *)(cont);     \
         if (((int) _procedure) & 2)            \
            _procedure = (void *)(*((int *) (_procedure - 2))); \
         goto *_procedure;                      \
       } while(0)

#endif /* hppa1_1_hp_hpux_TARGET */

/* -----------------------------------------------------------------------------
  FUNBEGIN and FUNEND.

  These are markers indicating the start and end of Real Code in a
  function.  All instructions between the actual start and end of the
  function and these markers is shredded by the mangler.
  -------------------------------------------------------------------------- */

/*  The following __DISCARD__() has become necessary with gcc 2.96 on x86.
 *  It prevents gcc from moving stack manipulation code from the function
 *  body (aka the Real Code) into the function prologue, ie, from moving it
 *  over the --- BEGIN --- marker.  It should be noted that (like some
 *  other black magic in GHC's code), there is no essential reason why gcc
 *  could not move some stack manipulation code across the __DISCARD__() -
 *  it just doesn't choose to do it at the moment.
 *  -= chak
 */
#ifndef FB_
#define FB_    __asm__ volatile ("--- BEGIN ---"); __DISCARD__ ();
#endif

#ifndef FE_
#define FE_    __asm__ volatile ("--- END ---");
#endif

#endif /* !USE_MINIINTERPRETER */

#endif /* TAILCALLS_H */

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST�PCZA
QRCZAK

Re: Thoughts and Opinions or something like that

[chris.danx]

Hi, [posting to others re-instated]

> > Things I'd like from a VM (off the top of my head - I don't use VMs
> > directly and I have no idea whether the following are possible):
> >
> > - garbage collection
> > - support for coroutines (no single stack restrictions)
> > - support for tail recursion
> >
> > (the last two are known problems with the JVM, I believe).
>
>
> Scheme VMs have GC and tail-call optimization. Java VM has threads.
> Icon VM has coroutines (rather: co-expressions). No problems, and
> I would add that it is MUCH easier to provide for a more complicated
> semantics of a language using an interpreter than compiling to
> a native code...

Do you mean just rip out an interpreter and forget the VM idea until later?
That sounds like a good idea.

>
> > If you want to concentrate on your language, rather than writing the VM,
> > you could target an existing machine - apart from the obvious .net and
> > JVM, you might consider C--
>
>
> Sorry, but I am violently against this approach, if you want to do
> something interesting, to learn new paradigms, to have some fun. Using
> existing VPlatforms (BTW, C-- is not one) is good for the portability
> and for the possibility of "selling" it to a wider community, but it
> is a little boring, and you feel like putting yourself voluntarily
> into a somebody else's straitjacket.
>


> ...
>
> "chris danx":
> > and the following "not sure" or "in many paradigms" features
> >
> > -    Units bound to values/variables
> > -    Lists                         []
> > -    Arrays                        <>
>
> Don't neglect reasonable arrays, please, otherwise one day, sooner
> or later you will regret it...
>

What do you mean by reasonable arrays?  What's unreasonable about them?

Chris

>
> Jerzy Karczmarczuk
> Caen, France

Re: Thoughts and Opinions or something like that

[Jerzy Karczmarczuk]

"chris.danx" wrote:
> 
> Hi, [posting to others //nsgroups Ada & misc// re-instated]

(As you wish, but it has NOTHING to do with Ada, etc... And, anyway,
I don't read those newsgroups, so if somebody is kind enough to comment,
it won't reach me)

I remarked, concerning the "problems" with VMs

> > Scheme VMs have GC and tail-call optimization. Java VM has threads.
> > Icon VM has coroutines (rather: co-expressions). No problems, and
> > I would add that it is MUCH easier to provide for a more complicated
> > semantics of a language using an interpreter than compiling to
> > a native code...

> Do you mean just rip out an interpreter and forget the VM idea 
> until later? That sounds like a good idea.

I think that there is a small misunderstanding here. An interpreter
IS a Virtual Machine. I just said that in general the idea of building
a language with interesting semantic layer is easier if one has some
higher-level executable code, not the assembly stuff, that's all. So,
if I wanted to construct a language, I would build an interpreter first.
A virtual machine, if you prefer. My own, not the Java stuff...

Alain Fisher proposes to look at the Smalltalk machine. Yes, it is
quite powerful, and nice. However, the object-orientation is build
at a low level, and if you don't need it, there will be a cost.

There is plenty of small VMachines around. From Forth/Postscript,
through the SECD models (including lazy or persistent), the CAMLish
kernel used e.g. to implement Moscow SML, logical machines such as
variants of WAM, etc. One can learn a lot from them, even if there
is not much sense in "ripping" them, and adapting to a novel
language. In particular one may learn how to implement tail-recursion
and something about GC.



> > > -    Lists                         []
> > > -    Arrays                        <>
> >
> > Don't neglect reasonable arrays, please, otherwise one day, sooner
> > or later you will regret it...
> 
> What do you mean by reasonable arrays?  What's unreasonable about them?
> 
> Chris

Not about THEM.
There are unreasonable arrays simulated by lists. Reasonable mean:
real arrays, secure (index checking), true random access, working well
with garbage collector (in some Lisps lists were dynamic, but arrays
static...), and fast iterators. 



Jerzy Karczmarczuk
Caen, France

Re: Thoughts and Opinions or something like that

[chris.danx]

"Jerzy Karczmarczuk" <karczma@info.unicaen.fr> wrote in message
news:3AE6D66A.7A3E09F8@info.unicaen.fr...
> "chris.danx" wrote:
> >
> > Hi, [posting to others //nsgroups Ada & misc// re-instated]
>
> (As you wish, but it has NOTHING to do with Ada, etc... And, anyway,
> I don't read those newsgroups, so if somebody is kind enough to comment,
> it won't reach me)
>

Yes, it will.  I posted to more than one group so i could get a larger volume of
discussion, and i'd noticed that c.l.m is not very busy otherwise i might have
just stuck it there.  It's a personal preference i guess, i don't cross post
that often.



> I remarked, concerning the "problems" with VMs
>
> > > Scheme VMs have GC and tail-call optimization. Java VM has threads.
> > > Icon VM has coroutines (rather: co-expressions). No problems, and
> > > I would add that it is MUCH easier to provide for a more complicated
> > > semantics of a language using an interpreter than compiling to
> > > a native code...
>
> > Do you mean just rip out an interpreter and forget the VM idea
> > until later? That sounds like a good idea.
>
> I think that there is a small misunderstanding here. An interpreter
> IS a Virtual Machine. I just said that in general the idea of building
> a language with interesting semantic layer is easier if one has some
> higher-level executable code, not the assembly stuff, that's all. So,
> if I wanted to construct a language, I would build an interpreter first.
> A virtual machine, if you prefer. My own, not the Java stuff...
>

VM is an interpreter!  Thanks for reminding me, i'd temporarily forgotten that
fact.  I thought you meant that it'd be best to use an interpreter for the
language like Hugs, or Metacombco Basic.  This is what i usually call an
interpreter, but i guess it really doesn't matter, there's so much overlap in
computing.




> Alain Fisher proposes to look at the Smalltalk machine. Yes, it is
> quite powerful, and nice. However, the object-orientation is build
> at a low level, and if you don't need it, there will be a cost.

I don't think I would not use the smalltalk machine.  The cost as you have said
would be too great.

>
> There is plenty of small VMachines around. From Forth/Postscript,
> through the SECD models (including lazy or persistent), the CAMLish
> kernel used e.g. to implement Moscow SML, logical machines such as
> variants of WAM, etc. One can learn a lot from them, even if there
> is not much sense in "ripping" them, and adapting to a novel
> language. In particular one may learn how to implement tail-recursion
> and something about GC.

I wasn't aware of CAMLish kernel, or WAM.  Thanks for the references i'll go
take peek.  Most of the VMs i'd looked at used Stack based methods for
computation but i didn't like that.  I'd never seen a VM use registers before so
i thought i'd do one to see if they're as bad as they've been made out.  It
seems a reverse from hardware computing.

Hardware    Register Performance > Stack Performance
Software    "    "    "    "     < "    "    "    "

Weird!


> > > > -    Lists                         []
> > > > -    Arrays                        <>
> > >
> > > Don't neglect reasonable arrays, please, otherwise one day, sooner
> > > or later you will regret it...
> >
> > What do you mean by reasonable arrays?  What's unreasonable about them?
> >
> > Chris
>
> Not about THEM.
> There are unreasonable arrays simulated by lists. Reasonable mean:
> real arrays, secure (index checking), true random access, working well
> with garbage collector (in some Lisps lists were dynamic, but arrays
> static...), and fast iterators.
>

I would never ever simulate arrays with lists, because of performance.  Having
to walk a list to get to 20th element then re-walk it to get 19th is a bad
thing.  True random access, yes.  secure (index checking) yes!

Don't know about works well with garbage collector but i'd assume so, well i
guess that's a yes then.

Fast iterators?  I know what an iterator is but what is "fast iterator"?  Just a
suped up version of an iterator?

Thanks,
Chris Campbell

>
>
> Jerzy Karczmarczuk
> Caen, France

Re: Thoughts and Opinions or something like that

[chris.danx]

"Andrew Cooke" <andrew@andrewcooke.free-online.co.uk> wrote in message
news:3AE6DAB3.899FF645@andrewcooke.free-online.co.uk...
>
>
> Jerzy Karczmarczuk wrote:
> > Sorry, but I am violently against this approach, if you want to do
> > something interesting, to learn new paradigms, to have some fun. Using
> > existing VPlatforms (BTW, C-- is not one) is good for the portability
> > and for the possibility of "selling" it to a wider community, but it
> > is a little boring, and you feel like putting yourself voluntarily
> > into a somebody else's straitjacket.
>
> That seems a little strong.  It was only a suggestion, as he's already
> working on other "new" stuff - a whole language.  I agree, to learn you
> need to play, but the playing has to be fun.

Agreed.

> Making a sandcastle is
> fun, sweeping the Sahara clean is hard work.  Using some kind of
> existing low-level support for your langauge might be a good way of
> keeping things light enough to be interesting.

In an ideal world yes.


> Also, I know C-- isn't a virtual machine, but it is a possible way of
> providing low-level support for a language, which is relevant here.  In
> fact, it seems to have been designed particularly for that.  If looks
> like a duck and quacks like a duck then only an anally retentive
> c.l.functional poster (who dropped the very group I emailed from -
> c.l.misc) would waste words making a distinction.

The reason i turned away from C-- is that it seemed only to work with linux.
I'm windows based so it didn't seem practicle at the time -- i'd installed linux
on my machine before as part of a dual boot thing, did everything it said, and
bang it only boots linux, not windows, so i'm not doing that again).  It might
work on Windows though!

Chris

p.s. i thought people generally ignored cross posting and let it stand as it is
but obviously not.  i don't know why folks drop them.  is it because they think
that messages posted from other groups won't be shown on their group?  That's
bolloks!  That's the whole point of cross posting the message.

> Andrew

Re: Play with virtual machines (Was: Thoughts and Opinions...)

[chris.danx]

"Jerzy Karczmarczuk" <karczma@info.unicaen.fr> wrote in message
news:3AE7E37B.F384DCDA@info.unicaen.fr...
> I expressed my (partially) strong negative opinion about exploiting
> the existing virtual machines for implementing a new, non-existing
> yet and experimental language. I assembly here my answer to Chris
> "Danx" (Campbell) and Andrew Cooke.
>
> Andrew Cooke quotes me:
>
> > > Sorry, but I am violently against this approach, if you want to do
> > > something interesting, to learn new paradigms, to have some fun. Using
> > > existing VPlatforms (BTW, C-- is not one) is good for the portability
> > > and for the possibility of "selling" it to a wider community, but it
> > > is a little boring, and you feel like putting yourself voluntarily
> > > into a somebody else's straitjacket.
>
> > That seems a little strong.  It was only a suggestion, as he's already
> > working on other "new" stuff - a whole language.  I agree, to learn you
> > need to play, but the playing has to be fun.  Making a sandcastle is
> > fun, sweeping the Sahara clean is hard work.  Using some kind of
> > existing low-level support for your langauge might be a good way of
> > keeping things light enough to be interesting.
>
> This "a little strong" accusation is right. I wouldn't say that, if the
> author of the project was mainly concerned about coding, about making
> his machine run his language in finite development time. Then, surely,
> existing solutions are more than reasonable.
> [Taking JVM would help him with GC; taking some models of SECD would
>  (perhaps...) help to implement the tail recursion, etc. But using JVM
>  would not teach him *how* to construct a garbage collector.

This is a good point.  I hadn't considered that before.  Many languages i've
used seem to regard the JVM as a holy grail of sorts, because of it's garbage
collection.  I'd rather not use it, since it has a stack based computational
model, and for now i want register based one.

I've been tinkering with a memory model suggested by Tucker Taft.  Basically i
had a problem with allocating memory, which would be somewhat restrictive in the
ammount of space i could allocate.

Tucker suggested i use a model close to Virtual Memory in computer OSes.  I've
had some difficulties with this, but i think i can make it work.  The idea goes
like this, you have page table:page number:offset, when a write occurs a page is
either allocated (if it does not exist before hand) and written, or written to
straight away.  A read returns 0 for un-allocated page, or the data for an
allocated one.

I was thinking of having some kind of primitive GC.  it goes like this:

Rather than have all code and data in large contigous blocks, some (not commonly
used routines) would put there data a separate page.  When the routine is done,
that page can be deleted.  Don't know if this will work.

Another scheme i thought about was adding a 32bit number to array, set, and list
types.  Each scope level has a number, when we go down the number increases.  An
array, list, set can only be deleted if the number decreases below it's own.
This is just off the top of my head, so maybe it's impracticle.  Not sure it
would work in some cases.



> Once more: I thought he wants to work in the kitchen more than just
> having his meal prepared...

An interesting way to put it.

>
>
> > Also, I know C-- isn't a virtual machine, but it is a possible way of
> > providing low-level support for a language, which is relevant here.
>
> That's right, of course. A low-level implementation language, better
> structured and more portable than assemblers, and as powerful wrt.
> branching and memory control, more than C, is something we will badly
> need. But C-- won't give you the semantic model of your new language,
> this is a different layer of description. Chris, who gives up C--
> right now because of his Windows commitment might return back one day,
> but the VM construction will remain as it is.
>
> ********************************
>
>
>
> "chris.danx" wrote:
>
> > p.s. i thought people generally ignored cross posting and let it
> > stand as it is but obviously not.  i don't know why folks drop them.
> > is it because they think that messages posted from other groups
> > won't be shown on their group?  That's bolloks!  That's the whole
> > point of cross posting the message.
>
> This was not my point. Simply, some people abuse cross-posting in
> a harmful, polluting way. The discussion domain, originally OK,
> gets shifted, and after two days its subject has *NOTHING* to do with
> the nsgroup profile. "Algorithm" groups full of postings about where
> to find DirectX software, or about the status of software patents;
> mutilingual programming/communication group starting to talk about
> politics, etc. That's all. Filtering away all possible redundant
> messages is impossible.

Ah, i see.  Sorry.  Those people who abuse this are crappy.  It's happened on
one other group quite a lot.  they're discussing delphi as a model for os
development on two groups, it started with one guy asking what he should use but
now they're arguing over delphi's features vs visual C's vs C hash vs whatever.
It's quit annoying as the discussion was quite informative at the start, before
all the Delphi bitching.




> Chris asks also in a previous posting:
>
> > Fast iterators?  I know what an iterator is but what is "fast
> > iterator"?  Just a suped up version of an iterator?
>
> I am an old user of array-oriented software: languages like Matlab
> (or Scilab, Yorick, RLab, Tela, Octave...). What I meant is that if
> you use all those tables, matrices, etc. *SERIOUSLY*, than the language
> should provide you with an adequate number of high-level constructs
> coded as efficiently as possible within the language kernel/standard
> library. For example
> *Maps and Folds: computing sums, maxima/minima, multiplying arrays
>      by scalars etc. Filters, transpositions.
> *Comprehensions and generators:  Intervals, like a .. b; Constructs
>       like Clean array comprehension
>
> {createArray 5 0 & [i]=elem \\ elem <-: {1,3,5,7,9} & i<-[0..4]}
>
> *Zips: scalar products, masking...
> *Slicing, extracting sub-arrays. Streaming arrays (compact I/O).
>
> *Nice interfacing between graphic objects (bitmaps, z-buffers or
>  other stencils) and array manipulators.
>

Righty oh.  That's a lot of work, but hey, i can see why it's useful.  The
language will be largely functional with some imperative features, and i was
planning on having generators for lists and sets.  I completely forgot about
array generators and comprehensions, thanks.  I'd only used clean a little since
it can be difficult for beginners(like me).  It's a nice language though.

> ==
>
> All this together permits to write a long piece of (say, Matlab) code
> 10 times faster and shorter than the equivalent C code. Less bugs, and
> because those operations are within the kernel, the execution speed
> is very decent. You don't have to write dozens of loops (and debugging
> indices...) No need to keep trace of dozens of temporary accumulating
> variables... Here you are what I mean "suped up" iterators...
>
> Array-oriented software will be always needed by physicists, engineers,
> etc. It is a pity that an array-oriented FUNCTIONAL language: Sisal
> is dead. This is an ecological niche wide open.
>

I've never used arrays like you suggested before.  I can certainly see the
benefits now you've pointed it out.  It seems like a good idea to include some
support.  This language will be almost completely developed with other people
experimenting with it and sending in there results.  Once the VMs working and
the (more) structured assembly language (with nicer syntax, 86x and m68k aren't
nice at all IMO) is working, an assembler and disassembler will be next.  Then
it will be the first prototype will arrive and people can tinker.

I decided to do it this way since involving people will only improve it.  The
main problem will be die-hards who wan't me to do another Haskell, or Ada, or
people who say lisp has everything and add this cos' X has it.  That's not
helpful, people need to make arguments for the right reasons, not for bad ones.


Chris

Re: Play with virtual machines (Was: Thoughts and Opinions...)

[chris.danx]

"Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at> wrote in message
news:3AE81234.267643AC@kfunigraz.ac.at...
> Jerzy Karczmarczuk wrote:
>
> > All this together permits to write a long piece of (say, Matlab) code
> > 10 times faster and shorter than the equivalent C code. Less bugs, and
> > because those operations are within the kernel, the execution speed
> > is very decent.
>
> [comp.lang.misc removed from the header]
>

[Stop removing groups.  Your getting on my nerves!  This is suppost to be an
open discussion.  So let's keep it that way.]

> That is correct. But there remains one problem: the written code is very hard
> to read. Sure the development time is reduced by an enormous amount. I cannot
> live without Yorick anymore (I can't pay the money which Yorick helped saving
> me), but reusing the code is the same dilema as with lets say C.
>
> > Array-oriented software will be always needed by physicists, engineers,
> > etc.
>
> That is really true. But there is another option: Fortran 90. Sure it is not
> "interactive" but it has some nice features handling arrays.
>
> > It is a pity that an array-oriented FUNCTIONAL language: Sisal
> > is dead. This is an ecological niche wide open.
>
> I know from a physicist at LLNL that Sisal had been the only "functional"
> language with the potential to compare in speed against Fortran. But nobody
> knows why they dropped Sisal.
>
>
> S. Gonzi
> [BTW: There is an IDL clone for Linux available, called "Ana". It is
> something like Matlab or Yorick but with strong emphasize on image
> processing. An IDL license costs in Europe nearly more than US$ 2000.-. So
> Ana might be a good proxy for IDL].
>
>

Re: Play with virtual machines (Was: Thoughts and Opinions...)

[Larry Elmore]

"chris.danx" wrote:
> 
> "Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at> wrote in message
> news:3AE81234.267643AC@kfunigraz.ac.at...
> > Jerzy Karczmarczuk wrote:
> >
> > > It is a pity that an array-oriented FUNCTIONAL language: Sisal
> > > is dead. This is an ecological niche wide open.
> >
> > I know from a physicist at LLNL that Sisal had been the only "functional"
> > language with the potential to compare in speed against Fortran. But nobody
> > knows why they dropped Sisal.

What about J?

Larry

Re: Play with virtual machines (Was: Thoughts and Opinions...)

[Goldhammer]

On Fri, 27 Apr 2001 02:14:25 GMT, Larry Elmore <ljelmore@home.com> wrote:


>What about J?


Here is something interesting about J. Scroll down to
"Judge's Prize".

http://www.ai.mit.edu/extra/icfp-contest/winners.html

Look at the source here:

http://www.ai.mit.edu/extra/icfp-contest/j-source.txt


-- 
Don't think you are. Know you are.

Re: Play with virtual machines (Was: Thoughts and Opinions...)

[singlespeeder]

there's a critique of the JVM by the crew that wrote the dis VM for inferno
at
http://www.vitanuova.com/inferno/papers/dis.html

nick

Re: Play with virtual machines (Was: Thoughts and Opinions...)

[singlespeeder]

Sorry, that's the spec, try
http://www.vitanuova.com/inferno/papers/hotchips.html

nick

"singlespeeder" <singlespeeder@32sixteen.com> wrote in message
news:9cs2hi$jlt$1@plutonium.btinternet.com...
> there's a critique of the JVM by the crew that wrote the dis VM for
inferno
> at
> http://www.vitanuova.com/inferno/papers/dis.html
>
> nick
>
>

Re: Thoughts and Opinions or something like that

[Tarjei T. Jensen]

chris.danx wrote
>The real problem is the VM, so i'm looking for peoples thoughts on this.
What
>concepts would you have found useful, and what you'd rule out.

I would think that a VM would have to be as high level as possible in order
to be efficient. My impression is that there is a growing disparity between
memory and CPU speeds. In order to be efficient it is important to reduce
memory fetches. The VM decoding code should stay in the cache and therefore
be fast.

As far as instructions are concerned I always fancied deviding branch
instructions into two groups: Those who branch most of the time and those
who seldom branch. The idea was that one could skimp on branch prediction on
the CPU. For a while or for loop one would use the former type of
instructions. Since I have heard of nobody who have done this I assume that
the idea is not particularly good.

Greetings,

Re: Thoughts and Opinions or something like that

[Jeffrey M. Vinocur]

In article <9c642e$of323@news.kvaerner.com>,
Tarjei T. Jensen <tarjei.jensen@kvaerner.com> wrote:
>
>As far as instructions are concerned I always fancied deviding branch
>instructions into two groups: Those who branch most of the time and those
>who seldom branch. The idea was that one could skimp on branch prediction on
>the CPU. For a while or for loop one would use the former type of
>instructions. Since I have heard of nobody who have done this I assume that
>the idea is not particularly good.

Well, the goal isn't to lessen branch prediction -- the silicon
is there either way -- but rather to reduce mispredicted
branches.  The most basic approach, I guess, is assume all
backwards branches will be taken -- this gets loops.  One
not-very-complicated approach is to cache whether a branch was
taken last time through and predict the same.  This approach,
however, does exactly what you suggest; it gets loop iterations
2,3,4,...,n-1 all correct.

Re: Thoughts and Opinions or something like that

[Nicholas James NETHERCOTE]

jmv16@cornell.edu (Jeffrey M. Vinocur) writes:

>Tarjei T. Jensen <tarjei.jensen@kvaerner.com> wrote:
>>
>>As far as instructions are concerned I always fancied deviding branch
>>instructions into two groups: Those who branch most of the time and those
>>who seldom branch. The idea was that one could skimp on branch prediction on
>>the CPU. For a while or for loop one would use the former type of
>>instructions. Since I have heard of nobody who have done this I assume that
>>the idea is not particularly good.

>Well, the goal isn't to lessen branch prediction -- the silicon
>is there either way -- but rather to reduce mispredicted
>branches.  The most basic approach, I guess, is assume all
>backwards branches will be taken -- this gets loops.  One
>not-very-complicated approach is to cache whether a branch was
>taken last time through and predict the same.  This approach,
>however, does exactly what you suggest; it gets loop iterations
>2,3,4,...,n-1 all correct.

I remember seeing a suggestion somewhere for a pragma in a C-- implementation
that allowed you to estimate the probability that a condition succeeded.  So it
sounds like it must be a worthwhile idea, assuming your estimates are accurate.

--
Nick Nethercote
njn[AT]cs.mu.oz.au

Re: Thoughts and Opinions or something like that

[Keith Thompson]

jmv16@cornell.edu (Jeffrey M. Vinocur) writes:
[...]
> Well, the goal isn't to lessen branch prediction -- the silicon
> is there either way -- but rather to reduce mispredicted
> branches.  The most basic approach, I guess, is assume all
> backwards branches will be taken -- this gets loops.  One
> not-very-complicated approach is to cache whether a branch was
> taken last time through and predict the same.  This approach,
> however, does exactly what you suggest; it gets loop iterations
> 2,3,4,...,n-1 all correct.

Note that if you have multiple threads/processes/coroutines/whatever,
the threads can interfere with each other's cached branch information.

In practice, I suspect this doesn't make much difference.  You could
cache the branch information separately in each thread, but I suspect
this wouldn't be worth the effort.  It might even be harmful if it
prevents one thread from "learning" from the experience of another.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

Re: Thoughts and Opinions or something like that

[Alain Fischer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3336 bytes --]

Perhaps you can take some ideas from Smalltalk VM.
Some are very fast (only a 4:1 ratio over optimised C++).
See the tread "Integer micro-benchmarks" on comp.lang.smalltalk

Some reference:

http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_imp_toc.html
(an old implementation of Smalltalk-80)

http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html
(the story of a recent implementation of Smalltalk)

See also: www.squeak.org
Squeak is an open source implementation of Smalltalk with a decent VM
written in Smalltalk then translated in C the compiled for a lot of
platform.
The Smalltak paradigm are near from functional programing.

Have a nice day.
Alain


"chris.danx" <chris.danx@ntlworld.com> a �crit dans le message news:
HtiF6.5582$Tv2.757613@news6-win.server.ntlworld.com...
> Hi,
>     Someone on these news groups suggested to someone that in order to
make a
> reliable Virtual Machines, they needed the opinions of many programmers in
many
> languages.  {Can't remember who, some of those threads get huge and i get
lost!
> Good idea who ever it was!}
>
> I'm involved in a project to develop a VM and i was looking for peoples
thoughts
> on this.  I've started with a simple RISC machine that's not finished yet.
I
> will complete this soon, but i've been thinking my approach is flawed.
Not to
> say RISC is bad, but maybe it's too simplistic or lacks specific support
for
> features that'd make it A:more efficient and B:easier to program.
>
>
> The language project will support the following imperative features:
>
> -    For/While loops
> -    Procedures
> -    side effect enabled programming (variables)
> -    "tidy" pointers
> -    modes for parameters (only for procedures, functions nonmodified
params)
> -    Generitcity (polymorphism)
>
>
> and the following functional features
>
> -    pattern matching
> -    side effect free programming (values)
> -    higher order functions
> -    guards
> -    Algebraic types
> -    N-Tuples
> -    Genericity (polymorphisism)
>
> and the following "not sure" or "in many paradigms" features
>
> -    Units bound to values/variables
> -    Lists                         []
> -    Arrays                        <>
> -    Records
> -    Sets (and Records as Sets)    {}
> -    Enumeration types (with extensiblity and subtyping)
> -    Subtyping
> -    Relational programming (some paper i really liked described it,
prologish
>      but somewhat different)
>
>
> This list is quite exhaustive and i know it doesn't look that nice now,
but the
> work i've done so far seems to indicate this is all possible and looks
nice too.
> The major stumbling block is state->stateless programming but i'm looking
and
> trying ideas out.  Something will be done; whether or not it's pretty is
another
> matter.
>
> I know many folks get annoyed when they here about "yet another new
language"
> but this is not about the language itself.  It is about me learning about
all
> this stuff and seeing what i can do with a big collection of (sometimes
> unrelated) issues and see what can come of it.
>
> The real problem is the VM, so i'm looking for peoples thoughts on this.
What
> concepts would you have found useful, and what you'd rule out.
>
> Please feel free to ignore this if you don't want to contribute (i know
you will
> anyway).
>
>
> Regards,
> Chris
>
>

Re: Thoughts and Opinions or something like that

[brian hiles]

In comp.lang.misc chris.danx <chris.danx@ntlworld.com> wrote:
> Someone on these news groups suggested to someone that in order to make a
> reliable Virtual Machines, they needed the opinions of many programmers...

By VM do you mean the _Java_ virtual machine, bu which many language
authors are writing languages to produce jvm bytecodes, or _another_
VM for in which case it seems you are "reinventing the wheel"?

For both cases, the best use of one's effort is the time spent reviewing
the field for other programmers projects:

http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

A fascinating site!

=Brian

Re: Thoughts and Opinions or something like that

[Gregory Toomey]

I can't see where all the 'virtual machine' stuff is going.

CPU instructions are just virtual machines for the underlying microcode,
which are a virtual machine for some underlying gate logic,
which is a virtual machine for solid state physics,
which is a vittual machine for quantum machanics ...

Java has a virtual machine (listed below), compliled Prolog has the Warran
Abstract Machine, etc. The VAX (CISC) instruction set even has polynomial
instructions.

But I just can't see this is leading anywhere.


gtoomey
--------
"brian hiles" <bsh@rainey.blueneptune.com> wrote in message
news:teje2rsjqeak2e@corp.supernews.com...
> In comp.lang.misc chris.danx <chris.danx@ntlworld.com> wrote:
> > Someone on these news groups suggested to someone that in order to make
a
> > reliable Virtual Machines, they needed the opinions of many
programmers...
>
> By VM do you mean the _Java_ virtual machine, bu which many language
> authors are writing languages to produce jvm bytecodes, or _another_
> VM for in which case it seems you are "reinventing the wheel"?
>
> For both cases, the best use of one's effort is the time spent reviewing
> the field for other programmers projects:
>
> http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
>
> A fascinating site!
>
> =Brian

Re: Thoughts and Opinions or something like that

[chris.danx]

"Gregory Toomey" <gtoomey@usa.net> wrote in message
news:cPoG6.12897$482.65420@newsfeeds.bigpond.com...
> I can't see where all the 'virtual machine' stuff is going.
>

I think that's the point.

> CPU instructions are just virtual machines for the underlying microcode,
> which are a virtual machine for some underlying gate logic,
> which is a virtual machine for solid state physics,
> which is a vittual machine for quantum machanics ...
>

only if you consider physics reality, and not a model for explaining reality.
This is a distinction people often forget.  Physics is the study of natural
phenomena, by which we develop explanations for events around us according to
what we percieve.  It may explain parts of our reality but... /end of blether


> Java has a virtual machine (listed below), compliled Prolog has the Warran
> Abstract Machine, etc. The VAX (CISC) instruction set even has polynomial
> instructions.
>

VAX bit the dust a while back didn't it.  "The ultimate CISC machine!" was how i
once heard it described.  Shame...




> But I just can't see this is leading anywhere.



>
>
> gtoomey
> --------
> "brian hiles" <bsh@rainey.blueneptune.com> wrote in message
> news:teje2rsjqeak2e@corp.supernews.com...
> > In comp.lang.misc chris.danx <chris.danx@ntlworld.com> wrote:
> > > Someone on these news groups suggested to someone that in order to make
> a
> > > reliable Virtual Machines, they needed the opinions of many
> programmers...
> >
> > By VM do you mean the _Java_ virtual machine, bu which many language
> > authors are writing languages to produce jvm bytecodes, or _another_
> > VM for in which case it seems you are "reinventing the wheel"?
> >
> > For both cases, the best use of one's effort is the time spent reviewing
> > the field for other programmers projects:
> >
> > http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
> >
> > A fascinating site!
> >
> > =Brian
>
>

Re: Thoughts and Opinions or something like that

[chris.danx]

"brian hiles" <bsh@rainey.blueneptune.com> wrote in message
news:teje2rsjqeak2e@corp.supernews.com...
> In comp.lang.misc chris.danx <chris.danx@ntlworld.com> wrote:
> > Someone on these news groups suggested to someone that in order to make a
> > reliable Virtual Machines, they needed the opinions of many programmers...
>
> By VM do you mean the _Java_ virtual machine, bu which many language
> authors are writing languages to produce jvm bytecodes,

JVM sucks IMO.  It's not that i hate Java it's just it's machine is not well
planned or thought out, again IMO.


> or _another_
> VM for in which case it seems you are "reinventing the wheel"?

I'm not reinventing the wheel, and anyway what's wrong with that?  Earths
history is full of people developing things and reworking things TO MAKE THEM
BETTER FOR SPECIFIC JOBS.

Nuff said...


> For both cases, the best use of one's effort is the time spent reviewing
> the field for other programmers projects:
>
> http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
>
> A fascinating site!

Really, i looked and thought "hmm, put my language on JVM, why didn't i think of
that before?".  It's been weighed up against others ages ago, it was found to
support features that didn't work with the language goals.  I'd have to get
really stuck into the VM and figure out how to make the program work with alien
concepts.  The point of making a language unspecific VM (the RISC machine) is to
make experimentation easier.  The point of making a language specific VM is to
improve efficiency, and make the compiler simpler.  Also it fit's into the
concept of interactive programming.  Since any code block can (in theory) be run
on the VM and be examined as it's running, it's easier to test code.  If i was
to do this with the native architecture it'd be more difficult, and more
dangerous.  The VM simplifies the testing by providing the ability to watch
what's going on and halting it, changing the code, then resuming and seeing
what's going on now.

JVM might have garbage collection, but it's not been designed to work with tail
recursion, carry through unit binding, set expression, lists and what not.
These will make my life easier, and hopefully an intelligent and well designed
implementation will make them efficient and speedy.

>
> =Brian

Re: Thoughts and Opinions or something like that

[Jon Beniston]

"chris.danx" wrote:

> "brian hiles" <bsh@rainey.blueneptune.com> wrote in message
> news:teje2rsjqeak2e@corp.supernews.com...
> > In comp.lang.misc chris.danx <chris.danx@ntlworld.com> wrote:
> > > Someone on these news groups suggested to someone that in order to make a
> > > reliable Virtual Machines, they needed the opinions of many programmers...
> >
> > By VM do you mean the _Java_ virtual machine, bu which many language
> > authors are writing languages to produce jvm bytecodes,
>
> JVM sucks IMO.  It's not that i hate Java it's just it's machine is not well
> planned or thought out, again IMO.
>

So, in your opinion, what's wrong with it? How could it be improved?

JonB


>
> > or _another_
> > VM for in which case it seems you are "reinventing the wheel"?
>
> I'm not reinventing the wheel, and anyway what's wrong with that?  Earths
> history is full of people developing things and reworking things TO MAKE THEM
> BETTER FOR SPECIFIC JOBS.
>
> Nuff said...
>
> > For both cases, the best use of one's effort is the time spent reviewing
> > the field for other programmers projects:
> >
> > http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
> >
> > A fascinating site!
>
> Really, i looked and thought "hmm, put my language on JVM, why didn't i think of
> that before?".  It's been weighed up against others ages ago, it was found to
> support features that didn't work with the language goals.  I'd have to get
> really stuck into the VM and figure out how to make the program work with alien
> concepts.  The point of making a language unspecific VM (the RISC machine) is to
> make experimentation easier.  The point of making a language specific VM is to
> improve efficiency, and make the compiler simpler.  Also it fit's into the
> concept of interactive programming.  Since any code block can (in theory) be run
> on the VM and be examined as it's running, it's easier to test code.  If i was
> to do this with the native architecture it'd be more difficult, and more
> dangerous.  The VM simplifies the testing by providing the ability to watch
> what's going on and halting it, changing the code, then resuming and seeing
> what's going on now.
>
> JVM might have garbage collection, but it's not been designed to work with tail
> recursion, carry through unit binding, set expression, lists and what not.
> These will make my life easier, and hopefully an intelligent and well designed
> implementation will make them efficient and speedy.
>
> >
> > =Brian

Re: Thoughts and Opinions or something like that

[Biep @ http://www.biep.org]

Be sure your VM supports full continuations.  Or let it expect CPS programs
and have the compilers do the translation..

Also, you might want to look at oz (http://www.mozart-oz.org) for some
ideas.

--
Biep
Reply via http://www.biep.org