ApochPiQ, on 24 May 2013 - 19:44, said:

cr88192, on 24 May 2013 - 15:16, said:
the language is still C, and still behaves pretty much like plain old C and can use native-compiled libraries and so on, but rather than being compiled directly to native code, is compiled first to a bytecode format, and possibly compiled to native code for each target (such as via a JIT compiler, or maybe an AOT compiler), allowing an increased range of portability (no need to recompile a "reasonably written" application to run on various targets, provided the VM is available).

So, basically, C except with a lot of extra cruft and points of failure...


I don't understand this at all. Well-written C is already highly portable. If you want even more portability you're making a language that is no longer C. And you'd have to murder most of C to get any more portable, at which point you probably want to design a cleaner barebones language than what would be left of C so you could, y'know, actually do non-trivial stuff in it.

only if significant design changes were made to the language.
if the language is basically pretty much as it was before, and still conforms with the C standards, it is still C.

well written code should ideally be able to be compiled via such a tool chain, or directly as native code, and if done well, the differences here should be mostly invisible (as in, pretty much everything works just as it does in native).

though, yes, some of the mentioned features would require additional #ifdef's, but nothing new there.

though, in general: if people have to see the results of what you have done, you have done it wrong.

most likely, a person would go mix and match, using one set of tools or another, as it suits their purposes.

Quote
Adding a VM/JIT layer does not increase portability by any stretch of the imagination - if anything, it's exactly the opposite. C or nearly-C targets exist for virtually every piece of processing hardware. Your proposed solution is actually a liability for someone wanting portability, because they would have to wait for your tool chain to add support for a platform that probably already has a working C compiler.

Wanting C and a VM layer is kind of counterproductive. Either make a better language in general, or just... use C.

granted...

there are difficulties with the idea (not all of which are readily solvable), and this is partly why I have not put a whole lot of effort into this already (despite having previously already written a C compiler...).

but, there might be cases though where being able to copy binaries without recompiling could be a selling point, and if people actually cared or were interested, it could be worthwhile...

hence the whole "make it not suck" requirement, pretty much a whole lot is predicated on this one.


the problem with "better" languages is typically that it requires effort to port code to them, and none is really better for everything.

for the most part, the C/C++/Java/C#/JS/AS3/... are "sort of in about the right general area", but there is still a mess of ugly seams (different pieces of technology that still don't really play well together).

the world needs some stronger glue here (ideally, so that all this stuff can be glued together).


the rest of the matter, like actually porting the tools and tool-chain, well, who knows there...
if the code is available, then it isn't too much different than with anything else, just "another set of tools for the toolbox".

so, like, it is more about whatever might be a better or worse solution for a given use-case.
sort of like people using Emscripten to compile C into JavaScript.

a good solution in general?... probably not.
a good solution for certain use cases?... probably (probably does at least beat out trying to manually port stuff over to JavaScript, or maybe vs porting to Java so it can be shoved into a Java applet, ...).

and, hypothetically, if your app is compiled to a reasonably portable bytecode, and a VM implementation could also be written in JavaScript or Java, then suddenly, much of the need to port the whole app to JS or Java can be side-stepped...

"?" Attempting anything results in undefined behaviour.

I'd name it "Kihon" (martial arts term meaning basic or fundamental), and it would be probably be terrible, but in my fantasy, it would be a mongrel blend of python and C# with lots of explicit support for multi threading.

There are two things I've thought about. A C# version with more functional aspects, in particular the ability to tag functions and methods as pure meaning they can have no side effects as well as immutable types (you can create immutable types, but not really language enforced). I wouldn't be the slightest surprised if this was implemented in the near future though.

