Java to C++ conversion

Robbert Haarman <comp.lang.misc@inglorion.net> writes:
>>actually, one of my main complaints about Java, and most other non-C/C++
>>languages, is the absence of pointers.
>That's somewhat misleading. In a sense, everything Java calls a
>"reference to an object" is a pointer.

This is not only so "in a sense".
It is written in the Java Language Specification:

»(...) reference values (...) are pointers«
JLS3, 4.3.1.
http://java.sun.com/docs/books/jls/t...ues.html#4.3.1

"Robbert Haarman" <comp.lang.misc@inglorion.net> wrote in message
news:20061018001312.GU26569@morgenes.shire.sytes.n et...
> On Wed, Oct 18, 2006 at 07:39:17AM +1000, cr88192 wrote:
>>
>> actually, one of my main complaints about Java, and most other non-C/C++
>> languages, is the absence of pointers.
>
> That's somewhat misleading. In a sense, everything Java calls a
> "reference to an object" is a pointer. What Java doesn't have is pointer
> arithmetic and pointers that don't refer to the start of objects.
>

actually, what I meant was what it does lack, in particular, the pointer
arithmetic, ability to treat memory however I want, ...

there are many cases where this kind of thing is especially helpful.


>> technically, pointers aren't good from the lang design perspective, but
>> are
>> useful wrt implementing some things (especially custom memory management
>> and
>> similar).
>
> Several features besides raw pointers would allow you to implement these
> things. For example, in dynamically typed languages with arrays, you
> could use array indices instead of pointers. The same would work in
> statically typed languages with a common supertype and a way to downcast
> to actual types.
>

that is what I had meant later on, but I will argue that this is potentially
less efficient, since now there is another layer of stuff going on between
the implementation and the raw hardware.


>> so, for example, in the Java VM, one can sit around and put it in the
>> hands
>> of the VM whether or not the GC is good, or whether or not representing
>> conses as classes will waste a whole not, or not a lot of memory...
>>
>> likewise, there is no particularly efficient way to implement things like
>> fixnums.
>> as a result, a lang VM running on top of Java, for example, is almost
>> doomed
>> to be crappy.
>
> Yes. It's lack of flexibility is one of the main drawbacks of the JVM.
> Of course, this only affects people who want to target the JVM with
> languages other than Java, but, in a sense, this also includes the Java
> folks: certain changes to the language would require changes to the JVM
> to be implementable efficiently, whereas no such changes to the VM would
> have been necessary, had it been designed more generically from the
> start.
>

yes, very true.


>> then again, even then, one still has a little hope. it is possible to
>> still
>> use tagged references, and a large object array (with an additional array
>> for storing conses), but then one has to manage their own (second level)
>> MM/GC, which is hardly that great either.
>
> Well, you can't have it both ways: you either use the provided MM and
> accept its limitations, or you write your own MM and accept the effort.
>

yes.

the problem is such a second-level MM/GC is likely to be slower, and have
more arbitrary limitations, than if the thing had just been written in C...


>> sadly, there is no really 'generic' way to deal with dynamic languages,
>> meaning the notion of a true "general purpose dynamic vm" is a little
>> pushing it.
>
> I don't see why that should be the case. As long as you don't build
> inflexible constructs into your VM, you should be fine. In particular,
> if your VM resembles a real machine, I think it would be unfair to say
> it wasn't generic.
>

yes.

my vm "sort of" resembles a real machine, if in fact that real machine
happens to be a dynamically typed stack machine (with jumps and similar).
note though that there are many opcodes which (presently) bypass type
checking, and it may be that a JIT compiler backend would, in fact, drop the
tagged reference structure altogether in some cases.


so, the big question may be how flexible is the VM to handle different kinds
of languages.
it doesn't help me that I presently lack much of a developed theory as to
implement a "general" dynamic vm, and even with some other languages I am
fammiliar with (Scheme, ...), there are things that could become an issue (a
particular example is the scheme notion of re-entrant continuations).

for example, scheme's continuations would bring up a few possibilities:
save the entire frame (inefficient, in terms of having to allocate a new
context, or making a copy of the contents of the current context);
generate code in some form of continuation passing style (inefficient, as my
vm is designed for a C-style control flow, lacks inter-function jumps, and
would likely have additional overhead for small fine-grained functions,
....).

both would be possible:
the former is simpler, and would "do the job";
a general solution to the problem of efficient CPS is a little harder, but
could be workable.

my vm does support tail-call optimization, and has some specialized opcodes
for dealing with tail-calls, so that is a start at least. this would work if
one wants to generate a whole lot of tiny blocks.

more likely, it would be useful to generate the code as a larger block held
together by local jumps, but this gets in the way of things like the
possibility of needing to jump to a small function from outside the block,
could somewhat complicate code generation, ...

then again, all this could be left as an upper-compiler issue, rather than
the responsibility of the lower-compiler/codegenerator (and, as such, a
'simple' CPS compiler could generate very inefficient bytecode).


or something...

more so, many languages may have other mismatches, or things that may be
difficult or impossible to implement that may have not been effectively
considered (most looming is the possibility of fundamental differences wrt
the typesystems).


none the less though, it is an interesting prospect, and I may start to look
into this as a possibility.

much of the current compiler is more likely to be retasked as a "lower
compiler", which would presumably be fed an already well-cooked form of the
language ASTs. the job of the codegenerator would then be to process these
and form sane bytecode, and the JIT compiler would take the bytecode and
produce sane machine code.

