----- Original Message -----
From: "John Leuner" <[EMAIL PROTECTED]>
To: "Fundamentals of New Computing" <[email protected]>
Sent: Friday, December 05, 2008 4:44 AM
Subject: Re: [fonc] x86_64...
On Thu, 2008-12-04 at 18:04 +0100, Michael Haupt wrote:
Hi,
today I migrated to a new machine at work, a nice and fast dual-core
64 bit box. Building COLA works fine as long as only idc is concerned;
building jolt blows up (obviously):
-----
cp: cannot stat 'CodeGenerator-x86_64.st': No such file or directory
-----
I found an e-mail from Martin McClure saying that he was working on
code generation support for x86_64 (in August). Has there been some
progress?
Is there *any* way for me to make it work (32 bit chroots aside)?
Please don't say I have to implement the code generation myself, I
don't quite feel competent. ;-)
I do all my development on a 64-bit machine, but I generate 32-bit ELF
object files and 32-bit executables. They run just fine and gdb handles
them fine too.
So if you compiled idc and jolt with flags to create 32-bit binaries it
might work ...
John
all of this had prompted me to look at the code for this project...
it is interesting, there is Coke which is a Scheme-like language and which
is apparently directly interfacing with C land.
my guess is that the interface is largely untyped?... (I infer this both
from the way this is done, and the presence of occasional explicit type
annotations).
the apparent addition of some elements of Smalltalk style syntax is also
interesting (granted, I personally have a far easier time understanding
Scheme than ST though...).
I have not looked, but it is presumably the case that people can compile ST
to Coke?...
apparently both this, and my effort, had independently discovered the idea
of having 2 different this/self values (in my case, this was due to the
issue of mixing delegation with class/instance, where I have delegation
methods which accept the self which recieved the original method call, and
normal virtual methods get the self from the object containing the method).
however beyond this I suspect the object systems differ notably (my system
is based mostly on the use of a class/instance system and interfaces).
some of this has implications for my effort:
hmm, I could forsake my recent idea of implementing a PostScript based
mini-language and implement a Scheme based one instead (potentially
borrowing a few ideas from Coke and similar, but adapting them more for use
in my case).
the projects themselves somewhat differ in that mine is written primarily in
C...
for my uses (and also to further my commitment to getting the JVM component
more written), I will probably target the thing to my modified/extended
JVM/JBC (likely, I will target the VM directly, rather than generating class
files and running them through the classloader, since this would save both
time and effort).
most of this VM is written, it just lacks some components (such as exception
handling, ...), and thus far I have made no attempt to make the classpath
work on it.
this will, however, potentially lead to a kind of hack used before in my
assembler/linker process, namely where to export object files it actually
translates from the representation in terms of the internal structures.
this would also probably ease retargeting my existing (incomplete)
JavaScript frontend, since I internally use a Scheme-like representation for
the upper end of the compiler.
so, pros (in my case):
Scheme is a much more enjoyable language to use than PostScript (... ever
tried hand-coding all that much PS code?...);
I already have the needed parser, printer, and core types (part of my core
typesystem lib, where I often use S-Exps as an internal data representation
in my projects);
this is would be similar to my existing JS frontend, thus reducing work to
retarget;
could be easily adapted to most other dynamic languages.
cons:
the compilation process from S-Exps to bytecode is more involved than that
from PS to bytecode;
complicates the path of eventually targetting C to this VM (requires either
changing upper-compiler to produce S-Exp output rather than RPN output, or
to produce class files).
other implications:
since PS syntax would not be used for JBC, explicitly targeting JBC would
require the use the JVM-assembler I wrote (uses a variation of Jasmin-style
syntax);
in time it may also make sense to add a JIT backend to this modified JVM;
it may make sense to try to find some good way to escape the JVM's stupid
little rule that all strings be an instance of 'java/lang/String';
..
note that my low-level assembler (x86 and x86-64) uses a variation of
NASM-style syntax (it mainly differs in that it lacks macros and similar,
but does support lumping multiple instructions onto the same line).
note that my primary target OS is Windows rather than Linux (hence, I don't
use dlsym and friends, but implement my own dynamic linking). however, on
Linux libdl is used when loading shared objects.
I don't remember for certain, but I don't think ELF support is complete in
my case (mostly I use COFF).
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
