[M3devel] LINUXLIBC6

[Jay K]

C-- is not actively maintained I believe, so not a good idea to use.  C and C++ are much more portable and "maintained" (C++ gives us more portable efficient exception handling.)  (There is a good C and C++ compiler for every mainstream system in use today  LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.It is a bit of a chore to learn and use.  JIT isn't a crazy idea either..or rather, an interpreter.If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.  (In reality you don't want to start with parse.c because of the GPL.)  And, interesting point as well, an interpreter in Java or C# or whatever is "more native" on e.g. Android and Windows Phone, is also not too difficult. You could do it in a low level fashion that is viable in "safe" environments.Search the web for "XML VM". I know it is nonsense term, but the project is/was real, despite the name, it is a viable approach.  What they did is this:  "convert" (i.e. dump faithfully and without optimization or fitting any uniform scheme) Java .class files and .NET IL into XML.  Write XML Style Sheets (XSL) to transform to whatever -- including JavaScript and C.  Write some supporting libraries.  As a result, they could "compile" Java to C and run on iPhone, "compile" Java to JavaScript and run in browser (Yes, I know about Google Web Toolkit.)    - Jay
 Date: Fri, 18 May 2012 18:16:59 +0100
From: dabenavidesd at yahoo.es
To: dragisha at m3w.org
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] LINUXLIBC6

Hi all:
After ESC we do need much debugger at all, in fact it was designed for that for avoiding put much time on it.
Still if we generate C is for super-optimization (but verified also mechanically), so I don't mind that, but for code quality I prefer C, I agree absolutely in that we should support it again for that purpose (as originally).
As for not verified code we should stick with C--, as it is written for that purposes, but for portability specially with implicit safety.
And for not verified nor optimal and not common use code (like mentor) we should make them source packages (in fact If they are written in Obliq we don't want to redistribute that as non-source), instead part of m3-demo package subdirectory or so.
I think for M3CG is that we need a LLVM or so back-end for JIT.
Thanks in advance

--- El vie, 18/5/12, Dragiša
 Durić <dragisha at m3w.org> escribió:

De: Dragiša Durić <dragisha at m3w.org>
Asunto: Re: [M3devel] LINUXLIBC6
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: viernes, 18 de mayo, 2012 11:58

One thing we also drop is to source level debug modula-3, if we choose to go along generate-C pathway.
On May 17, 2012, at 1:40 AM, Jay K wrote:  But heck, really, if we generate C, then targets largely drop away.  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120518/33fcf5fa/attachment-0002.html>