gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

C/C++ > Can C++/C# be used to make ds apps?

#101206 - tarkster2 - Sun Sep 03, 2006 9:26 pm

Im just learned about this stuff yesterday so im a noob. if i have devkitpro and select C++/C# in programmers notepad could that program be used on a ds (with movieplayer and passcard 3)

#101210 - tepples - Sun Sep 03, 2006 9:33 pm

Yes, you can use C++ in your ARM9 program. No, you currently cannot use managed code such as Java or C#.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#101542 - sgeos - Wed Sep 06, 2006 10:36 am

I'm assuming that ahead-of-time Java compilers and whatnot don't exist for the GBA.

-Brendan

#101580 - sajiimori - Wed Sep 06, 2006 6:26 pm

GCC can compile Java ahead of time, but you need a runtime environment.

#101649 - sgeos - Thu Sep 07, 2006 12:17 am

sajiimori wrote:
GCC can compile Java ahead of time, but you need a runtime environment.

Which I'm assuming:
A) Has not been created yet, and
B) Is not a straight port.

-Brendan

#101653 - gmiller - Thu Sep 07, 2006 12:59 am

On linux java compiles to object code not to byte code and then links with a library (or it did last time I messed with it). Which means it could be built for some environments but the libraries are HUGE so the code might not fit too well. I will pull out a small java app and see what it does with "gcc -type java".

#101657 - gmiller - Thu Sep 07, 2006 1:58 am

The "gcj" compiler (front end to gcc) or gcc -x java will product assembly code on linux which you could use on an embedded machine. The problem with these types of problems is the libraries. I t would take a long time to trim down the library code to allow this to be ported to a machine without a java virtual machine. Now some ARM9 processors have the java byte code as part fo their native instruction set but the ARM9 in the DS does not (I think). What you need to understand is this is not a trivial task, but neither was trimming the C runtime library or the C++ library. It might be possible but the language without most of the System:: and I/O code would be just like doing it in C or C++.

#101660 - sajiimori - Thu Sep 07, 2006 2:25 am

Garbage collection alone makes Java pretty different to work with.

#101680 - sgeos - Thu Sep 07, 2006 12:17 pm

How would one go about touching IO registers from java?

As far as garbage collection goes... I might force it every
frame just to be predictable.

-Brendan

#101687 - tepples - Thu Sep 07, 2006 2:17 pm

sgeos wrote:
How would one go about touching IO registers from java?

Your program written in the Java language would call runtime libraries written in the Java language, which would call native back-ends through JNI.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#101700 - gmiller - Thu Sep 07, 2006 3:14 pm

With the gcc route you could just call C or C++ code to do the register touching and reading. Since it is just code (the temp file are in assembly) you code generate the code and then "customize" the generated code to enable your libraries. On linux there is no java virtual machine using this method of course this was just the gcc approach.

#101707 - sgeos - Thu Sep 07, 2006 3:42 pm

tepples wrote:
sgeos wrote:
How would one go about touching IO registers from java?

Your program written in the Java language would call runtime libraries written in the Java language, which would call native back-ends through JNI.

In other words, using currently non-existant gba/ds-specific libraries?

gmiller wrote:
On linux there is no java virtual machine using this method of course this was just the gcc approach.

How is this to be parsed?

On linux, there is no java virtual machine using this method.
Of course this was just the gcc approach.

On linux, there is no java virtual machine.
Using this method, of course, this was just the gcc approach.

-Brendan

#101709 - gmiller - Thu Sep 07, 2006 4:09 pm

On my Linux box ....

Code:

gcc -S  MyFirst.java
cat MyFirst.s
        .file   "MyFirst.java"
        .text
        .align 2
.globl _ZN7MyFirst4mainEP6JArrayIPN4java4lang6StringEE
        .type   _ZN7MyFirst4mainEP6JArrayIPN4java4lang6StringEE, @function
_ZN7MyFirst4mainEP6JArrayIPN4java4lang6StringEE:
.LFB2:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        subl    $24, %esp
.LCFI2:
        movl    $_ZN7MyFirst6class$E, (%esp)
        call    _Jv_InitClass
        movl    $6, -4(%ebp)
        movl    $14, -8(%ebp)
        movl    -4(%ebp), %eax
        addl    -8(%ebp), %eax
        movl    %eax, -12(%ebp)
        leave
        ret
.LFE2:
        .size   _ZN7MyFirst4mainEP6JArrayIPN4java4lang6StringEE, .-_ZN7MyFirst4mainEP6JArrayIPN4java4lang6StringEE
.globl __gcj_personality_v0
        .align 2
.globl _ZN7MyFirstC1Ev
        .type   _ZN7MyFirstC1Ev, @function
_ZN7MyFirstC1Ev:
.LFB3:
        pushl   %ebp
.LCFI3:
        movl    %esp, %ebp
.LCFI4:
        subl    $8, %esp
.LCFI5:
        movl    8(%ebp), %eax
        movl    %eax, (%esp)
        call    _ZN4java4lang6ObjectC1Ev
        leave
        ret
.LFE3:
        .size   _ZN7MyFirstC1Ev, .-_ZN7MyFirstC1Ev
        .set    .L_ZN7MyFirst4mainEP6JArrayIPN4java4lang6StringEE0,_ZN7MyFirst4mainEP6JArrayIPN4java4lang6StringEE
        .section        .rodata
        .align 2
        .type   _Utf1, @object
        .size   _Utf1, 4
_Utf1:
        .value  1465
        .value  4
        .ascii  "main"
        .zero   1
        .align 2
        .type   _Utf2, @object
        .size   _Utf2, 4
_Utf2:
        .value  59434
        .value  22
        .ascii  "([Ljava.lang.String;)V"
        .zero   1
        .set    .L_ZN7MyFirstC1Ev1,_ZN7MyFirstC1Ev
        .align 2
        .type   _Utf3, @object
        .size   _Utf3, 4
_Utf3:
        .value  626
        .value  6
        .ascii  "<init>"
        .zero   1
        .align 2
        .type   _Utf4, @object
        .size   _Utf4, 4
_Utf4:
        .value  39797
        .value  3
        .ascii  "()V"
        .zero   1
        .data
        .align 32
        .type   _MT_MyFirst, @object
        .size   _MT_MyFirst, 40
_MT_MyFirst:
        .long   _Utf1
        .long   _Utf2
        .value  16393
        .value  -1
        .long   .L_ZN7MyFirst4mainEP6JArrayIPN4java4lang6StringEE0
        .long   0
        .long   _Utf3
        .long   _Utf4
        .value  16385
        .value  -1
        .long   .L_ZN7MyFirstC1Ev1
        .long   0
.globl _ZTVN7MyFirstE
        .align 32
        .type   _ZTVN7MyFirstE, @object
        .size   _ZTVN7MyFirstE, 40
_ZTVN7MyFirstE:
        .long   0
        .long   0
        .long   _ZN7MyFirst6class$E
        .long   0
        .long   _ZN4java4lang6Object8finalizeEv
        .long   _ZN4java4lang6Object8hashCodeEv
        .long   _ZN4java4lang6Object6equalsEPS1_
        .long   _ZN4java4lang6Object8toStringEv
        .long   _ZN4java4lang6Object5cloneEv
        .long   _ZN4java4lang6Object22throwNoSuchMethodErrorEv
        .align 4
        .type   _catch_classes_MyFirst, @object
        .size   _catch_classes_MyFirst, 24
_catch_classes_MyFirst:
        .zero   24
        .section        .rodata
        .align 2
        .type   _Utf5, @object
        .size   _Utf5, 4
_Utf5:
        .value  6212
        .value  7
        .ascii  "MyFirst"
        .zero   1
.globl _ZN7MyFirst6class$E
        .data
        .align 32
        .type   _ZN7MyFirst6class$E, @object
        .size   _ZN7MyFirst6class$E, 144
_ZN7MyFirst6class$E:
        .long   _ZTVN4java4lang5ClassE+8
        .long   0
        .long   401000
        .long   _Utf5
        .value  1
        .zero   2
        .long   _ZN4java4lang6Object6class$E
        .long   0
        .long   0
        .long   0
        .long   _MT_MyFirst
        .value  2
        .value  6
        .long   0
        .long   8
        .value  0
        .value  0
        .long   _ZTVN7MyFirstE+8
        .long   0
        .long   0
        .long   0
        .long   0
        .long   0
        .long   0
        .long   _catch_classes_MyFirst
        .long   0
        .long   0
        .value  0
        .byte   1
        .zero   1
        .long   0
        .value  0
        .zero   2
        .long   0
        .long   0
        .long   0
        .long   0
        .long   0
        .long   0
        .long   0
        .long   0
        .long   0
        .section        .jcr,"aw",@progbits
        .align 4
        .long   _ZN7MyFirst6class$E
        .section        .eh_frame,"a",@progbits
.Lframe1:
        .long   .LECIE1-.LSCIE1
.LSCIE1:
        .long   0x0
        .byte   0x1
        .string "zP"
        .uleb128 0x1
        .sleb128 -4
        .byte   0x8
        .uleb128 0x5
        .byte   0x0
        .long   __gcj_personality_v0
        .byte   0xc
        .uleb128 0x4
        .uleb128 0x4
        .byte   0x88
        .uleb128 0x1
        .align 4
.LECIE1:
.LSFDE1:
        .long   .LEFDE1-.LASFDE1
.LASFDE1:
        .long   .LASFDE1-.Lframe1
        .long   .LFB2
        .long   .LFE2-.LFB2
        .uleb128 0x0
        .byte   0x4
        .long   .LCFI0-.LFB2
        .byte   0xe
        .uleb128 0x8
        .byte   0x85
        .uleb128 0x2
        .byte   0x4
        .long   .LCFI1-.LCFI0
        .byte   0xd
        .uleb128 0x5
        .align 4
.LEFDE1:
.LSFDE3:
        .long   .LEFDE3-.LASFDE3
.LASFDE3:
        .long   .LASFDE3-.Lframe1
        .long   .LFB3
        .long   .LFE3-.LFB3
        .uleb128 0x0
        .byte   0x4
        .long   .LCFI3-.LFB3
        .byte   0xe
        .uleb128 0x8
        .byte   0x85
        .uleb128 0x2
        .byte   0x4
        .long   .LCFI4-.LCFI3
        .byte   0xd
        .uleb128 0x5
        .align 4
.LEFDE3:
        .ident  "GCC: (GNU) 4.1.1 20060525 (Red Hat 4.1.1-1)"
        .section        .note.GNU-stack,"",@progbits

#101712 - gmiller - Thu Sep 07, 2006 4:15 pm

Of course all of this assumes the cross compiler you are using will generate code for the target machine. My current compile does not allow an ARM target on this machine.

#101781 - sgeos - Fri Sep 08, 2006 12:26 am

gmiller wrote:
Of course all of this assumes the cross compiler you are using will generate code for the target machine. My current compile does not allow an ARM target on this machine.

Sounds interesting to try to get Java running on an ARM. Then, in theory at least, cell phone games and applets could be ported "easily". (Where easily probably means a fair bit of hassle =)

-Brendan

#101786 - keldon - Fri Sep 08, 2006 12:50 am

But a lot of these phones have fairly powerful processors; even in comparison with the GBA. The sony ericson p800 (for example) is a 156Mhz Arm 9 processor with 12MB of RAM.