siod Forum Rss Feed

New Post: is it possible to treat managed C++ and just another port?

raould — Sun, 24 Aug 2008 23:24:44 GMT

could you "redirect" to using the CLR's GC system?

NEW POST: is it possible to treat managed C++ and just another port?

publius — Sat, 14 Apr 2007 11:51:19 GMT

I have done an initial port to CLR. Things that trigger "native code generation" were removed.

1. valist, varstart,vaend, vaarg. So instead of having listn, I have made list2,list3. Perhaps there is another implementation of "..." which does not generate a warning in CLR. Using it in portable code by using macros might be tricky. This is unfortunate, because "..." can be used to considerably reduce the verbosity of code.

2. all the garbage collector related stuff removed. lookspointerp, and stackstartptr. gcmarkandsweep(), the use of jmp_buf structure. Just removed.

3. stacklimitptr removed, and STACK_CHECK(X) macro is a no-op.

4. the jmpbuf removed from the catchframe structure. And all code that referenced it. Also other calls to setjmp and longjmp removed.

I also did a bit of rewrite around functions that are warned as
being unsafe or security risks. Of course this could also be done
in the C version as well. sprintf, strcat, getenv, etc. But the thing
that confused me about this was why, in a fully managed environment
these functions would be unsafe? Doesn't even a raw char * in managed
code have a length associated with it that comes from the point
where you called malloc to get the memory in the first place? Perhaps
not. (In the LISPMACHINE implementations of C of course this was done,
and C pointers were a kind of locative, or closure, into other
structures).

Anyway, the result is code that works, read-eval-print, but no garbage
collector. I will post it to the site, as soon as the TFS here on
codeplex is running again.

NEW POST: icons used during the install

publius — Sat, 07 Apr 2007 16:41:15 GMT

Thanks to Brad Parker, http://www.unlambda.com/ for the graphics used in the installer splash screens and the wcsiod.exe program icon.

NEW POST: is it possible to treat managed C++ and just another port?

publius — Mon, 26 Feb 2007 19:13:01 GMT

Here is the fundamental question. Is it possible to have an application written in C and to treat it as just another port when run in a managed C++ environment?
Can we keep the source code relatively clean, and compile from the same sources for platforms
as divergent as Cygwin, Linux, unmanaged C, managed C++, and in different operating systems,
and CLR such as Windows .NET and Linux Mono?

Experience with Purify and some very old C interpreters, including the C compiler for the CADR circa 1982, suggest that it is possible to do this, as long as the overhead of dealing
with the "MAKE/BUILD" environment does not get out of control.

We've been dealing with differences between C compilers for 30 years, and know that it is not
intractable.

the purpose and goals of this project:

publius — Sat, 24 Feb 2007 17:06:57 GMT

The source code for the SIOD scheme interpreter has been available for
nearly 20 years, most recently (since the 1990's) from
http://alum.mit.edu/www/gjc/siod.html. What is the purpose for
hosting it on CodePlex now?

The earliest versions of SIOD were particularly small, such that
definining and executing a small function such as "factorial" or "fib" could
provide as much as 80% code-coverage. This made them attractive to people
who want to test a new C compiler for the first time on some small but
not entirely trivial program. To that end I want to investigate the issues
of porting ugly C programs into managed code, and to evaluate the
garbage collection and performance issues before embarking on a larger
lisp implementation project.

There are a couple ways to take SIOD into the managed code space.
The obvious way is to avoid the explicit management of heaps, and
just allocate storage in small chunks using the CLR, and let the CLR
take care of all the storage management. SIOD is small enough to
fully document the entire porting process, any the issues that come up,
before dealing with other favorite programs of the 1980's, such as Emacs.

Another purpose is to evaluate how easy it is to use the visual studio
express integration with the codeplex source code management.