[fpc-devel] DIFF for consideration
See attached.
Index: rtl/embedded/arm/lpc1768.pp
===
--- rtl/embedded/arm/lpc1768.pp (revision 0)
+++ rtl/embedded/arm/lpc1768.pp (revision 0)
@@ -0,0 +1,160 @@
+
+unit lpc1768;
+
+{$goto on}
+{$define lpc1768}
+
+interface
+
+var
+STCTRL : DWord absolute $E000E010;
+STRELOAD : DWord absolute $E000E014;
+STCURR : DWord absolute $E000E018;
+
+FIO1DIR2 : Byte absolute $2009C022;
+FIO1SET2 : Byte absolute $2009C03A;
+FIO1CLR2 : Byte absolute $2009C03E;
+
+SCS : DWord absolute $400FC1A0;
+CLKSRCSEL: DWord absolute $400FC10C;
+PLL0FEED : DWord absolute $400FC08C;
+PLL0CON : DWord absolute $400FC080;
+PLL0CFG : DWord absolute $400FC084;
+PLL0STAT : DWord absolute $400FC088;
+CCLKCFG : DWord absolute $400FC104;
+
+implementation
+
+var
+_data: record end; external name '_data';
+_edata: record end; external name '_edata';
+_etext: record end; external name '_etext';
+_bss_start: record end; external name '_bss_start';
+_bss_end: record end; external name '_bss_end';
+_stack_top: record end; external name '_stack_top';
+
+procedure PASCALMAIN; external name 'PASCALMAIN';
+
+procedure _FPC_haltproc; assembler; nostackframe; public name '_haltproc';
+asm
+.Lhalt:
+b .Lhalt
+end;
+
+procedure _FPC_start; assembler; nostackframe;
+label _start;
+asm
+.init
+.balign 16
+
+.long _stack_top// stack top address
+.long _start+1 // 1 Reset
+.long .LDefaultHandler+1// 2 NMI
+.long .LDefaultHandler+1// 3 HardFault
+.long .LDefaultHandler+1// 4 MemManage
+.long .LDefaultHandler+1// 5 BusFault
+.long .LDefaultHandler+1// 6 UsageFault
+.long .LDefaultHandler+1// 7 RESERVED
+.long .LDefaultHandler+1// 8 RESERVED
+.long .LDefaultHandler+1// 9 RESERVED
+.long .LDefaultHandler+1// 10 RESERVED
+.long .LDefaultHandler+1// 11 SVCall
+.long .LDefaultHandler+1// 12 Debug Monitor
+.long .LDefaultHandler+1// 13 RESERVED
+.long .LDefaultHandler+1// 14 PendSV
+.long .LDefaultHandler+1// 15 SysTick
+.long .LDefaultHandler+1// 16 External Interrupt(0)
+.long .LDefaultHandler+1// 17 External Interrupt(1)
+.long .LDefaultHandler+1// 18 External Interrupt(2)
+.long .LDefaultHandler+1// 19 ...
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+.long .LDefaultHandler+1
+
+.globl _start
+.text
+_start:
+
+// Copy initialized data to ram
+ldr r1,.L_etext
+ldr r2,.L_data
+ldr r3,.L_edata
+.Lcopyloop:
+cmp r2,r3
+ittt ls
+ldrls r0,[r1],#4
+strls r0,[r2],#4
+bls .Lcopyloop
+
+// clear onboard ram
+ldr r1,.L_bss_start
+ldr r2,.L_bss_end
+mov r0,#0
+.Lzeroloop:
+cmp r1,r2
+itt ls
+strls r0,[r1],#4
+bls .Lzeroloop
+
+b PASCALMAIN
+b _FPC_haltproc
+
+.L_bss_start:
+.long _bss_start
+.L_bss_end:
+.long _bss_end
+.L_etext:
+.long _etext
+.L_data:
+.long _data
+.L_edata:
+.long _edata
+.LDefaultHandlerAddr:
+.long .LDefaultHandler
+// default irq handler just returns
+.LDefaultHandler:
+mov pc,r14
+end;
+
+end.
+
+
Index: rtl/embedded/Makefile.fpc
===
--- rtl/embedded/Makefile.fpc (revision 18875)
+++ rtl/embedded/Makefile.fpc (working copy)
@@ -49,13 +49,15 @@
ifeq ($(ARCH),arm)
ifeq ($(SUBARCH),armv7m)
-CPU_UNITS=lm3fury lm3tempest stm32f103 # thumb2_bare
+CPU_UNITS=lm3fury lm3tempest stm32f103 lpc1768 # thumb2_bare
endif
-
ifeq ($(SUBARCH),armv4t)
CPU_UNITS=lpc21x4 at91sam7x256
endif
+ifeq ($(SUBARCH),armv4)
+CPU_UNITS=lpc21x4 at91sam7x256
endif
+endif
ifeq ($(ARCH),avr)
CPU_UNITS=atmega128
Index: rtl/embedded/Makefile
Re: [fpc-devel] FPC-JVM: Breaking up a cycle
On 27 Aug 2011, at 11:33, Sven Barth wrote: On 27.08.2011 00:49, Jonas Maebe wrote: BTW: the javapp program normally solves the ordering problem for you. However, it can't do that if there are circular references... Normally, you'd solve those by specifying the classes whose removal results in breaking the circle(s) using the -a parameter of javapp (it will then turn those classes into an empty definition), but that only works for top-level classes. Besides the AVViewGroup problem there weren't any circles, but javapp failed to order the other classes correctly... That's because the behaviour of the topological sort that's used to order them is probably undefined in the presence of cycles. Maybe it simply terminates when it encounters the first cycle to avoid getting stuck in an endless loop later. While we're at it: for one class (android.os.FileObserver, see here: http://developer.android.com/reference/android/os/FileObserver.html ) it generated the following: === source begin === public procedure init_(para1: JLString); overload; virtual; procedure init_(para1: JLString; para2: jint); overload; virtual; === source end === These should be constructers, shouldn't they? Other constructors (even with parameters) were converted correctly. What happens if you use javap to print that class rather than javapp? So javap -classpath android.jar android.os.FileObserver Besides this javapp is a invaluable tool for Pascal developers :D It was to be expected that it wouldn't work perfectly for everything immediately :) Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Problem with String = CharSequence
On 27 Aug 2011, at 12:00, Sven Barth wrote: Now that the cycle problem was solved (I don't know whether it works, because I'm still trying to get a test working ^^), I've encountered the next problem. The android.widget.TextView class has a method setText that takes a CharSequence which is implemented by java.lang.String. As I've read in the wiki UnicodeString is mapped to that type. But the following code pieces don't compile (tv is the TextView of type AWTextView): The fact that something is implemented by something else does not mean that the semantics are identical. E.g. a var s: set of TSomeEnum is implemented via java.util.EnumSet, but that does not mean that you can pass such a set to any method expecting a java.util.EnumSet. Similarly, you cannot use include() with a java.lang.EnumSet class instance. One is a Pascal set type, the other is a Java class type and both have their own behaviour. It is however possible to typecast one to the other via JLEnumSet(@enumsetvar) and PEnumSetType(enumsetinstance)^. Now, because strings are so common there's an exception in that unicodestrings will be implicitly typecasted to java.lang.String and vice versa (and in the svn version of the compiler, ansistrings and shortstrings will also be automatically converted to and from java.lang.String without typecasts). Automatic typecasting from unicodestring to java.lang.CharSequence could be added, but then it should also be added to java.lang.Object and then you very can get cannot choose which overloaded method to call situations, so I'm not sure whether this is a good idea. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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( 601): newInstance failed: p0 i0 [0 a1
D/AndroidRuntime( 601): Shutting down VM
W/dalvikvm( 601): threadid=1: thread exiting with uncaught exception
(group=0x40015560)
E/AndroidRuntime( 601): FATAL EXCEPTION: main
E/AndroidRuntime( 601): java.lang.RuntimeException: Unable to instantiate
activity
ComponentInfo{org.freepascal.helloworld/org.freepascal.helloworld.THelloWorld}:
java.lang.InstantiationException: org.freepascal.helloworld.THelloWorld
Is this an expected exception?
And here the log entry when building the Java based example with a class that
derives from TObject:
=== begin build log ===
[echo] Converting compiled files and external libraries into
/home/sven/projects/android/helloandroid/bin/classes.dex...
[apply]
[apply] UNEXPECTED TOP-LEVEL EXCEPTION:
[apply] com.android.dx.cf.code.SimException: local variable type mismatch:
attempt to set or access a value of type java.lang.Object using a local
variable of type boolean. This is symptomatic of .class transformation tools
that ignore local variable information.
Can you run the bytecode verifier on the class files generated for your
program? See http://wiki.freepascal.org/FPC_JVM/Debugging#Bytecode_verification
for the details. You may also have to add the android.jar to the class path for
the verifier to work (although I'm not 100% certain whether that will work in
case the android versions of java.lang.* start replacing the JDK versions of
the same classes for running the verifier itself)
first-fpc-dalvik.png
Nice :)
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Breaking up a cycle
While we're at it: for one class (android.os.FileObserver, see here:
http://developer.android.com/reference/android/os/FileObserver.html ) it
generated the following:
=== source begin ===
public
procedureinit_(para1: JLString); overload; virtual;
procedureinit_(para1: JLString; para2: jint); overload; virtual;
=== source end ===
These should be constructers, shouldn't they? Other constructors (even with
parameters) were converted correctly.
What happens if you use javap to print that class rather than javapp? So
javap -classpath android.jar android.os.FileObserver
Here it is:
=== output begin ===
Compiled from FileObserver.java
public abstract class android.os.FileObserver extends java.lang.Object{
public static final int ACCESS;
public static final int MODIFY;
public static final int ATTRIB;
public static final int CLOSE_WRITE;
public static final int CLOSE_NOWRITE;
public static final int OPEN;
public static final int MOVED_FROM;
public static final int MOVED_TO;
public static final int CREATE;
public static final int DELETE;
public static final int DELETE_SELF;
public static final int MOVE_SELF;
public static final int ALL_EVENTS;
public android.os.FileObserver(java.lang.String);
public android.os.FileObserver(java.lang.String, int);
protected void finalize();
public void startWatching();
public void stopWatching();
public abstract void onEvent(int, java.lang.String);
}
=== output end ===
Besides this javapp is a invaluable tool for Pascal developers :D
It was to be expected that it wouldn't work perfectly for everything
immediately :)
But it works good enough to convert most of the Android SDK without to
big problems :)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Problem with String = CharSequence
On 28.08.2011 21:32, Jonas Maebe wrote: On 27 Aug 2011, at 12:00, Sven Barth wrote: Now that the cycle problem was solved (I don't know whether it works, because I'm still trying to get a test working ^^), I've encountered the next problem. The android.widget.TextView class has a method setText that takes a CharSequence which is implemented by java.lang.String. As I've read in the wiki UnicodeString is mapped to that type. But the following code pieces don't compile (tv is the TextView of type AWTextView): The fact that something is implemented by something else does not mean that the semantics are identical. E.g. a var s: set of TSomeEnum is implemented via java.util.EnumSet, but that does not mean that you can pass such a set to any method expecting a java.util.EnumSet. Similarly, you cannot use include() with a java.lang.EnumSet class instance. One is a Pascal set type, the other is a Java class type and both have their own behaviour. It is however possible to typecast one to the other via JLEnumSet(@enumsetvar) and PEnumSetType(enumsetinstance)^. Now, because strings are so common there's an exception in that unicodestrings will be implicitly typecasted to java.lang.String and vice versa (and in the svn version of the compiler, ansistrings and shortstrings will also be automatically converted to and from java.lang.String without typecasts). Automatic typecasting from unicodestring to java.lang.CharSequence could be added, but then it should also be added to java.lang.Object and then you very can get cannot choose which overloaded method to call situations, so I'm not sure whether this is a good idea. Ok, thank you for the explanation of the behavior. Would adding an operator overload for implicit cast solve the problem? I'm not talking about adding it to System or JDK15, but maybe a seperate unit... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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=10035 gids={1015}
D/dalvikvm( 601): newInstance failed: p0 i0 [0 a1
D/AndroidRuntime( 601): Shutting down VM
W/dalvikvm( 601): threadid=1: thread exiting with uncaught exception
(group=0x40015560)
E/AndroidRuntime( 601): FATAL EXCEPTION: main
E/AndroidRuntime( 601): java.lang.RuntimeException: Unable to instantiate
activity
ComponentInfo{org.freepascal.helloworld/org.freepascal.helloworld.THelloWorld}:
java.lang.InstantiationException: org.freepascal.helloworld.THelloWorld
Is this an expected exception?
I'd say that it isn't an expected one... at least the converted class
doesn't contain a throws comment at its constructor...
And here the log entry when building the Java based example with a class that
derives from TObject:
=== begin build log ===
[echo] Converting compiled files and external libraries into
/home/sven/projects/android/helloandroid/bin/classes.dex...
[apply]
[apply] UNEXPECTED TOP-LEVEL EXCEPTION:
[apply] com.android.dx.cf.code.SimException: local variable type mismatch:
attempt to set or access a value of type java.lang.Object using a local
variable of type boolean. This is symptomatic of .class transformation tools
that ignore local variable information.
Can you run the bytecode verifier on the class files generated for your
program? See http://wiki.freepascal.org/FPC_JVM/Debugging#Bytecode_verification
for the details. You may also have to add the android.jar to the class path for
the verifier to work (although I'm not 100% certain whether that will work in
case the android versions of java.lang.* start replacing the JDK versions of
the same classes for running the verifier itself)
I don't think using the verifier on my own class files will be of much
use, because if I understand the log correct it complains about the code
in FpcBitSet.containsAll (mentioned in the last few lines before the
next empty one). Also - regarding your android.jar comment - I'm not
even using any Android classes in that example... just TObject (as a
base class) and UnicodeString (it tried to convert all RTL classes,
because I put the complete RTL in the projects bin directory, in which
all contained .class files are converted).
Regards,
SVen
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Problem with String = CharSequence
On 28 Aug 2011, at 22:02, Sven Barth wrote: Would adding an operator overload for implicit cast solve the problem? I'm not talking about adding it to System or JDK15, but maybe a seperate unit... I don't think that is not possible. You can at least not overload the assignment operator for types that can be explicitly typecasted to each other (which is the case for unicodestring and JLCharSequence). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on Android
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 === [echo] Converting compiled files and external libraries into /home/sven/projects/android/helloandroid/bin/classes.dex... [apply] [apply] UNEXPECTED TOP-LEVEL EXCEPTION: [apply] com.android.dx.cf.code.SimException: local variable type mismatch: attempt to set or access a value of type java.lang.Object using a local variable of type boolean. This is symptomatic of .class transformation tools that ignore local variable information. Can you run the bytecode verifier on the class files generated for your program? See http://wiki.freepascal.org/FPC_JVM/Debugging#Bytecode_verification for the details. You may also have to add the android.jar to the class path for the verifier to work (although I'm not 100% certain whether that will work in case the android versions of java.lang.* start replacing the JDK versions of the same classes for running the verifier itself) I don't think using the verifier on my own class files will be of much use, because if I understand the log correct it complains about the code in FpcBitSet.containsAll (mentioned in the last few lines before the next empty one). 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 to the Java version. Since the FPC RTL shipped with the snapshot is compiled against the JDK bindings, that would explain the problems. You could try to regenerate rtl/java/java_sys(h).inc using the first invocation listed at http://wiki.freepascal.org/FPC_JVM/Building#Building_javapp (but adding -classpath android.jar so it will use the android version of all those classes) and then rebuild the RTL (if it still compiles with those different signatures). Also - regarding your android.jar comment - I'm not even using any Android classes in that example... just TObject (as a base class) and UnicodeString (it tried to convert all RTL classes, because I put the complete RTL in the projects bin directory, in which all contained .class files are converted). The RTL uses android/JDK classes (such as several classes from java.lang and java.util). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Problem with String = CharSequence
On 28 Aug 2011, at 22:55, Jonas Maebe wrote: On 28 Aug 2011, at 22:02, Sven Barth wrote: Would adding an operator overload for implicit cast solve the problem? I'm not talking about adding it to System or JDK15, but maybe a seperate unit... I don't think that is not possible. -not Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Breaking up a cycle
On 28 Aug 2011, at 21:59, Sven Barth wrote:
Here it is:
=== output begin ===
Compiled from FileObserver.java
public abstract class android.os.FileObserver extends java.lang.Object{
public static final int ACCESS;
public static final int MODIFY;
public static final int ATTRIB;
public static final int CLOSE_WRITE;
public static final int CLOSE_NOWRITE;
public static final int OPEN;
public static final int MOVED_FROM;
public static final int MOVED_TO;
public static final int CREATE;
public static final int DELETE;
public static final int DELETE_SELF;
public static final int MOVE_SELF;
public static final int ALL_EVENTS;
public android.os.FileObserver(java.lang.String);
public android.os.FileObserver(java.lang.String, int);
protected void finalize();
public void startWatching();
public void stopWatching();
public abstract void onEvent(int, java.lang.String);
}
It's caused by the fact that javapp calls all constructors to create. It then
notices that the method name create conflicts with the constant CREATE, and
tries to solve it by renaming the constructor to its original name + '_' (and
setting the external name to the original name). Internally, the name of the
constructor in class files is init, so that gets changed into init_ and
as a result the filter afterwards to translate init to create isn't
triggered anymore.
I can fix that, but then the constructor will still be called Create_ rather
than Create :/
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Status report on 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 to the Java version. Since the FPC RTL shipped with the snapshot is compiled against the JDK bindings, that would explain the problems. Now I see: the Android VM apparently also looks at the debug information and checks whether it's appropriate everywhere. The compiler currently says for each local variable and parameter that it's located in a particular stack slot from start to finish of the method. However, if it's only used in part of the method, the stack slot may be reused by temporary values with different types (or because of SSA, it may migrate from one stack slot to another, because virtual registers are also mapped to stack slots). This is what the Android VM verifier is complaining about. You may be able to work around the issue for now by compiling without debugging information (-g-), but you'll also have to recompile the RTL without debug information. I believe Florian has been working recently on tracking the location of variables/parameters throughout the code of a procedure, so it may be possible to fix it with the help of that information. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Request to apply (and merge) patch from bug 19313
On 28/8/2011 05:07, Marco van de Voort wrote: In our previous episode, Luiz Americo Pereira Camara said: http://bugs.freepascal.org/view.php?id=19313 that fix the cited regression (notice that the fixes branch also has this bug) Done. Thanks Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