The other one is a low-level language intended to be link compatible with C++. The idea is basically to create a cleaned up version of C++: remove/replace (or at least reduce the role of) the preprocessor, remove the requirement for stuff to be declared before use (types, functions and methods can be declared in any order and in separate files without includes), make errors of various common pitfalls (remove some implicit type casts, require initialization before use, ...), standardize default types (int is 32 bits and long is 64) and create a new "platform int" which is always the best size for the target. I want to clean up the syntax slightly. I also want to include real delegates (as in C#/.NET) into the language. I would also want to review templates and class inheritance to make the rules stricter and less easy to misuse.

Having a smaller, cleaner and stricter language could greatly help with readability and stability. By compiling down to standard C++ (or even C), some of the core strengths of C++ would be maintained (mature toolchains and platform adaptation).

EasyC

Basically a scripting language version of c++. Thus, allowing you to have manual memory management on the fly without recompiling. Although it would be optional, and you could turn off pointers by checking a box.You could also use it with game engines instead of something like UnrealScript, UnityScript, TorqueScript, blah blah blah. This giving c++ programmers an easy way to use scripting without learning whole 'nother language. But I have no idea what im talking about though, and no idea if this is feasible.

Jarvis - programming can only be done verbally.

EasyC

Basically a scripting language version of c++. Thus, allowing you to have manual memory management on the fly without recompiling. Although it would be optional, and you could turn off pointers by checking a box.You could also use it with game engines instead of something like UnrealScript, UnityScript, TorqueScript, blah blah blah. This giving c++ programmers an easy way to use scripting without learning whole 'nother language. But I have no idea what im talking about though, and no idea if this is feasible.

FWIW, some scripting languages (mine, for example), do have manual memory management, and also pointers. (FWIW, my scripting VM is technically GC'ed, but the GC is kind of slow and unreliable, so it is better to manually 'delete' things, or in other cases use structs or value-classes). it is also, in its present form, statically-typed (more or less), and generally uses a "kind-of Java-like" syntax...

technically, the pointers it provides are not raw "narrow pointers", but more often what I call "boxed pointers" (essentially "fat pointers"), which are typically more strictly typed and which use bounds-checking.

also a lot of work has been put in making it play nicely with native C code, but sadly C++ support is a bit lacking (only some of the tools support C++, and typically only a subset, and there is also the matter of supporting multiple various C++ ABI's, mostly as details like the exact physical class-layout and name mangling will often differ between one compiler and another, or one compiler version and another, ...).

I have a few times though thought that similar technology can be applied to C (and possibly a similar C++ subset, *1).

*1: basically, supporting classes, operator overloading, and possibly namespaces (only some of my tools presently support namespaces). templates are likely to be absent (thoughts of trying to implement this feature raise some uncertainty...).

a drawback of both C and C++ is that basically, if keeping the languages in their standards-compliant forms, there is no good way to make the compile times much faster than with native compilers. this need not kill off C (or C++) based scripting though, since there is still the possibility of "compile-and-cache" (where the results of compiling are stored off somewhere, and reused later). however, usable eval is a separate issue.

basis: partly in the past I had experimented with implementing/using a similar piece of technology, just it had compiled to native code (at the time, the problems of compiler performance and debugging the native code-generator, largely killed this off). compiling instead to bytecode could allow more room for an interpreter-based backend (with JIT offered on "major" targets, but otherwise allowing for a plain-C interpreter), where interpreters are a little easier to debug.

another issue originally was that the use of raw pointers made it too easy to crash the engine from script-code, though fat-pointers can help here, as well as at least giving "some" hope of keeping the code effectively "sandboxed" (I think it can be done, but I will probably not go into it here). note that the internal use of fat-pointers (and pointer validation, ...) could be kept largely invisible from the high-level code.

of course, there is also the "elephant in the room" that is LLVM/Clang.

as well as there being some other C or C++ based interpreters, and compilers to various VM backends, ...

Here we go for another thread cr88192 takes seriously.

Here we go for another thread cr88192 takes seriously.

just responding to comments and giving information is all...

(mostly: my ability to spot patterns has seemingly found a pattern... and it caught some interest, but mostly in a "can it work? most probably!..." sense...).

What, exactly, does "VM managed C" even mean?

the language is still C, and still behaves pretty much like plain old C and can use native-compiled libraries and so on, but rather than being compiled directly to native code, is compiled first to a bytecode format, and possibly compiled to native code for each target (such as via a JIT compiler, or maybe an AOT compiler), allowing an increased range of portability (no need to recompile a "reasonably written" application to run on various targets, provided the VM is available).

...

I remember writing one of those. It was the coolest thing, designing this little architecture with a C compiler, and it was so powerful and could use native libraries, and could be rigged like a normal scripting language... until I realized it could do too much. The tasks for which I needed a scripting language were so high performance, that using a general scripting VM with a language based on C resulted in it being unusably inefficient, unless I went all out and essentially made a "C to byte code to ASM" compiler, which defeated the purpose of compiling to byte code in the first place, since it wouldn't nearly save me any time, having to write JIT interpreters for every platform that already had a C compiler.

In the end, I wound up putting the VM on a shelf, and designing several smaller, but much, much faster VMs with more specialized languages for their purposes. It does give me great interest to see others doing similar projects, though.