Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end From: BGB Newsgroups: comp.compilers Subject: Re: target platforms and .NET, was GCC is 25 years old today Date: Sat, 31 Mar 2012 13:08:08 -0700 Organization: albasani.net Lines: 178 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-03-075@comp.compilers> References: <12-03-051@comp.compilers> <12-03-053@comp.compilers> <12-03-062@comp.compilers> <12-03-068@comp.compilers> <12-03-069@comp.compilers> <12-03-072@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: leila.iecc.com 1333225136 24328 64.57.183.58 (31 Mar 2012 20:18:56 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 31 Mar 2012 20:18:56 +0000 (UTC) Keywords: VM, code Posted-Date: 31 Mar 2012 16:18:56 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:542 On 3/30/2012 1:33 PM, BGB wrote: > either way, it wouldn't work with Mono. > theoretically, a .NET port of the VM could be made, but I am not > personally inclined to bother with this. > [Porting to .NET would be a challenge, since you'd have to graft on > the whole .NET type system. -John] yes, granted. me wandering off pretty far from the original topic here, oh well. I can imagine bigger issues though: be lazy, port to C++/CLI, live with the issue that it wont work on Mono; or, having to largely re-implement the VM in C# (would likely be a huge pain, and would likely almost be better off as a largely ground-up reimplementation). the type-system shouldn't be as much of a challenge, since technically .NET can do vaguely similar stuff to what my typesystem does, and other parts of the design were partly inspired by C# anyways (the static type hierarchy is fairly similar). a few major influences: ECMAScript, ActionScript, Java, C#, C, and C++, as well as lesser influences: Scheme, Self, Erlang, ... the language roughly implements ECMA-262, but deviates in some cases. similarly, BGBScript already supports Class/Instance OO, references, properties, ... note: it also still has Prototype-OO, internally a "hybrid" object model is used. externally, this is exposed similar to in ActionScript3, whereby using a "dynamic" modifier on a class declaration allows addition of new fields at runtime (otherwise, a fixed layout is used). objects created ex-nihilo are implicitly both dynamic and lack a parent class (internally, there are about 3 different "types" of object, with the "dynamic class" case being a class/instance object daisy-chained with a prototype/"dictionary" object, which is apparently different from how it works in ActionScript, but then again, I also implemented interfaces via a large hash-table as well...). note: there is a partial split between static and dynamic types, as the "static type system" vaguely represents a Java/C# style type-system, and the "dynamic type system" uses a different set of types (so, it is not strictly 1:1, unlike Java or C#). hence: var i:int; //integer variable (32-bit range) var j:fixnum; //fixnum variable (currently 28 or 48 bit range) car k:long; //long variable (64-bit range) var v; //variant (default type) v=i; //may convert to fixnum or a boxed int (depending on range) v=j; //copied directly (may be slightly cheaper in some cases) v=k; //currently converts to boxed long note that type coercion works more like C, with most types converting freely when possible, although potentially implicit down-casting could be made to generate a warning. var b:bool; b=i; //"warn: implicit type conversion from int to bool" or similar. variant is not exactly the same as "object" in C#, differing mostly in fine details (in certain cases, type-inference is allowed to convert it to a static type, although it will always be a variant/reference if used as an explicit storage type). note that the default array type is "variant[]", and arrays will be this type except in certain cases (creation via "new type[size]", array-type suffixes, or being used to initialize a variable with a declared array type "var arr:int[]=[1,2,3];"). struct Foo { var obj:variant; //will not be inferred var obj2; //likewise } note: structs have similar behavior to C#, and are pass-by-value / pass-by-copy. there is also "value_class", which is conceptually similar (but is a full class type, sort of like in C++, but lacking MI). internally, structs and value-classes are aliases (but, they are not strictly equivalent regarding their semantics). note: the same basic mechanism is used to access C structs, and could potentially be extended to support C++ classes, but more work would be needed for this (mostly for supporting vtables and similar, but it has not been a high priority). extra note: "dynamic value_class" is not allowed, maybe for obvious enough reasons. value-classes have a fixed memory layout. example: value_class Foo { ... } var obja:Foo; //value class var objb:*Foo; //pointer to value class var objc:Foo; //value class obja=new Foo(); //init obja (1) objb=&obja; //pointer to obja (2) objc=obja; //copy of obja (may invoke copy-constructor, 3) ... note 1: value classes are implemented differently than in C++ or similar, in that they are still handled as reference-types (to heap allocated instances). their primary difference is that they are subject to copy/delete semantics (they are deleted when they go out of scope, which will call the destructor if one exists). granted, this isn't particularly efficient, but whatever. note 2: currently, there is no construct to directly initialize a "pointer to a value-class", but something like "new *Foo()" or similar is a possible syntax. technically, "&obja" creates a reference, but references may be implicitly converted to pointers. note 3: functionally similar to "objc=new Foo(obja);" if a valid constructor exists (otherwise, a raw copy is made). side node, the syntax: int i; string str; ... is supported, just it is harder to claim that the language is still an ECMAScript variant, if one is sitting around using lots of declarations which are clearly a different style from ECMAScript. these cases are parsed more like in Java/C# than like in C or C++ though. also, unlike C or C++, pointers are declared with '*' in prefix position "*int pi;" rather than "int *pi;", this change having been made to avoid potentially ambiguous syntax (for a similar reason, the language doesn't use C style cast syntax, instead using a different syntax: "x as type" and "x as! type"). by convention, I am typically staying closer to ECMAScript style. a bigger challenge (if trying to produce CIL) could be the scoping model, where my language uses a scoping model partly influenced by Self, which is relatively uncommon and lacks .NET support. lesser worries are that .NET lacks direct fixnum and flonum analogues, and they would instead have to be implemented via boxed types, which would be more expensive (a boxed type being generally a heap-allocated object, vs a value encoded directly into the pointer). this is also one point (among others) where my language fails regarding ECMA-262 conformance: I don't default to using double for numbers, because I would have to box doubles, and this would be expensive. so, cheaper fixnums and flonums are used, but flonums are considerably less accurate than a double (on 32-bit targets, they are a 32-bit float with the low-order bits shaved off, and on 64-bit targets is a 64-bit double with low-order bits shaved). luckily, I have no plans to port to .NET, and am not at present all that concerned even with making a nice C#/BS interface. likely higher priorities: finish implementing the new JIT / native-compiler; implement some good way to directly produce (native friendly) DLLs without needing to first generate and compile C glue-code (IOW: a custom static linker); ... but, as such, these are still not terribly high priorities for my project as a whole.