or such...


> Regards,
>
> Bob
>
> ---
> Computer science is no more about computers than astronomy is about
> telescopes.
>
> -- Edsger Dijkstra
>

"Robbert Haarman" <comp.lang.misc@inglorion.net> wrote in message
news:20061018001312.GU26569@morgenes.shire.sytes.n et...
> On Wed, Oct 18, 2006 at 07:39:17AM +1000, cr88192 wrote:
>>
>> actually, one of my main complaints about Java, and most other non-C/C++
>> languages, is the absence of pointers.
>
> That's somewhat misleading. In a sense, everything Java calls a
> "reference to an object" is a pointer. What Java doesn't have is pointer
> arithmetic and pointers that don't refer to the start of objects.
>

actually, what I meant was what it does lack, in particular, the pointer
arithmetic, ability to treat memory however I want, ...

there are many cases where this kind of thing is especially helpful.


>> technically, pointers aren't good from the lang design perspective, but
>> are
>> useful wrt implementing some things (especially custom memory management
>> and
>> similar).
>
> Several features besides raw pointers would allow you to implement these
> things. For example, in dynamically typed languages with arrays, you
> could use array indices instead of pointers. The same would work in
> statically typed languages with a common supertype and a way to downcast
> to actual types.
>

that is what I had meant later on, but I will argue that this is potentially
less efficient, since now there is another layer of stuff going on between
the implementation and the raw hardware.


>> so, for example, in the Java VM, one can sit around and put it in the
>> hands
>> of the VM whether or not the GC is good, or whether or not representing
>> conses as classes will waste a whole not, or not a lot of memory...
>>
>> likewise, there is no particularly efficient way to implement things like
>> fixnums.
>> as a result, a lang VM running on top of Java, for example, is almost
>> doomed
>> to be crappy.
>
> Yes. It's lack of flexibility is one of the main drawbacks of the JVM.
> Of course, this only affects people who want to target the JVM with
> languages other than Java, but, in a sense, this also includes the Java
> folks: certain changes to the language would require changes to the JVM
> to be implementable efficiently, whereas no such changes to the VM would
> have been necessary, had it been designed more generically from the
> start.
>

yes, very true.


>> then again, even then, one still has a little hope. it is possible to
>> still
>> use tagged references, and a large object array (with an additional array
>> for storing conses), but then one has to manage their own (second level)
>> MM/GC, which is hardly that great either.
>
> Well, you can't have it both ways: you either use the provided MM and
> accept its limitations, or you write your own MM and accept the effort.
>

yes.

the problem is such a second-level MM/GC is likely to be slower, and have
more arbitrary limitations, than if the thing had just been written in C...


>> sadly, there is no really 'generic' way to deal with dynamic languages,
>> meaning the notion of a true "general purpose dynamic vm" is a little
>> pushing it.
>
> I don't see why that should be the case. As long as you don't build
> inflexible constructs into your VM, you should be fine. In particular,
> if your VM resembles a real machine, I think it would be unfair to say
> it wasn't generic.
>

yes.

my vm "sort of" resembles a real machine, if in fact that real machine
happens to be a dynamically typed stack machine (with jumps and similar).
note though that there are many opcodes which (presently) bypass type
checking, and it may be that a JIT compiler backend would, in fact, drop the
tagged reference structure altogether in some cases.


so, the big question may be how flexible is the VM to handle different kinds
of languages.
it doesn't help me that I presently lack much of a developed theory as to
implement a "general" dynamic vm, and even with some other languages I am
fammiliar with (Scheme, ...), there are things that could become an issue (a
particular example is the scheme notion of re-entrant continuations).

for example, scheme's continuations would bring up a few possibilities:
save the entire frame (inefficient, in terms of having to allocate a new
context, or making a copy of the contents of the current context);
generate code in some form of continuation passing style (inefficient, as my
vm is designed for a C-style control flow, lacks inter-function jumps, and
would likely have additional overhead for small fine-grained functions,
....).

both would be possible:
the former is simpler, and would "do the job";
a general solution to the problem of efficient CPS is a little harder, but
could be workable.

my vm does support tail-call optimization, and has some specialized opcodes
for dealing with tail-calls, so that is a start at least. this would work if
one wants to generate a whole lot of tiny blocks.

more likely, it would be useful to generate the code as a larger block held
together by local jumps, but this gets in the way of things like the
possibility of needing to jump to a small function from outside the block,
could somewhat complicate code generation, ...

then again, all this could be left as an upper-compiler issue, rather than
the responsibility of the lower-compiler/codegenerator (and, as such, a
'simple' CPS compiler could generate very inefficient bytecode).


or something...

more so, many languages may have other mismatches, or things that may be
difficult or impossible to implement that may have not been effectively
considered (most looming is the possibility of fundamental differences wrt
the typesystems).


none the less though, it is an interesting prospect, and I may start to look
into this as a possibility.

much of the current compiler is more likely to be retasked as a "lower
compiler", which would presumably be fed an already well-cooked form of the
language ASTs. the job of the codegenerator would then be to process these
and form sane bytecode, and the JIT compiler would take the bytecode and
produce sane machine code.

or such...


> Regards,
>
> Bob
>
> ---
> Computer science is no more about computers than astronomy is about
> telescopes.
>
> -- Edsger Dijkstra
>