* Thoughts and Opinions or something like that @ 2001-04-24 17:12 chris.danx 2001-04-24 21:35 ` Ted Dennison ` (5 more replies) 0 siblings, 6 replies; 28+ messages in thread From: chris.danx @ 2001-04-24 17:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-24 17:12 Thoughts and Opinions or something like that chris.danx @ 2001-04-24 21:35 ` Ted Dennison 2001-04-24 23:27 ` chris.danx 2001-04-25 7:40 ` Andrew Cooke ` (4 subsequent siblings) 5 siblings, 1 reply; 28+ messages in thread From: Ted Dennison @ 2001-04-24 21:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-24 21:35 ` Ted Dennison @ 2001-04-24 23:27 ` chris.danx 0 siblings, 0 replies; 28+ messages in thread From: chris.danx @ 2001-04-24 23:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-24 17:12 Thoughts and Opinions or something like that chris.danx 2001-04-24 21:35 ` Ted Dennison @ 2001-04-25 7:40 ` Andrew Cooke 2001-04-25 10:42 ` chris.danx [not found] ` <3AE69665.63E362CD@info.unicaen.fr> 2001-04-25 9:06 ` Thoughts and Opinions or something like that Tarjei T. Jensen ` (3 subsequent siblings) 5 siblings, 2 replies; 28+ messages in thread From: Andrew Cooke @ 2001-04-25 7:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-25 7:40 ` Andrew Cooke @ 2001-04-25 10:42 ` chris.danx 2001-04-25 17:26 ` Warren W. Gay VE3WWG 2001-04-26 14:22 ` Marcin 'Qrczak' Kowalczyk [not found] ` <3AE69665.63E362CD@info.unicaen.fr> 1 sibling, 2 replies; 28+ messages in thread From: chris.danx @ 2001-04-25 10:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-25 10:42 ` chris.danx @ 2001-04-25 17:26 ` Warren W. Gay VE3WWG 2001-04-26 14:22 ` Marcin 'Qrczak' Kowalczyk 1 sibling, 0 replies; 28+ messages in thread From: Warren W. Gay VE3WWG @ 2001-04-25 17:26 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-25 10:42 ` chris.danx 2001-04-25 17:26 ` Warren W. Gay VE3WWG @ 2001-04-26 14:22 ` Marcin 'Qrczak' Kowalczyk 1 sibling, 0 replies; 28+ messages in thread From: Marcin 'Qrczak' Kowalczyk @ 2001-04-26 14:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <3AE69665.63E362CD@info.unicaen.fr>]
* Re: Thoughts and Opinions or something like that [not found] ` <3AE69665.63E362CD@info.unicaen.fr> @ 2001-04-25 10:51 ` chris.danx 2001-04-25 13:51 ` Jerzy Karczmarczuk [not found] ` <3AE6DAB3.899FF645@andrewcooke.free-online.co.uk> 1 sibling, 1 reply; 28+ messages in thread From: chris.danx @ 2001-04-25 10:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-25 10:51 ` chris.danx @ 2001-04-25 13:51 ` Jerzy Karczmarczuk 2001-04-25 13:52 ` chris.danx 0 siblings, 1 reply; 28+ messages in thread From: Jerzy Karczmarczuk @ 2001-04-25 13:51 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-25 13:51 ` Jerzy Karczmarczuk @ 2001-04-25 13:52 ` chris.danx 0 siblings, 0 replies; 28+ messages in thread From: chris.danx @ 2001-04-25 13:52 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <3AE6DAB3.899FF645@andrewcooke.free-online.co.uk>]
* Re: Thoughts and Opinions or something like that [not found] ` <3AE6DAB3.899FF645@andrewcooke.free-online.co.uk> @ 2001-04-25 14:30 ` chris.danx [not found] ` <3AE7E37B.F384DCDA@info.unicaen.fr> 1 sibling, 0 replies; 28+ messages in thread From: chris.danx @ 2001-04-25 14:30 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <3AE7E37B.F384DCDA@info.unicaen.fr>]
* Re: Play with virtual machines (Was: Thoughts and Opinions...) [not found] ` <3AE7E37B.F384DCDA@info.unicaen.fr> @ 2001-04-26 9:02 ` chris.danx [not found] ` <3AE81234.267643AC@kfunigraz.ac.at> 1 sibling, 0 replies; 28+ messages in thread From: chris.danx @ 2001-04-26 9:02 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <3AE81234.267643AC@kfunigraz.ac.at>]
* Re: Play with virtual machines (Was: Thoughts and Opinions...) [not found] ` <3AE81234.267643AC@kfunigraz.ac.at> @ 2001-04-26 12:57 ` chris.danx 2001-04-27 2:14 ` Larry Elmore 0 siblings, 1 reply; 28+ messages in thread From: chris.danx @ 2001-04-26 12:57 UTC (permalink / raw) "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]. > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Play with virtual machines (Was: Thoughts and Opinions...) 2001-04-26 12:57 ` chris.danx @ 2001-04-27 2:14 ` Larry Elmore 2001-04-27 3:27 ` Goldhammer 0 siblings, 1 reply; 28+ messages in thread From: Larry Elmore @ 2001-04-27 2:14 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Play with virtual machines (Was: Thoughts and Opinions...) 2001-04-27 2:14 ` Larry Elmore @ 2001-04-27 3:27 ` Goldhammer 2001-05-03 17:00 ` singlespeeder 0 siblings, 1 reply; 28+ messages in thread From: Goldhammer @ 2001-04-27 3:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Play with virtual machines (Was: Thoughts and Opinions...) 2001-04-27 3:27 ` Goldhammer @ 2001-05-03 17:00 ` singlespeeder 2001-05-03 17:03 ` singlespeeder 0 siblings, 1 reply; 28+ messages in thread From: singlespeeder @ 2001-05-03 17:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Play with virtual machines (Was: Thoughts and Opinions...) 2001-05-03 17:00 ` singlespeeder @ 2001-05-03 17:03 ` singlespeeder 0 siblings, 0 replies; 28+ messages in thread From: singlespeeder @ 2001-05-03 17:03 UTC (permalink / raw) 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 > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-24 17:12 Thoughts and Opinions or something like that chris.danx 2001-04-24 21:35 ` Ted Dennison 2001-04-25 7:40 ` Andrew Cooke @ 2001-04-25 9:06 ` Tarjei T. Jensen 2001-04-25 12:12 ` Jeffrey M. Vinocur 2001-04-25 12:09 ` Alain Fischer ` (2 subsequent siblings) 5 siblings, 1 reply; 28+ messages in thread From: Tarjei T. Jensen @ 2001-04-25 9:06 UTC (permalink / raw) 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, ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-25 9:06 ` Thoughts and Opinions or something like that Tarjei T. Jensen @ 2001-04-25 12:12 ` Jeffrey M. Vinocur 2001-04-26 2:12 ` Nicholas James NETHERCOTE 2001-04-26 18:23 ` Keith Thompson 0 siblings, 2 replies; 28+ messages in thread From: Jeffrey M. Vinocur @ 2001-04-25 12:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-25 12:12 ` Jeffrey M. Vinocur @ 2001-04-26 2:12 ` Nicholas James NETHERCOTE 2001-04-26 18:23 ` Keith Thompson 1 sibling, 0 replies; 28+ messages in thread From: Nicholas James NETHERCOTE @ 2001-04-26 2:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-25 12:12 ` Jeffrey M. Vinocur 2001-04-26 2:12 ` Nicholas James NETHERCOTE @ 2001-04-26 18:23 ` Keith Thompson 1 sibling, 0 replies; 28+ messages in thread From: Keith Thompson @ 2001-04-26 18:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-24 17:12 Thoughts and Opinions or something like that chris.danx ` (2 preceding siblings ...) 2001-04-25 9:06 ` Thoughts and Opinions or something like that Tarjei T. Jensen @ 2001-04-25 12:09 ` Alain Fischer 2001-04-27 18:20 ` brian hiles 2001-05-04 8:49 ` Biep @ http://www.biep.org 5 siblings, 0 replies; 28+ messages in thread From: Alain Fischer @ 2001-04-25 12:09 UTC (permalink / raw) [-- 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 > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-24 17:12 Thoughts and Opinions or something like that chris.danx ` (3 preceding siblings ...) 2001-04-25 12:09 ` Alain Fischer @ 2001-04-27 18:20 ` brian hiles 2001-04-28 1:27 ` Gregory Toomey 2001-04-28 21:34 ` chris.danx 2001-05-04 8:49 ` Biep @ http://www.biep.org 5 siblings, 2 replies; 28+ messages in thread From: brian hiles @ 2001-04-27 18:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-27 18:20 ` brian hiles @ 2001-04-28 1:27 ` Gregory Toomey 2001-04-28 21:34 ` chris.danx 2001-04-28 21:34 ` chris.danx 1 sibling, 1 reply; 28+ messages in thread From: Gregory Toomey @ 2001-04-28 1:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-28 1:27 ` Gregory Toomey @ 2001-04-28 21:34 ` chris.danx 0 siblings, 0 replies; 28+ messages in thread From: chris.danx @ 2001-04-28 21:34 UTC (permalink / raw) "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 > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-27 18:20 ` brian hiles 2001-04-28 1:27 ` Gregory Toomey @ 2001-04-28 21:34 ` chris.danx 2001-04-30 8:31 ` Jon Beniston 1 sibling, 1 reply; 28+ messages in thread From: chris.danx @ 2001-04-28 21:34 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-28 21:34 ` chris.danx @ 2001-04-30 8:31 ` Jon Beniston 0 siblings, 0 replies; 28+ messages in thread From: Jon Beniston @ 2001-04-30 8:31 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Thoughts and Opinions or something like that 2001-04-24 17:12 Thoughts and Opinions or something like that chris.danx ` (4 preceding siblings ...) 2001-04-27 18:20 ` brian hiles @ 2001-05-04 8:49 ` Biep @ http://www.biep.org 5 siblings, 0 replies; 28+ messages in thread From: Biep @ http://www.biep.org @ 2001-05-04 8:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2001-05-04 8:49 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-24 17:12 Thoughts and Opinions or something like that chris.danx 2001-04-24 21:35 ` Ted Dennison 2001-04-24 23:27 ` chris.danx 2001-04-25 7:40 ` Andrew Cooke 2001-04-25 10:42 ` chris.danx 2001-04-25 17:26 ` Warren W. Gay VE3WWG 2001-04-26 14:22 ` Marcin 'Qrczak' Kowalczyk [not found] ` <3AE69665.63E362CD@info.unicaen.fr> 2001-04-25 10:51 ` chris.danx 2001-04-25 13:51 ` Jerzy Karczmarczuk 2001-04-25 13:52 ` chris.danx [not found] ` <3AE6DAB3.899FF645@andrewcooke.free-online.co.uk> 2001-04-25 14:30 ` chris.danx [not found] ` <3AE7E37B.F384DCDA@info.unicaen.fr> 2001-04-26 9:02 ` Play with virtual machines (Was: Thoughts and Opinions...) chris.danx [not found] ` <3AE81234.267643AC@kfunigraz.ac.at> 2001-04-26 12:57 ` chris.danx 2001-04-27 2:14 ` Larry Elmore 2001-04-27 3:27 ` Goldhammer 2001-05-03 17:00 ` singlespeeder 2001-05-03 17:03 ` singlespeeder 2001-04-25 9:06 ` Thoughts and Opinions or something like that Tarjei T. Jensen 2001-04-25 12:12 ` Jeffrey M. Vinocur 2001-04-26 2:12 ` Nicholas James NETHERCOTE 2001-04-26 18:23 ` Keith Thompson 2001-04-25 12:09 ` Alain Fischer 2001-04-27 18:20 ` brian hiles 2001-04-28 1:27 ` Gregory Toomey 2001-04-28 21:34 ` chris.danx 2001-04-28 21:34 ` chris.danx 2001-04-30 8:31 ` Jon Beniston 2001-05-04 8:49 ` Biep @ http://www.biep.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox