On 02.09.2011 18:07, Jonas Maebe wrote:
On 02 Sep 2011, at 16:20, Sven Barth wrote:
I just tried to reproduce that at work on Windows, but I encountered an error when
compiling the RTL. The problematic part are the dependencies of "uuchar".
The problem is that Win32 does not define the SYSTEM
On 02 Sep 2011, at 16:20, Sven Barth wrote:
> I just tried to reproduce that at work on Windows, but I encountered an error
> when compiling the RTL. The problematic part are the dependencies of "uuchar".
> The problem is that Win32 does not define the SYSTEMUNIT variable (and
> SYSTEMPPU is de
Am 02.09.2011 16:20, schrieb Sven Barth:
Am 02.09.2011 12:30, schrieb Sven Barth:
When using ppcjvm I compile using "-n" and when I compile the Java RTL
using make I also need to pass "-XP " in OPT.
Strange:
~/fpcjvm/rtl/java$ make FPC=ppcjvm2 OPT="-n -O2 -al" clean all
/bin/rm -f ../../rtl/u
Am 02.09.2011 12:30, schrieb Sven Barth:
When using ppcjvm I compile using "-n" and when I compile the Java RTL
using make I also need to pass "-XP " in OPT.
Strange:
~/fpcjvm/rtl/java$ make FPC=ppcjvm2 OPT="-n -O2 -al" clean all
/bin/rm -f ../../rtl/units/jvm-java/system.ppu
../../rtl/units/j
Am 02.09.2011 11:55, schrieb Jonas Maebe:
That would indeed cause the makefile to create a directory called
"ppcjvm". And the compiler binary is always called "pp" and then renamed
(moved) to "ppc", so that would indeed put the "pp" binary in that
ppcjvm directory rather than renaming it to "ppcj
On 02 Sep 2011, at 11:23, Sven Barth wrote:
Am 02.09.2011 11:04, schrieb Jonas Maebe:
I don't see that, all object and unit files are stored under
compiler/jvm/units/ here. I also don't understand
how
that can happen, because the name of the generated compiler binary is
also "ppcjvm" and y
Am 02.09.2011 11:04, schrieb Jonas Maebe:
On 01 Sep 2011, at 21:40, Sven Barth wrote:
Two more questions regarding compilation:
1. is it normal that the compiler is compiled to compiler/ppcjvm/
instead of compiler/jvm/ when using "make PPC_TARGET=jvm all"?
I don't see that, all object and un
On 01 Sep 2011, at 21:40, Sven Barth wrote:
Two more questions regarding compilation:
1. is it normal that the compiler is compiled to compiler/ppcjvm/
instead of compiler/jvm/ when using "make PPC_TARGET=jvm all"?
I don't see that, all object and unit files are stored under compiler/
jvm/
On 01.09.2011 20:27, Jonas Maebe wrote:
On 01 Sep 2011, at 00:02, Jonas Maebe wrote:
On 31 Aug 2011, at 23:13, Sven Barth wrote:
On 31.08.2011 22:59, Jonas Maebe wrote:
I'll do a testsuite run to see whether I introduced any bugs in the string
handling, but to test the Android stuff you c
On 01 Sep 2011, at 00:02, Jonas Maebe wrote:
> On 31 Aug 2011, at 23:13, Sven Barth wrote:
>
>> On 31.08.2011 22:59, Jonas Maebe wrote:
>>>
>>> I'll do a testsuite run to see whether I introduced any bugs in the string
>>> handling, but to test the Android stuff you can also use a compiler
>>
Am 01.09.2011 06:54, schrieb Max Vlasov:
On Thu, Sep 1, 2011 at 1:13 AM, Sven Barth wrote:
I'll try to improve the unit names of the android unit and its dependencies
a bit and then it might become the first package for FPC-JVM ;)
Sven, thanks for your tests. Adding hwfpo (Hello World From
Am 01.09.2011 00:02, schrieb Jonas Maebe:
I'll try to improve the unit names of the android unit and its dependencies a
bit and then it might become the first package for FPC-JVM ;)
Great! Note that using the jdk15 unit in the android unit is not a good idea,
since it probably also exports JD
On Thu, Sep 1, 2011 at 1:13 AM, Sven Barth wrote:
>
> I'll try to improve the unit names of the android unit and its dependencies
> a bit and then it might become the first package for FPC-JVM ;)
>
Sven, thanks for your tests. Adding hwfpo (Hello World From Pascal
Only) and simple step-by-step in
On 31 Aug 2011, at 23:13, Sven Barth wrote:
> On 31.08.2011 22:59, Jonas Maebe wrote:
>>
>> I'll do a testsuite run to see whether I introduced any bugs in the string
>> handling, but to test the Android stuff you can also use a compiler compiled
>> against another RTL for now.
Testsuite didn
On 31.08.2011 22:59, Jonas Maebe wrote:
On 31 Aug 2011, at 22:44, Sven Barth wrote:
No, the end is missing as well.
If I change the unit output path to something like "output" (something short) though,
then the "4.j" is printed. Besides that the content of the ppas file is completely
differe
On 31 Aug 2011, at 22:44, Sven Barth wrote:
> No, the end is missing as well.
> If I change the unit output path to something like "output" (something short)
> though, then the "4.j" is printed. Besides that the content of the ppas file
> is completely different in both cases... it nearly looks
On 31.08.2011 22:35, Jonas Maebe wrote:
On 31 Aug 2011, at 22:22, Sven Barth wrote:
On 31.08.2011 22:14, Jonas Maebe wrote:
Forgot to commit a file, sorry.
Nobody is perfect :)
But there seems to be another problem. When assembling the system unit I get
the following error:
=== output b
On 31 Aug 2011, at 22:22, Sven Barth wrote:
> On 31.08.2011 22:14, Jonas Maebe wrote:
>>
>> Forgot to commit a file, sorry.
>
> Nobody is perfect :)
>
> But there seems to be another problem. When assembling the system unit I get
> the following error:
>
> === output begin ===
>
> Assemblin
On 31.08.2011 22:14, Jonas Maebe wrote:
On 31 Aug 2011, at 21:55, Sven Barth wrote:
On 31 Aug 2011, at 21:36, Sven Barth wrote:
On 31.08.2011 21:21, Jonas Maebe wrote:
Fixed in svn, there was a bug in the abstract method accounting.
When compiling the RTL (make RELEASE=1 clean all) for i
On 31 Aug 2011, at 21:55, Sven Barth wrote:
>>
>> On 31 Aug 2011, at 21:36, Sven Barth wrote:
>>
>>> On 31.08.2011 21:21, Jonas Maebe wrote:
Fixed in svn, there was a bug in the abstract method accounting.
>>>
>>> When compiling the RTL (make RELEASE=1 clean all) for i386 I get the
>>> f
On 31.08.2011 21:49, Jonas Maebe wrote:
On 31 Aug 2011, at 21:36, Sven Barth wrote:
On 31.08.2011 21:21, Jonas Maebe wrote:
Fixed in svn, there was a bug in the abstract method accounting.
When compiling the RTL (make RELEASE=1 clean all) for i386 I get the following
error:
Fixed.
Than
On 31 Aug 2011, at 21:36, Sven Barth wrote:
> On 31.08.2011 21:21, Jonas Maebe wrote:
>> Fixed in svn, there was a bug in the abstract method accounting.
>
> When compiling the RTL (make RELEASE=1 clean all) for i386 I get the
> following error:
Fixed.
Jonas__
On 31.08.2011 21:21, Jonas Maebe wrote:
Fixed in svn, there was a bug in the abstract method accounting.
When compiling the RTL (make RELEASE=1 clean all) for i386 I get the
following error:
=== output begin ===
make[1]: Entering directory `/mnt/data/subversion/fpc-jvm/rtl/linux'
/mnt/data/
On 30 Aug 2011, at 22:59, Jonas Maebe wrote:
> On 30 Aug 2011, at 22:37, Sven Barth wrote:
>
>> On 30.08.2011 22:32, Jonas Maebe wrote:
>>>
>>> On 30 Aug 2011, at 22:26, Sven Barth wrote:
>>>
I've also found the class that defines the abstract methods. It's four
classes above androi
On 30 Aug 2011, at 10:34, Jonas Maebe wrote:
> Also, at http://www.netmite.com/android/mydroid/dalvik/docs/verifier.html I
> noticed one forbidden thing that FPC currently does: "The Dalvik verifier is
> more restrictive than other VMs in one area: type safety on sub-32-bit
> integer widths. T
On 30 Aug 2011, at 22:37, Sven Barth wrote:
> On 30.08.2011 22:32, Jonas Maebe wrote:
>>
>> On 30 Aug 2011, at 22:26, Sven Barth wrote:
>>
>>> I've also found the class that defines the abstract methods. It's four
>>> classes above android.app.Activity in the inheritance tree
>>> (android.com
On 30.08.2011 22:32, Jonas Maebe wrote:
On 30 Aug 2011, at 22:26, Sven Barth wrote:
I've also found the class that defines the abstract methods. It's four classes
above android.app.Activity in the inheritance tree (android.common.Context). I
yet need to check whether all methods are overridd
On 30 Aug 2011, at 22:26, Sven Barth wrote:
> I've also found the class that defines the abstract methods. It's four
> classes above android.app.Activity in the inheritance tree
> (android.common.Context). I yet need to check whether all methods are
> overridden correctly by the subclasses (an
On 30.08.2011 22:11, Jonas Maebe wrote:
On 30 Aug 2011, at 21:59, Sven Barth wrote:
I/ActivityManager( 62): Start proc com.example.helloandroid for activity
com.example.helloandroid/.HelloAndroid: pid=375 uid=10034 gids={1015}
W/dalvikvm( 375): VFY: new-instance on interface or abstract cl
On 30 Aug 2011, at 21:59, Sven Barth wrote:
> I/ActivityManager( 62): Start proc com.example.helloandroid for activity
> com.example.helloandroid/.HelloAndroid: pid=375 uid=10034 gids={1015}
> W/dalvikvm( 375): VFY: new-instance on interface or abstract class
> Lorg/freepascal/android/TTestA
On 30.08.2011 10:34, Jonas Maebe wrote:
On 30 Aug 2011, at 10:16, Sven Barth wrote:
Am 30.08.2011 10:10, schrieb Jonas Maebe:
Maybe you have to explicitly add "-g-" to the OPT string when compiling
the RTL (and your programs), since the default config file shipped with
the snapshot enables d
On 08/30/2011 12:19 PM, Hans-Peter Diettrich wrote:
The FPC internal representation (code tree nodes) has no notion of
registers. This is (also) due to the fact, that a register allocator
can work reasonably only after the entire code of a subroutine is
known. When the target is a registerles
On 08/30/2011 10:25 AM, Jonas Maebe wrote:
He means that converting a stack based program representation (whether
it's compiler-internal or Java byte code is irrelevant) of a program
to a flat register file based program representation has been a solved
problem since a long time ago.
Of cours
Michael Schnell schrieb:
On 08/29/2011 05:58 PM, Hans-Peter Diettrich wrote:
That is why I am astonished that converting Java-Bytecode to Dalvik
code should be an easy task.
A stackbased internal or intermediate representation is the most
general one, from which a compiler can decide whic
On 30 Aug 2011, at 10:16, Sven Barth wrote:
Am 30.08.2011 10:10, schrieb Jonas Maebe:
Maybe you have to explicitly add "-g-" to the OPT string when
compiling
the RTL (and your programs), since the default config file shipped
with
the snapshot enables debug information.
I have done that
On 30 Aug 2011, at 09:59, Michael Schnell wrote:
On 08/29/2011 05:58 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
That is why I am astonished that converting Java-Bytecode to
Dalvik code should be an easy task.
A stackbased internal or intermediate representation is the most
Am 30.08.2011 10:10, schrieb Jonas Maebe:
On 30 Aug 2011, at 09:16, Sven Barth wrote:
Am 29.08.2011 23:06, schrieb Jonas Maebe:
Ok... creating an Android class (in this case
android.widget.TextView) from within my FPC class works, but the
full FPC variation still doesn't want to start...
On 30 Aug 2011, at 09:16, Sven Barth wrote:
Am 29.08.2011 23:06, schrieb Jonas Maebe:
Ok... creating an Android class (in this case
android.widget.TextView) from within my FPC class works, but the
full FPC variation still doesn't want to start...
What kind of error do you get?
The sam
Am 30.08.2011 09:59, schrieb Michael Schnell:
On 08/29/2011 05:58 PM, Hans-Peter Diettrich wrote:
That is why I am astonished that converting Java-Bytecode to Dalvik
code should be an easy task.
A stackbased internal or intermediate representation is the most
general one, from which a compi
On 08/29/2011 05:58 PM, Hans-Peter Diettrich wrote:
That is why I am astonished that converting Java-Bytecode to Dalvik
code should be an easy task.
A stackbased internal or intermediate representation is the most
general one, from which a compiler can decide which registers to use
for ex
Am 29.08.2011 23:06, schrieb Jonas Maebe:
On 29 Aug 2011, at 22:42, Sven Barth wrote:
On 29.08.2011 22:22, Sven Barth wrote:
Without debug information it works. Next step: creating one of the
Android classes from within FPC compiled code. :)
Ok... creating an Android class (in this case and
On 29 Aug 2011, at 22:42, Sven Barth wrote:
> On 29.08.2011 22:22, Sven Barth wrote:
>> Without debug information it works. Next step: creating one of the
>> Android classes from within FPC compiled code. :)
>
> Ok... creating an Android class (in this case android.widget.TextView) from
> withi
On 29.08.2011 22:22, Sven Barth wrote:
Without debug information it works. Next step: creating one of the
Android classes from within FPC compiled code. :)
Ok... creating an Android class (in this case android.widget.TextView)
from within my FPC class works, but the full FPC variation still do
On 29.08.2011 00:56, Jonas Maebe wrote:
On 28 Aug 2011, at 23:01, Jonas Maebe wrote:
The org.freepascal.rtl.system class verifies fine here, and the FpcBitSet stuff
also works fine. Maybe the methods of java.util.BitSet (on which
org.freepascal.rtl.FpcBitSet is based) have different signatur
Michael Schnell schrieb:
The JVM bytecode is a pure stackbased one while the Dalvik one uses
registers.
Yep.
That is why I am astonished that converting Java-Bytecode to Dalvik code
should be an easy task.
A stackbased internal or intermediate representation is the most general
one, from
On 08/29/2011 01:09 PM, Jonas Maebe wrote:
JIT compilers for Java byte code have existed for over a decade now.
They also map the Java stack machine to register-based architectures.
Of course they do.
Seemingly the Dalvik "to-dex-converter" is supposed to do some static
pre-processor work on
On 29 Aug 2011, at 11:42, Michael Schnell wrote:
On 08/29/2011 11:08 AM, Sven Barth wrote:
But there is a significant difference between the JVM bytecode and
the Dalvik one and perhaps Michael thought of that when writing his
question:
The JVM bytecode is a pure stackbased one while the D
On 08/29/2011 11:43 AM, Felipe Monteiro de Carvalho wrote:
Sven is correct. I didn't know this until now, but all Android
applications are first compiled using javac and then dex converts the
bytecode. Usually you don't have to care about this, because the Java
part is provided in source code and
On Mon, Aug 29, 2011 at 11:42 AM, Michael Schnell wrote:
> That is why I am astonished that converting Java-Bytecode to Dalvik code
> should be an easy task.
Sven is correct. I didn't know this until now, but all Android
applications are first compiled using javac and then dex converts the
byteco
On 08/29/2011 11:08 AM, Sven Barth wrote:
But there is a significant difference between the JVM bytecode and the
Dalvik one and perhaps Michael thought of that when writing his question:
The JVM bytecode is a pure stackbased one while the Dalvik one uses
registers.
Yep.
That is why I am as
Of course I did understand this. I suppose the virtual "Java Processor"
in fact uses 32 or 64 bit data. But the instruction coding might (or
might not) be quite different when doing a byte-encoded instruction set
(like a X86 processor) or using another instruction width (like ARM).
-Michael
__
Am 29.08.2011 10:58, schrieb Jonas Maebe:
On 29 Aug 2011, at 09:58, Michael Schnell wrote:
How did you manage to move from the 8 bit SUN Java bytecode to the 16
bit Android /Dalvik code ?
You are thinking of 8 and 16 bit in the wrong way. Those are simply
details of the respective byte code
On 29 Aug 2011, at 09:58, Michael Schnell wrote:
How did you manage to move from the 8 bit SUN Java bytecode to the
16 bit Android /Dalvik code ?
You are thinking of 8 and 16 bit in the wrong way. Those are simply
details of the respective byte code instruction formats. For example,
it's
Am 29.08.2011 09:58, schrieb Michael Schnell:
On 08/27/2011 05:43 PM, Sven Barth wrote:
So it is definitely possible to run FPC JVM code on Dalvik, it's just
not working perfectly currently...
Sorry if this is a stupid question from still-JAVA-ignorant:
How did you manage to move from the 8
On 08/27/2011 05:43 PM, Sven Barth wrote:
So it is definitely possible to run FPC JVM code on Dalvik, it's just
not working perfectly currently...
Sorry if this is a stupid question from still-JAVA-ignorant:
How did you manage to move from the 8 bit SUN Java bytecode to the 16
bit Android
On 28 Aug 2011, at 23:01, Jonas Maebe wrote:
> The org.freepascal.rtl.system class verifies fine here, and the FpcBitSet
> stuff also works fine. Maybe the methods of java.util.BitSet (on which
> org.freepascal.rtl.FpcBitSet is based) have different signatures in the
> Android version compared
On 28 Aug 2011, at 22:16, Sven Barth wrote:
> On 28.08.2011 21:38, Jonas Maebe wrote:
>>
>> On 27 Aug 2011, at 17:43, Sven Barth wrote:
>>
>>> And here the log entry when building the Java based example with a class
>>> that derives from TObject:
>>>
>>> === begin build log ===
>>>
>>> [
On 28.08.2011 21:38, Jonas Maebe wrote:
On 27 Aug 2011, at 17:43, Sven Barth wrote:
When running the full FPC application (or "activity"):
=== begin run log ===
I/ActivityManager( 59): Start proc org.freepascal.helloworld for activity
org.freepascal.helloworld/.THelloWorld: pid=601 uid=10
On 27 Aug 2011, at 17:43, Sven Barth wrote:
> When running the full FPC application (or "activity"):
>
> === begin run log ===
>
> I/ActivityManager( 59): Start proc org.freepascal.helloworld for activity
> org.freepascal.helloworld/.THelloWorld: pid=601 uid=10035 gids={1015}
> D/dalvikvm(
Hello together!
As you might have noticed I'm currently trying to get Pascal code
working on Android using the new JVM backend.
So far I've converted the Android API in the android namespace to Pascal
and managed to compile, convert (to DEX) and package a full Pascal
HelloWorld application,
60 matches
Mail list logo
