Re: [fpc-devel] New FPC target: JVM
On 21 Aug 2011, at 02:37, dmitry boyarintsev wrote: So there're actually 2 code generators right now. One is used for JVM and another is used for native machine code? The JVM target only uses the high level code generator. The other targets use a combination of both. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On 21 Aug 2011, at 05:03, Paul Ishenin wrote: Sad that units with dots feature was blocked previosly - it would allow you to write java classes as is with namespace prefix instead of use abbrevations. I don't think that would be usable, unless we'd also allow something like Java's import java.xml.* or propagating uses. There are classes from 216 different packages in the jdk15 unit, so you could easily get enormous uses clauses without such a feature. I'm also not sure how it would work for the classes that are required in the system unit, since the system unit cannot depend on other units (even if it could for one special unit, that other unit would require system unit types such as jint or even longint). Even importing them under a different name wouldn't work, since e.g. TObject is derived from java.lang.Object and the compiler should allow you to typecast these types to each other. But if you have a type called Object in a unit called java.lang and a separate type JLObject from which TObject derives in the system unit, that wouldn't work. And dotted unit names would still introduce the ambiguities that caused the feature to be blocked. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Ok, not a full answer yet, but ...
Also have a fresh svn tree, built and got similar results.
Redirected build output to a text file, copied and pasted the line compiling
unitstr file to batch file. ADDED -Cpcortexm3 and rebuilt.
Disassembled the resulting object file and got:
stm32f103.o: file format elf32-littlearm
Disassembly of section .text.n_stm32f103__fpc_haltproc:
STM32F103__FPC_HALTPROC:
0:e7fe b.n0 STM32F103__FPC_HALTPROC
2:46f7 movpc, lr
Disassembly of section .text.n_stm32f103__fpc_start:
STM32F103__FPC_START:
0:f8df 1034 ldr.wr1, [pc, #52]; 38
STM32F103__FPC_START+0x38
4:4a0d ldrr2, [pc, #52]; (3c
STM32F103__FPC_START+0x3c)
6:4b0e ldrr3, [pc, #56]; (40
STM32F103__FPC_START+0x40)
8:429a cmpr2, r3
a:bf9e itttls
c:f851 0b04 ldrls.wr0, [r1], #4
10:f842 0b04 strls.wr0, [r2], #4
14:e7f8 bls.n8 STM32F103__FPC_START+0x8
16:4906 ldrr1, [pc, #24]; (30
STM32F103__FPC_START+0x30)
18:4a06 ldrr2, [pc, #24]; (34
STM32F103__FPC_START+0x34)
1a:f04f mov.wr0, #0
1e:4291 cmpr1, r2
20:bf9c ittls
22:f841 0b04 strls.wr0, [r1], #4
26:e7fa bls.nfff8 PASCALMAIN+0xfff8
28:f7ff bffe b.w0 PASCALMAIN
2c:f7ff bffe b.w0 STM32F103__FPC_START
...
44:0048 .word0x0048
48:46f7 movpc, lr
4a:46f7 movpc, lr
This looks more like what I would expect for Thumb mode, so it's a build
problem
where the cpu is not getting set to Thumb2 mode when it builds the Thumb2 RTL
files.
John
From: David Welch dwe...@dwelch.com
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sun, August 21, 2011 12:24:34 AM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
thumb2 is an extension to thumb not arm, you can mix thumb and arm in T
variants
like the v4T v5T and anything after that v6 on up, except for the cortex-m
variants which are thumb+thumb2 only and cannot execute ARM 32 bit instructions
(yes thumb2 32 bit thumb extensions but nothing from the ARM instruction set).
Here is an example of the problem I am seeing:
took a clean copy from svn
svn co http://svn.freepascal.org/svn/fpc/trunk fpc
cd fpc
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm INSTALL_PREFIX=/fpcarm
test.pp
procedure Wait(d : dword);
begin
while d0 do
dec(d);
end;
begin
while true do
begin
Wait($2);
end;
end.
test.pp
./compiler/ppcrossarm -Parm -Tembedded -Wpstm32f103re -Cpcortexm3 test.pp
Free Pascal Compiler version 2.7.1 [2011/08/20] for arm
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Embedded
Compiling test.pp
Assembling program
Linking test
/opt/embarm/arm-embedded-ld: warning: library search path
/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/ is unsafe for
cross-compilation
14 lines compiled, 0.0 sec
then dumped the binary:
0800 _START-0x158:
800:2000fffc strdcspc, [r0], -ip
804:08000405 stmdaeqr0, {r0, r2, sl}
808:08000405 stmdaeqr0, {r0, r2, sl}
80c:08000405 stmdaeqr0, {r0, r2, sl}
810:08000405 stmdaeqr0, {r0, r2, sl}
814:08000405 stmdaeqr0, {r0, r2, sl}
818:08000405 stmdaeqr0, {r0, r2, sl}
...
08000194 PASCALMAIN:
8000194:46ec movip, sp
8000196:e92d 4800 stmdbsp!, {fp, lr}
800019a:f1ac 0b04 sub.wfp, ip, #4
800019e:b08a subsp, #40; 0x28
80001a0:f000 f844 bl800022c FPC_INITIALIZEUNITS
80001a4:e004 b.n80001b0 PASCALMAIN+0x1c
80001a6:bf00 nop
80001a8:f44f 3000 mov.wr0, #131072; 0x2
80001ac:f7ff ffd8 bl8000160 P$PROGRAM_WAIT$LONGWORD
80001b0:e7fa b.n80001a8 PASCALMAIN+0x14
80001b2:f000 f8ff bl80003b4 FPC_DO_EXIT
80001b6:46dd movsp, fp
80001b8:b001 addsp, #4
80001ba:e91d 8800 ldmdbsp, {fp, pc}
80001be:bf00 nop
...
08000404 STM32F103__FPC_START:
8000404:e59f103c ldrr1, [pc, #60]; 8000448
STM32F103__FPC_START+0x44
8000408:e59f203c ldrr2, [pc, #60]; 800044c
STM32F103__FPC_START+0x48
800040c:e59f303c ldrr3, [pc, #60]; 8000450
STM32F103__FPC_START+0x4c
8000410:e1520003 cmpr2, r3
8000414:94910004 ldrlsr0, [r1], #4
First off 0x08000405 implies a thumb target but it is not thumb code, it is arm
code so 0x08000404 would be correct but that is still wrong because cores with
that vector table (cortex-m) cannot execute arm
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Den 21-08-2011 00:00, David Welch skrev: A! that makes sense. I assume that is either leftover from a prior build? And how do I get a new/fresh build to look in the right place? It's installed in /fpcarm. This directory should contain a bin and units directory. You simply need to change your main fpc.cfg file to match those settings. I don't know precisely how that would be done on a unix system. Maybe it would even install directly to your current install directory, if you just run this? make buildbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 sudo make installbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 On a side note, I find it strange that it even accepts your old leftover files. I thought the linker normally would complain about interwork stuff ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On 20 August 2011 17:54, Mattias Gaertner wrote: Why did Google do that? Why don't you google yourself? Lets see if I understand this correctly. Dalvik was designed to be suitable for systems that are constrained in terms of memory and processor speed. (Quoted from Wikipedia) Yet today's smart phones and tablets are more powerful than the desktops of just a few years ago, or even the computers that first sent man to the moon. Now lets not even talk amount of memory. Most mobile devices have 512-1GB memory these days - again more than most desktops had just a few years ago. So Google creating a incompatible Java for this supposed limitation of processor speed and low memory. Yeah Sun's Java ran fine on desktops of 10-15 years ago, and even on PDA's of that time. Google is doing with Android just the opposite of what Sun's Java stands for - compile once, run everywhere. If Google wanted something different for their Android platform, they should not have called it Java then. What benefits do you miss? Compile Java (SE, ME etc) apps once, run everywhere. Java is just a language. No, Java is also known as a platform (like Java Virtual Machine). Google (like Microsoft before it) is now tainting the Java platform by making it incompatible with existing Java. Like I said, if they wanted something different, they should have named it differently too. Anyway, I never said I'm an expert in Android. I'll research the subject further to get a clearer picture. A jvm backend for fpc is great. I hope it is not too much work to maintain. I have no issues with FPC supporting the Java platform as a target - I think this is great news indeed. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On 21 Aug 2011, at 11:52, Graeme Geldenhuys wrote: Lets see if I understand this correctly. Dalvik was designed to be suitable for systems that are constrained in terms of memory and processor speed. (Quoted from Wikipedia) Yet today's smart phones and tablets are more powerful than the desktops of just a few years ago, or even the computers that first sent man to the moon. Mobile platforms are all about power consumption in order to make batteries last as long as possible. Generally: faster = less power usage. No, Java is also known as a platform (like Java Virtual Machine). There are three separate things: * Java the programming language * the JVM platform/specification * the JDK There are indeed commonly called together the Java platform, but they are not indivisible. That's why it's possible to e.g. compile Pascal code into JVM byte code that makes use of the JDK. Google (like Microsoft before it) is now tainting the Java platform by making it incompatible with existing Java. Google is doing several things: * they kept the Java programming language * they replaced the JVM with Dalvik, to make it faster/more power efficient (by doing a bunch of analyses and transformations that are normally done at run time at compile time). This by itself does not introduce incompatibilities, since Java class files can be translated into Dalvik class files * they replaced the JDK with their own class library, the Android SDK Do you think it would have been better if they had said you program in the Android language, which is identical to the Java language? Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM patch to switch to controller records rather than arrays
On 21 Aug 2011, at 00:35, John Clymer wrote: DIFF attached for comment and review. Provides the following features / difference: 1) Switched operation of cpuinfo.pas - there is still a SET containing the ct_ constants, but that now indexes an array of structures rather than a collection of arrays. The array contains the info from the old arrays, PLUS FLASH, SRAM and EPROM memory definitions i.e. BASE and SIZE for each. NOTE: Switched for both ARM and AVR. AVR changes will compile the cross compiler, but choke while building the RTL (complaining about a function being too complex). However, the SVN and daily build exhibit the same behaviour - so I do not believe I have broken the AVR any further than it was broken. 2) Added LM3FURY controller unit file - this will be built up into a base unit file for all the Fury class Stellaris controllers. 3) I intend to leave the Stellaris controller class with the intention that those that don't want a full set of system defines can use this class and will receive nothing more than the bare minimum to boot a chip into PASCALMAIN. The Flash and SRAM sizes will be set very large - so caveat emptor to the user if, as they will need to ensure the programs do not require more resources than their chip require. It actually renders it unusable if the ram size is bigger than that in the device you are using as the stack top will be set outside the available ram. It has only ever worked before with the correct ram/flash sizes as I pointed out to you. It should be for specific known combinations, the ct_stellaris was incorrect before you diff'ed it, and now you have introduced another error (stack_top=0x20fffc?). Personally, as somebody using this compiler on real projects, I think there are too many changes proposed here in one hit, completely untested. festina lente ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
One thing which I am curious: What is the main use case which led to this work? I can imagine it would be useful for example to have a work focused on j2me in order to target phones which run only Java and nothing else (although in reality j2me is each time more obsolete with the spread of smartphones), but for desktop platforms which can already run native applications without any fuss I wonder what the use case of a Pascal to Java compiler is. Even for Android, I'm not sure such a Java port is much better then JNI. I'm not saying it isn't great to have this new option, because it clearly is, I'm just curious. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On Sunday, 21 August 2011, Jonas Maebe jonas. wrote: Google is doing several things: * they kept the Java programming language * they replaced the JVM with Dalvik, to make it faster/more power efficient (by doing a bunch of analyses and transformations that are normally done at run time at compile time). This by itself does not introduce incompatibilities, since Java class files can be translated into Dalvik class files * they replaced the JDK with their own class library, the Android SDK Ok, thanks for explaining (without the hostile tone like Mattias). From the Dalvik Wikipedia page, converting Sun Java class files to Google Java is not always possible. It seems to be a hit and miss case. But I guess recompiling the source code might have better sucsess. Do you think it would have been better if they had said you program in the Android language, which is identical to the Java language? Yes, not identical though, just similar syntax. Graeme. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : [fpc-devel] New FPC target: JVM
No, Java is also known as a platform (like Java Virtual Machine). There are three separate things: * Java the programming language * the JVM platform/specification * the JDK There are indeed commonly called together the Java platform, but they are not indivisible. That's why it's possible to e.g. compile Pascal code into JVM byte code that makes use of the JDK. And for gnu gcj to compile java into native machine code. No bytecode involved. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On Sat, Aug 20, 2011 at 5:02 PM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Why did Google do that? Why not stay with the standardized Java and get the benefits of all existing Java and Mobile Java apps? Java mobile (j2me) is almost completely different from usual Java APIs, even more then the Android API is different from JDK I'd say, and the j2me APIs are horrible, very slow, and they also work widely different across various phones. If anyone beliaves that j2me is write once and run everywhere without debugging in the hundreds of available phones, he clearly never wrote software on it =D I am happy j2me is getting obsolete. I don't know much about Android, but just when I thought it sounded great, I hear things like this. :-( I don't think this makes any difference, my main problem with Android is that they do not allow users to run purely native executables. If native apps work fine for the iPhone, they should have worked fine in Android too, no need for Java. Their current architecture really isn't the best IMHO, but it also not that bad either, compared to the competition, it is reasonably workable. Android is much better then BlackBerry or Windows Phone. You can actually run native Pascal code in Android, which means that you can use all those libraries which we have without any code changes, while in those other 2 the answer is just: no, no, no -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM patch to switch to controller records rather than arrays
Actually, I removed the hard coded stack_top, and put in a line to place
stack_top at the very top of RAM - dependent up on the settings in the
controller structure.
+ Add('_stack_top = 0x' + IntToHex(sramsize+srambase-4,8) + ';');
This sets stack_top to the very top of the SRAM space minus 4 bytes. So long
as
the srambase and sramsize are correct, the stack pointer will get set to the
top
of SRAM.
Not sure how you are making your conclusion. Any line with
stack_top=0x20fffc
is being deleted with this patch.
However, if I might ask - which controller are you using this on ?
Thanks,
John
From: Geoffrey Barton m...@periphon.net
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sun, August 21, 2011 2:46:55 PM
Subject: Re: [fpc-devel] ARM patch to switch to controller records rather than
arrays
On 21 Aug 2011, at 00:35, John Clymer wrote:
DIFF attached for comment and review. Provides the following features /
difference:
1) Switched operation of cpuinfo.pas - there is still a SET containing the ct_
constants, but that now indexes an array of structures rather than a
collection
of arrays. The array contains the info from the old arrays, PLUS FLASH, SRAM
and EPROM memory definitions i.e. BASE and SIZE for each.
NOTE: Switched for both ARM and AVR. AVR changes will compile the cross
compiler, but choke while building the RTL (complaining about a function
being
too complex). However, the SVN and daily build exhibit the same behaviour - so
I
do not believe I have broken the AVR any further than it was broken.
2) Added LM3FURY controller unit file - this will be built up into a base unit
file for all the Fury class Stellaris controllers.
3) I intend to leave the Stellaris controller class with the intention that
those that don't want a full set of system defines can use this class and will
receive nothing more than the bare minimum to boot a chip into PASCALMAIN.
The
Flash and SRAM sizes will be set very large - so caveat emptor to the user if,
as they will need to ensure the programs do not require more resources than
their chip require.
It actually renders it unusable if the ram size is bigger than that in the
device you are using as the stack top will be set outside the available ram. It
has only ever worked before with the correct ram/flash sizes as I pointed out
to
you. It should be for specific known combinations, the ct_stellaris was
incorrect before you diff'ed it, and now you have introduced another error
(stack_top=0x20fffc?).
Personally, as somebody using this compiler on real projects, I think there are
too many changes proposed here in one hit, completely untested.
festina lente
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On 21 Aug 2011, at 13:45, Felipe Monteiro de Carvalho wrote: One thing which I am curious: What is the main use case which led to this work? Application servers (usually web server backends). And the fact that it prepares the compiler for an LLVM backend: Java byte code is less strict about types than LLVM byte code (e.g. Java byte code does not specify full type information for temporary values, while LLVM byte code does), so it was a good first step to finally get things moving. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
20.08.2011 16:49, Jonas Maebe wrote: Download information, usage information etc is available at http://wiki.freepascal.org/FPC_JVM Regarding Android: the compiler and the system unit both use a bunch of standard functionality from the JDK to implement various features. So Android support would probably require quite a bit of extra work. I have not looked into that. Enjoy! Some people from Russian community tried to start to enjoy but failed :) http://www.freepascal.ru/forum/viewtopic.php?t=7325#p55875 http://www.freepascal.ru/forum/viewtopic.php?t=7325view=unread#unreadBest regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On 21 Aug 2011, at 15:29, Paul Ishenin wrote: 20.08.2011 16:49, Jonas Maebe wrote: Download information, usage information etc is available at http://wiki.freepascal.org/FPC_JVM Regarding Android: the compiler and the system unit both use a bunch of standard functionality from the JDK to implement various features. So Android support would probably require quite a bit of extra work. I have not looked into that. Enjoy! Some people from Russian community tried to start to enjoy but failed :) http://www.freepascal.ru/forum/viewtopic.php?t=7325#p55875 The problems are a) he is adding the '.class' extension when trying to run the program. You have to specify the name of the class to run, not the name of the class file (so leave out the '.class') b) he should specify the base path to the FPC rtl classes via the -cp parameter, as explained at http://wiki.freepascal.org/FPC_JVM/Usage#Running_compiled_programs I've added a quick start example at http://wiki.freepascal.org/FPC_JVM#Quick_start Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM patch to switch to controller records rather than arrays
On 21 Aug 2011, at 13:47, John Clymer wrote:
Actually, I removed the hard coded stack_top, and put in a line to place
stack_top at the very top of RAM - dependent up on the settings in the
controller structure.
+ Add('_stack_top = 0x' + IntToHex(sramsize+srambase-4,8) + ';');
This sets stack_top to the very top of the SRAM space minus 4 bytes. So long
as the srambase and sramsize are correct, the stack pointer will get set to
the top of SRAM.
Not sure how you are making your conclusion. Any line with
stack_top=0x20fffc is being deleted with this patch.
ok, it should have been 0x2000fffc to start with if it is for a 64k device.
Somebody also posted that stack_top could be ram_size+ram_base, I suppose
because the sp is decremented before writing. But I am no expert on this. I
have had obscure warnings from Keil MDK when linking (from C, yes it works) to
units compiled with FPC, and I have wondered whether it is stack alignment, but
not got much further with it.
However, if I might ask - which controller are you using this on ?
LM3S9B92 is what I used to test the existing stellaris startup on. I am now
using LM3S9B95 and LM3S5D51, the latter being 512k flash/96k ram. These are
'tempest' class devices I think; I would suggest not bothering about the
earlier classes of device. And that is another reason I don't think detailed
device info should go in the compiler. As there is no OS I think the minimal
RTL and info essential to the compiler/as/ld ie. flash, ram size, should be
there as compiler user options, but nothing device specific.
Geoffrey
Thanks,
John
From: Geoffrey Barton m...@periphon.net
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sun, August 21, 2011 2:46:55 PM
Subject: Re: [fpc-devel] ARM patch to switch to controller records rather
than arrays
On 21 Aug 2011, at 00:35, John Clymer wrote:
DIFF attached for comment and review. Provides the following features /
difference:
1) Switched operation of cpuinfo.pas - there is still a SET containing the
ct_ constants, but that now indexes an array of structures rather than a
collection of arrays. The array contains the info from the old arrays, PLUS
FLASH, SRAM and EPROM memory definitions i.e. BASE and SIZE for each.
NOTE: Switched for both ARM and AVR. AVR changes will compile the cross
compiler, but choke while building the RTL (complaining about a function
being too complex). However, the SVN and daily build exhibit the same
behaviour - so I do not believe I have broken the AVR any further than it
was broken.
2) Added LM3FURY controller unit file - this will be built up into a base
unit file for all the Fury class Stellaris controllers.
3) I intend to leave the Stellaris controller class with the intention
that those that don't want a full set of system defines can use this class
and will receive nothing more than the bare minimum to boot a chip into
PASCALMAIN. The Flash and SRAM sizes will be set very large - so caveat
emptor to the user if, as they will need to ensure the programs do not
require more resources than their chip require.
It actually renders it unusable if the ram size is bigger than that in the
device you are using as the stack top will be set outside the available ram.
It has only ever worked before with the correct ram/flash sizes as I pointed
out to you. It should be for specific known combinations, the ct_stellaris
was incorrect before you diff'ed it, and now you have introduced another
error (stack_top=0x20fffc?).
Personally, as somebody using this compiler on real projects, I think there
are too many changes proposed here in one hit, completely untested.
festina lente
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 20 Aug 2011, at 15:46, David Welch wrote: The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc. You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM. Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood. not quite, but it is my aspiration :-) And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems. I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. So far it seems to be very straight forward to add a platform/device to fpc arm embedded, so if the stock support is too bulky or confusing individuals can cherry pick items they want and make their own simpler target. The approach used in coide is quite interesting. Have a look on coocox.org. They have it down to box ticking. Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals. I agree. I understand this is a work in progress and sorting everything out will take some time. Unfortunately the discussion is rather torn between the basic simplicity camp and the portmanteau camp. I rather think the latter is more suitable for a commercial company which can afford the maintenance, otherwise it is always out-of-date. Keeping up with new ARM cores is perhaps enough to do already. Geoffrey. David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
As interesting is that it will assemble thumb2 code as arm code and not fail/stop during that step in the build. Thanks for the help, will try that. David On 08/21/2011 05:23 AM, Jeppe Græsdal Johansen wrote: Den 21-08-2011 00:00, David Welch skrev: A! that makes sense. I assume that is either leftover from a prior build? And how do I get a new/fresh build to look in the right place? It's installed in /fpcarm. This directory should contain a bin and units directory. You simply need to change your main fpc.cfg file to match those settings. I don't know precisely how that would be done on a unix system. Maybe it would even install directly to your current install directory, if you just run this? make buildbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 sudo make installbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 On a side note, I find it strange that it even accepts your old leftover files. I thought the linker normally would complain about interwork stuff ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now). Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.) Also, still testing, but I have the interrupt reserved word working (more or less, more testing needed.) This takes the interrupt codeword with an integer. The integer is the offset into the vectors table. If no interrupt is provided for the given address, it defaults to DefaultHandler in the startup file - which is just a continual loop - so one can breakpoint on it. (This can be enabled / disabled via a define in the source.) This is should only be enabled for the embedded target - but I need to double check to ensure that is the case. Fortunately, I have a few days off before the school semester starts - so I will be working on this quite heavily over the next few days. John From: Geoffrey Barton m...@periphon.net To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sun, August 21, 2011 6:01:22 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status On 20 Aug 2011, at 15:46, David Welch wrote: The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc. You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM. Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood. not quite, but it is my aspiration :-) And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems. I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. So far it seems to be very straight forward to add a platform/device to fpc arm embedded, so if the stock support is too bulky or confusing individuals can cherry pick items they want and make their own simpler target. The approach used in coide is quite interesting. Have a look on coocox.org. They have it down to box ticking. Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals. I agree. I understand this is a work in progress and sorting everything out will take some time. Unfortunately the discussion is rather torn between the basic simplicity camp and the portmanteau camp. I rather think the latter is more suitable for a commercial company which can afford the maintenance, otherwise it is always out-of-date. Keeping up with new ARM cores is perhaps enough to do already. Geoffrey. David ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
In our previous episode, John Clymer said: As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now). Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.) I don't use embedded arm, but on other microcontrollers, bootloaders are often also at the end of the flash. The main reason for this is to avoid having to modify the linker file for normal programs (to switch between bootloadable and not). For that, you need to have the exact amount of flash in your CPU profile. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 21 Aug 2011, at 15:33, John Clymer wrote: As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now). Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.) As I pointed out, this will always fail because the stacktop is set beyond the available ram. It will cause an exception I think. How do you propose to be able to set the actual ram top for the generic part, or am I missing something? Also, still testing, but I have the interrupt reserved word working (more or less, more testing needed.) This takes the interrupt codeword with an integer. The integer is the offset into the vectors table. If no interrupt is provided for the given address, it defaults to DefaultHandler in the startup file - which is just a continual loop - so one can breakpoint on it. (This can be enabled / disabled via a define in the source.) This is should only be enabled for the embedded target - but I need to double check to ensure that is the case. This is a useful development; ideally the integer would be backed by an enumeration as it is a big table. One thing which I did find missing was the interrupt enable and disable assembler codes, so I patched them with data bytes hidden in functions. The keil C compiler does not like these if you link to units doing this (throws a data/code wobbly). See the file attached to bug tracker ID0017365 for how I hacked interrupts. Fortunately, I have a few days off before the school semester starts - so I will be working on this quite heavily over the next few days. all power to your elbow... Geoffrey John From: Geoffrey Barton m...@periphon.net To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sun, August 21, 2011 6:01:22 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status On 20 Aug 2011, at 15:46, David Welch wrote: The great strength of ARM is that the peripherals, even if in different locations in different manufacturers parts, are identical in hardware terms if they are all cortex m3; that is the IP which they license from ARM.com. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler. Geoffrey Not sure what you are saying here, almost none of the peripherals are the same from vendor to vendor. With the cortex-m3 the systick timer and the VNIC for example are from ARM, sure, but the majority of the items you are going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor specific and vastly different from vendor to vendor. Within a vendor they are very similar if not the same but from ti to st most of the items are not compatible, likewise from ti to lpc/nxp or ti to atmel, etc. You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM. Normally these are libraries and not buried in the compiler proper, I agree with that. Perhaps that is what you were saying and I misunderstood. not quite, but it is my aspiration :-) And as with libraries you can take them or leave them, that would want to be the case here (without having to dig into the compiler proper). Would need to roll your own target to avoid/modify a library. Ideally with the compiler you want to specify the arm core to take advantages of instructions each newer core supports. Not use them to tie to boards or systems. I was hoping for thumb support but I now see that the choices are limited to arm and thumb+thumb2 (without any separation between thumb and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride this along for a while and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. So far it seems to be very straight forward to add a platform/device to fpc arm embedded, so if the stock support is too bulky or confusing individuals can cherry pick items they want and make their own simpler target. The approach used in coide is quite interesting. Have a look on coocox.org. They have it down to box ticking. Actually what we definitely need here in the near term is an arm generic target and a thumb2 generic target that does not have any of the vendor specific items in it, perhaps not even core specific peripherals. I agree. I understand this is a work in progress and sorting everything out will
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Den 21-08-2011 17:06, Geoffrey Barton skrev:
On 21 Aug 2011, at 15:33, John Clymer wrote:
As part of my table-ization of cpuinfo.pas, I am including a generic
part for each (no code published for this yet.) The caveat to this
is that FLASH size and SRAM sizes are just set to extremely large (1
MB each for now). Which means if the code size exceeds the space of
the device - the compiler/linker will not catch the overflow of the
available resource. (Running objsize on the ELF file will display
the sizes - so I just run that after every successful compile.)
As I pointed out, this will always fail because the stacktop is set
beyond the available ram. It will cause an exception I think. How do
you propose to be able to set the actual ram top for the generic part,
or am I missing something?
Also, still testing, but I have the interruptreserved word working
(more or less, more testing needed.) This takes the interrupt
codeword with an integer. The integer is the offset into the vectors
table. If no interrupt is provided for the given address, it
defaults to DefaultHandler in the startup file - which is just a
continual loop - so one can breakpoint on it. (This can be enabled /
disabled via a define in the source.) This is should only be enabled
for the embedded target - but I need to double check to ensure that
is the case.
This is a useful development; ideally the integer would be backed by
an enumeration as it is a big table. One thing which I did find
missing was the interrupt enable and disable assembler codes, so I
patched them with data bytes hidden in functions. The keil C compiler
does not like these if you link to units doing this (throws a
data/code wobbly). See the file attached to bug tracker ID0017365 for
how I hacked interrupts.
The CPS* instruction with the correct operand syntax was added in #18334
SVN trunk already has experimental support for the interrupt keyword.
It's enabled with FPC_HAS_SYSTEMS_INTERRUPT_TABLE in fpcdefs.inc. I
discovered a small bug with the current implementation which is fixed
with the attached patch(which also includes some other stuff... the
bugfix is in ncgutil. It didn't search the program file for interrupt
handlers before)
Index: compiler/fpcdefs.inc
===
--- compiler/fpcdefs.inc(revision 18784)
+++ compiler/fpcdefs.inc(working copy)
@@ -33,7 +33,7 @@
$define FPC_HAS_SYSTEMS_INTERRUPT_TABLE
to fpcdefs.inc to reactivate
the corresponding code }
-{$undef FPC_HAS_SYSTEMS_INTERRUPT_TABLE}
+{$define FPC_HAS_SYSTEMS_INTERRUPT_TABLE}
{ This fake CPU is used to allow incorporation of globtype unit
into utils/ppudump without any CPU specific code PM }
Index: compiler/ncgutil.pas
===
--- compiler/ncgutil.pas(revision 18784)
+++ compiler/ncgutil.pas(working copy)
@@ -3197,7 +3197,30 @@
end;
hp:=tused_unit(hp.next);
end;
+for i := 0 to current_module.symlist.Count-1 do
+ begin
+sym:=tsym(current_module.symlist[i]);
+if not assigned(sym) then
+ continue;
+if sym.typ = procsym then
+ begin
+for i2 := 0 to tprocsym(sym).ProcdefList.Count-1 do
+ begin
+pd:=tprocdef(tprocsym(sym).ProcdefList[i2]);
+if pd.interruptvector = 0 then
+ begin
+if pd.interruptvector high(interruptTable) then
+ Internalerror(2011030602);
+if interruptTable[pd.interruptvector] nil then
+ internalerror(2011030601);
+interruptTable[pd.interruptvector]:=pd;
+break;
+ end;
+ end;
+ end;
+ end;
+
new_section(current_asmdata.asmlists[al_globals],sec_init,'VECTORS',sizeof(pint));
current_asmdata.asmlists[al_globals].concat(Tai_symbol.Createname_global('VECTORS',AT_DATA,0));
{$IFDEF arm}
Index: compiler/pdecsub.pas
===
--- compiler/pdecsub.pas(revision 18784)
+++ compiler/pdecsub.pas(working copy)
@@ -2308,7 +2308,7 @@
idtok:_INTERRUPT;
pd_flags :
[pd_implemen,pd_body,pd_notobject,pd_notobjintf,pd_notrecord,pd_nothelper];
handler : @pd_interrupt;
- pocall : pocall_oldfpccall;
+ pocall : pocall_interrupt;
pooption : [po_interrupt];
mutexclpocall :
[pocall_internproc,pocall_cdecl,pocall_cppdecl,pocall_stdcall,
pocall_pascal,pocall_far16,pocall_oldfpccall];
Index: compiler/systems.pas
===
--- compiler/systems.pas(revision 18784)
+++
Re: [fpc-devel] Arm Thumb2 - Stellaris status
I found FPC_HAS_SYSTEMS_INTERRUPT_TABL, enabled it - but it was still broken for Thumb2 (stellaris, stm32). For Thumb2, it was broken in the following ways: 1) Stack_top should be placed at vector 0. 2) Each address should have the LSB set - to force Thumb mode when the PC gets loaded with that value. I defined FPC_HAS_SYSTEMS_INTERRUPT_TABLE a little further down - so that was only enabled on ARM and AVR (trying not to break other things...) I also have some added logic in ncgutil - for M3 devices - to place the stack_top into vector 0, then place handlers for vectors 1 to TOP. The WriteVector routine for Thumb also adds an offset of 1 to each vector - so as to force Thumb mode upon load to PC. John From: Jeppe Græsdal Johansen jjoha...@student.aau.dk To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sun, August 21, 2011 7:27:48 PM Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status Den 21-08-2011 17:06, Geoffrey Barton skrev: On 21 Aug 2011, at 15:33, John Clymer wrote: As part of my table-ization of cpuinfo.pas, I am including a generic part for each (no code published for this yet.) The caveat to this is that FLASH size and SRAM sizes are just set to extremely large (1 MB each for now).Which means if the code size exceeds the space of the device - the compiler/linker will not catch the overflow of the available resource. (Running objsize on the ELF file will display the sizes - so I just run that after every successful compile.) As I pointed out, this will always fail because the stacktop is set beyond the available ram. It will cause an exception I think. How do you propose to be able to set the actual ram top for the generic part, or am I missing something? Also, still testing, but I have the interrupt reserved word working (more or less, more testing needed.)This takes the interrupt codeword with an integer.The integer is the offset into the vectors table. If no interrupt is provided for the given address, it defaults to DefaultHandler in the startup file - which is just a continual loop - so one can breakpoint on it. (This can be enabled / disabled via a define in the source.) This is should only be enabled for the embedded target - but I need to double check to ensure that is the case. This is a useful development; ideally the integer would be backed by an enumeration as it is a big table. One thing which I did find missing was the interrupt enable and disable assembler codes, so I patched them with data bytes hidden in functions. The keil C compiler does not like these if you link to units doing this (throws a data/code wobbly). See the file attached to bug tracker ID0017365 for how I hacked interrupts. The CPS* instruction with the correct operand syntax was added in #18334 SVN trunk already has experimental support for the interrupt keyword. It's enabled with FPC_HAS_SYSTEMS_INTERRUPT_TABLE in fpcdefs.inc. I discovered a small bug with the current implementation which is fixed with the attached patch(which also includes some other stuff... the bugfix is in ncgutil. It didn't search the program file for interrupt handlers before) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Den 21-08-2011 17:43, John Clymer skrev: I found FPC_HAS_SYSTEMS_INTERRUPT_TABL, enabled it - but it was still broken for Thumb2 (stellaris, stm32). For Thumb2, it was broken in the following ways: 1) Stack_top should be placed at vector 0. I disagree, but I guess that's a question of interpretation. I don't think it's really a vector. So currently vector 0 is for the reset vector at address 0x8004, and _stack_top is placed in front of the table 2) Each address should have the LSB set - to force Thumb mode when the PC gets loaded with that value. That's the linkers job. And it is handled correctly currently as long as the labels where they are pointing to are marked with the .thumb_func directive(as they are when using -Cpcortexm3) I defined FPC_HAS_SYSTEMS_INTERRUPT_TABLE a little further down - so that was only enabled on ARM and AVR (trying not to break other things...) I also have some added logic in ncgutil - for M3 devices - to place the stack_top into vector 0, then place handlers for vectors 1 to TOP. The WriteVector routine for Thumb also adds an offset of 1 to each vector - so as to force Thumb mode upon load to PC. You shouldn't add anything to get thumb vectors, as I explained further up. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On Sun, Aug 21, 2011 at 3:45 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 21 Aug 2011, at 02:37, dmitry boyarintsev wrote: So there're actually 2 code generators right now. One is used for JVM and another is used for native machine code? The JVM target only uses the high level code generator. The other targets use a combination of both. Are there a plans to merge branches (trunk and jvm branch) together? or is it actually the next planned step? What about changing the native code generator to become more high level as JVM? On Sun, Aug 21, 2011 at 9:33 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: Some people from Russian community tried to start to enjoy but failed :) http://www.freepascal.ru/forum/viewtopic.php?t=7325#p55875 sorry, didn't get to translation of Usage page yet. thanks, Dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On Sun, Aug 21, 2011 at 5:33 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: The problems are a) he is adding the '.class' extension when trying to run the program. You have to specify the name of the class to run, not the name of the class file (so leave out the '.class') b) he should specify the base path to the FPC rtl classes via the -cp parameter, as explained at http://wiki.freepascal.org/FPC_JVM/Usage#Running_compiled_programs I've added a quick start example at http://wiki.freepascal.org/FPC_JVM#Quick_start I followed the instruction and again it failed to run the application. However, it's unsaid that location of the .class file should also be listed in -cp option. At least it worked fine for me. I tried it in Windows, so I'm not sure if it's required for Unix OSes, but it appears that working directory isn't used by java for classpath searching. Jonas, I'd suspect you have environment variable CLASSPATH setup in your system or something like that, that doesn't require you specify the path to .class file. In the end, it has nothing to do with ppcvmj, but rather than usage of java application :) I added a small note to Quick Start feel free to delete it anyway. thanks, Dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM patch to switch to controller records rather than arrays
Am 21.08.2011 01:35, schrieb John Clymer: DIFF attached for comment and review. Provides the following features / difference: 1) Switched operation of cpuinfo.pas - there is still a SET containing the ct_ constants, but that now indexes an array of structures rather than a collection of arrays. The array contains the info from the old arrays, PLUS FLASH, SRAM and EPROM memory definitions i.e. BASE and SIZE for each. NOTE: Switched for both ARM and AVR. AVR changes will compile the cross compiler, but choke while building the RTL (complaining about a function being too complex). However, the SVN and daily build exhibit the same behaviour - so I do not believe I have broken the AVR any further than it was broken. tcontrollerdatatype should be declared only once. 2) Added LM3FURY controller unit file - this will be built up into a base unit file for all the Fury class Stellaris controllers. The file is missing. 7) IF controllerunitstr is empty - then no added file is included in the build (again, to support a base controller type - with no defines what so ever - power user option) This should be boundy to some controller type like dummy else beginners will stumble on it. Besides this, the patch can be applied imo. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On Sat, Aug 20, 2011 at 11:49 AM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: Hi, There is a new branch in svn (branches/jvmbackend) that contains support for compiling Pascal code into Java virtual machine bytecode. While it does not support all language constructs and while there are some differences in some features that are supported, in general the result is fairly close to normal Pascal you'd write. Note however that this is a pure compiler port at this time. That means that while most of the language support is fairly complete, pretty much no standard Pascal units are available. For all practical intents and purposes there is only the system unit, and even that one misses many routines (including helpers required for basic functions such as read(ln)/write(ln), val, str, delete, pos, ...). On the other hand, a unit that contains the entire public interface of the JDK 1.5 is available. Over time, it should be possible to provide most of the standard functionality of the system unit (and other units) implemented on top of that unit, or rewritten in Pascal code that does not depend on untyped pointer accesses. Download information, usage information etc is available at http://wiki.freepascal.org/FPC_JVM Regarding Android: the compiler and the system unit both use a bunch of standard functionality from the JDK to implement various features. So Android support would probably require quite a bit of extra work. I have not looked into that. Enjoy! Is it good idea to write client application work on internet browser? Zaher Dirkey ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On 21 Aug 2011, at 19:05, dmitry boyarintsev wrote: On Sun, Aug 21, 2011 at 3:45 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 21 Aug 2011, at 02:37, dmitry boyarintsev wrote: So there're actually 2 code generators right now. One is used for JVM and another is used for native machine code? The JVM target only uses the high level code generator. The other targets use a combination of both. Are there a plans to merge branches (trunk and jvm branch) together? Yes, once other developers have had the chance to review the jvm branch and comment about it. Other requirements are that there are no regressions for non-JVM targets anymore (although I think I fixed all of those today) and that all new memory leaks are fixed (there are a few in the new symcreat unit). What about changing the native code generator to become more high level as JVM? That doesn't really offer any advantages, so I'm not sure whether it's worth the trouble. Code generation has two parts in the compiler: * all parse tree nodes have a method called pass_generate_code that calls general code generator routines * the code generator returns emit assembler statements In svn trunk, all pass_generate_code routines called the low level code generation routines. In the jvm branch, several of those pass_generate_code routines have been converted to call the high level code generator. For native targets, there is a special high level code generator implementation that generally just calls through to the low level code generator. As long as new implementations of pass_generate_code methods use the high level code generator (which has almost the same interface as the low level code generator, only the size parameters are high level definitions instead of only things like 4 byte unsigned value), and if new code generator methods are added to the high level instead of low level code generator classes, there should be no problem keeping everything in sync without duplicating any work (and without making things harder for anyone). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
On 21 Aug 2011, at 20:39, dmitry boyarintsev wrote: I followed the instruction and again it failed to run the application. However, it's unsaid that location of the .class file should also be listed in -cp option. At least it worked fine for me. I tried it in Windows, so I'm not sure if it's required for Unix OSes, but it appears that working directory isn't used by java for classpath searching. Jonas, I'd suspect you have environment variable CLASSPATH setup in your system or something like that, that doesn't require you specify the path to .class file. No, but my test scripts did have . in the -cp path. In the end, it has nothing to do with ppcvmj, but rather than usage of java application :) I added a small note to Quick Start feel free to delete it anyway. Thanks, I've updated it to use . (that's easier to type). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ARM vs Thumb2 - can't have both
Been playing with the ARM / Thumb2 part - specifically for the Thumb2 line-up. The compiler proper can be built to switch between the two with a command line switch. However, the RTL gets called as ARCH-SYSTEM, this only allows the RTL to compiled for one or the other. This may be by design - in which case there should be a big BOLD note added to the Arm port page. Or it may be unintentional - in which case it should be switched to ARCH-CPU-SYSTEM OR Thumb2 should get rolled out as a separate ARCH. Not sure I will have time to get into changing ARCH, but if there is a [somewhat] easy fix to add CPU to the RTL path for architectures that support it, I may have time to dig into that. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC target: JVM
Graeme Geldenhuys schrieb: Lets see if I understand this correctly. Dalvik was designed to be suitable for systems that are constrained in terms of memory and processor speed. IMO more important is avoiding the US patents on Java. For the curious: the Java patents typically claim Method And Apparatus For ..., where the Apparatus is obviously aimed to outwit the restriction, that most countries do not accept pure software patents. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM vs Thumb2 - can't have both
except for a few older ARM's both platforms support thumb code, so anything that is shared could be compiled for thumb with some target specific trampolines to get there ARM: 0x0: b _pre_start ... _pre_start: ldr r0,_start bx r0 .pool cortex-m3: 0x: _stac_top 0x0004: .word _start .thumb_func _start: limit to thumb instructions (no thumb2) same works for interrupts as well... If everything is written in an thumb interwork fashion then you can jump around from target specific block to target specific block, PASCALMAIN can be arm for the arm target and thumb2 for the cortex-m3 target for example and it all works. BTW if you add .thumb_func .thumb_func .globl _start .text _start: you dont have to do this: .long _start+1 you can do this instead: .long _start at least for gnu as, not sure if this code is targeted at different assemblers. On 08/21/2011 05:58 PM, John Clymer wrote: Been playing with the ARM / Thumb2 part - specifically for the Thumb2 line-up. The compiler proper can be built to switch between the two with a command line switch. However, the RTL gets called as ARCH-SYSTEM, this only allows the RTL to compiled for one or the other. This may be by design - in which case there should be a big BOLD note added to the Arm port page. Or it may be unintentional - in which case it should be switched to ARCH-CPU-SYSTEM OR Thumb2 should get rolled out as a separate ARCH. Not sure I will have time to get into changing ARCH, but if there is a [somewhat] easy fix to add CPU to the RTL path for architectures that support it, I may have time to dig into that. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM vs Thumb2 - can't have both
Yes, I'm somewhat familiar with mixing Thumb and Arm in C. However, I believe the intent is to target FPC for the newbie market (that's what I'm getting from wanting all the hardware peripheral registers installed in the controller unit file...) A newbie is NOT going to have any luck intermixing the two. That also doesn't solve the problem of the SYSTEM unit. As the compiler is laid out now - the system unit sits in a directory of the name ARCH-SYSTEM. So, to support BOTH ARM and THUMB (i.e. Cortex and native ARM7TDMI) SYSTEM files, 2 different builds are needed. However - they can't both sit in the same directory (not with the current setup of Makefiles and code.) I've seen where the compiler inserts the system unit and controller units, so supporting both would only be a few lines of code there. I've also seen when running the compiler in verbose mode (-Va) that the -Cp processor switch is getting defined to a constant - so one could possibly massage the makefiles into supporting ARCH-CPUTYPE-SYSTEM directories to seperate the two system units. Otherwise, one has the following problem: 1) building for ARM - all the controllerunits compile (because the assembler can assemble the thumb startup code into arm startup code). However, when one builds a program with the resulting SYSTEM and controllerunit file, the startup will be in ARM mode and cause the program not to run.) 2) building in THUMB - the ARM startup code in the lpc and sam7 controllerunit files fail to build - as they have ARM specific assembly code in them. However, if you are claiming that an ARM binary can be linked against a THUMB SYSTEM unit, then only the startup code remains to get fixed - and things aren't as messy as I'm perceiving them. John From: David Welch dwe...@dwelch.com To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Mon, August 22, 2011 6:00:29 AM Subject: Re: [fpc-devel] ARM vs Thumb2 - can't have both except for a few older ARM's both platforms support thumb code, so anything that is shared could be compiled for thumb with some target specific trampolines to get there ARM: 0x0: b _pre_start ... _pre_start: ldr r0,_start bx r0 .pool cortex-m3: 0x: _stac_top 0x0004: .word _start .thumb_func _start: limit to thumb instructions (no thumb2) same works for interrupts as well... If everything is written in an thumb interwork fashion then you can jump around from target specific block to target specific block, PASCALMAIN can be arm for the arm target and thumb2 for the cortex-m3 target for example and it all works. BTW if you add .thumb_func .thumb_func .globl _start .text _start: you dont have to do this: .long _start+1 you can do this instead: .long _start at least for gnu as, not sure if this code is targeted at different assemblers. On 08/21/2011 05:58 PM, John Clymer wrote: Been playing with the ARM / Thumb2 part - specifically for the Thumb2 line-up. The compiler proper can be built to switch between the two with a command line switch. However, the RTL gets called as ARCH-SYSTEM, this only allows the RTL to compiled for one or the other. This may be by design - in which case there should be a big BOLD note added to the Arm port page. Or it may be unintentional - in which case it should be switched to ARCH-CPU-SYSTEM OR Thumb2 should get rolled out as a separate ARCH. Not sure I will have time to get into changing ARCH, but if there is a [somewhat] easy fix to add CPU to the RTL path for architectures that support it, I may have time to dig into that. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM vs Thumb2 - can't have both
All I am saying is thumb (not thumb2) is common between many ARM cores and the cortex-m3. These lpc21xx parts use an ARM7TDMI which is an ARMv4T and supports thumb. the lpc2000 are also ARM7TDMI's and LPC1000 is cortex-m0 which is the successor to cortex-m3 so no doubt it is thumb/thumb2 based as well. All of the ARM based microcontrollers I know of (have used) str7, stm32, lpc2000, lpc1000, stellaris, sam7 (at91sam7) support thumb instructions (if you limit yourself to the original ARMv4T supported instructions). the sam9 and str9 both appear to be ARMv5T based so they support thumb as well. So long as all code modules use a thumb interwork as folks like to call it interface, then dules like PASCALMAIN can be compiled for arm, thumb or thumb2 and be called and return to arm, thumb or thumb2 code, mix and match at will. Obviously the exception table or vector table at address zero has to be different for ARM7 vs cortex-m, no way to work around that. If that is the root of the problem and that code wants to move out of the target specific rtl (stellaris.pp, lpc21x4.pp, etc) then, yeah, there is a big problem. If the exception and vector tables can be custom to the target as they are now (stellaris.pp, lpc21x4.pp, etc) then you could do a couple of things. One would be the interwork thing. The arm startup code, within the target specific rtl would have to do a two step to get from arm mode to thumb/interwork mode. The arm cores traditionally handles exceptions in arm mode. What I described in the prior email but not necessarily exactly like that. Any shared code between the ARM and cortex-m would be strictly thumb (limited to ARMv4T ideally). Any instructions like mrs/msr that thumb is lacking would want to be calls to arm code in the target specific startup area. The cortex-m vector table could simply point directly at the thumb mode shared code (and have matching named functions for mrs/msr and other instructions) The second solution, would be to use the lowest common denominator, everything except the exception/vector tables, and some architecture specific stuff (like any need for mrs/msr calls) be compiled for thumb (limited to ARMv4T). Unfortunately there is no thumb backend. With the second solution the compiler could be compiled one time, one way and so far all the targets are supported by that one compiler. I guess a third solution would be to treat the cortex-m3 as a completely different architecture, in the same way that the avr is a separate target (looks like there is at least a directory for the avr, but the code is arm so a work in progress). I would be super happy to see an msp430 target in there as well but that is another story. From what you were talking about ARCHSYSTEM becoming ARCHCPUTYPESYSTEM, cortex-m could be a separate ARCH instead of being part of the ARM architecture and ARCHSYSTEM would work. Sorry for being dense, I am a newbie here so dont know enough about the detail to know where the problem is. I still have not gotten past the problem I had trying to get that startup code to build right for the cortex-m3. Lots of arm experience, almost no fpc experience. I assume what you are calling a thumb system is the cortex-m3 based systems, you you cannot have arm code there. I assume the ARCH is for now ARM (the company not the instruction set). And SYSTEM is either ARM (the instruction set) or thumb2/cortex-m3? Am I understanding that so far? Or is ARCH ARM or cortex-m3 and SYSTEM is stellaris, lpc21x4, etc? David On 08/21/2011 10:36 PM, John Clymer wrote: Yes, I'm somewhat familiar with mixing Thumb and Arm in C. However, I believe the intent is to target FPC for the newbie market (that's what I'm getting from wanting all the hardware peripheral registers installed in the controller unit file...) A newbie is NOT going to have any luck intermixing the two. That also doesn't solve the problem of the SYSTEM unit. As the compiler is laid out now - the system unit sits in a directory of the name ARCH-SYSTEM. So, to support BOTH ARM and THUMB (i.e. Cortex and native ARM7TDMI) SYSTEM files, 2 different builds are needed. However - they can't both sit in the same directory (not with the current setup of Makefiles and code.) I've seen where the compiler inserts the system unit and controller units, so supporting both would only be a few lines of code there. I've also seen when running the compiler in verbose mode (-Va) that the -Cp processor switch is getting defined to a constant - so one could possibly massage the makefiles into supporting ARCH-CPUTYPE-SYSTEM directories to seperate the two system units. Otherwise, one has the following problem: 1) building for ARM - all the controllerunits compile (because the assembler can assemble the thumb startup code into arm startup code). However, when one builds a program with the resulting SYSTEM and controllerunit file, the startup will be in ARM mode
Re: [fpc-devel] ARM vs Thumb2 - can't have both
Yes, all my references of Thumb meant Thumb2. The problem is not building the compiler - the compiler works correctly supporting Thumb2 and ARM. The problems is building the libraries. Doing a standard build process, the compile chain gets into the rtl/embedded folder. It makes one pass through and compiles the SYSTEM unit. This gets built in whatever mode the crosscompiler has been told to be in. It defaults to ARM code, unless told to Thumb2 code (via a CROSSOPT=-Cpcortexm3 on the MAKE command line - or via an override in the RTL.CFG file in the embedded folder.) Now, if it's in Thumb2 mode - it compiles the STM32 and STELLARIS unit files fine, and makes a Thumb2 SYSTEM ppu. But, then it chokes on compiling the ARM controller unit files. BUT - if it's in ARM mode, it will compile everything, including the start-up routines for the Thumb2 parts - in full blown ARM mode. This will make the compiler finish it's job. BUT attempting to run anything on a M3 device will fail - as the M3 can NOT run ARM code. So, in order to get a working setup for an M3 device, one needs to manually remove the ARM controller files from the makefile, then re-build with -Cpcortexm3 in the RTL.CFG file in the embedded folder (or it could be added to the Makefile) - OR the make clean buildbase installbase line needs to have a CROSSOPT=-Cpcortexm3 added. Otherwise the system and startup files end up being ARM files. ARCH is ARM - but that is NOT the code generation, that is strictly because the company's name is ARM. SYSTEM is embedded - as that's what I'm building CPUTYPE (not referenced in any build files) is either ARM (for ARMV3-V5) OR Thumb2 (for Cortex M3 OR armv7m) Again, the compiler builds just fine - it's the RTL that has the issue. If you are having troubles building for Cortex, the magic that I'm using to make it work is: make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm CROSSBINDIR=/home/stimey/CodeSourcery/bin BINUTILSPREFIX=arm-none-eabi- CROSSOPT=-Cpcortexm3 INSTALL_PREFIX=/home/stimey/fpc The CROSSOPT item forces the RTL to be compiled as M3 / Thumb2. John From: David Welch dwe...@dwelch.com To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Mon, August 22, 2011 8:25:11 AM Subject: Re: [fpc-devel] ARM vs Thumb2 - can't have both All I am saying is thumb (not thumb2) is common between many ARM cores and the cortex-m3. These lpc21xx parts use an ARM7TDMI which is an ARMv4T and supports thumb. the lpc2000 are also ARM7TDMI's and LPC1000 is cortex-m0 which is the successor to cortex-m3 so no doubt it is thumb/thumb2 based as well. All of the ARM based microcontrollers I know of (have used) str7, stm32, lpc2000, lpc1000, stellaris, sam7 (at91sam7) support thumb instructions (if you limit yourself to the original ARMv4T supported instructions). the sam9 and str9 both appear to be ARMv5T based so they support thumb as well. So long as all code modules use a thumb interwork as folks like to call it interface, then dules like PASCALMAIN can be compiled for arm, thumb or thumb2 and be called and return to arm, thumb or thumb2 code, mix and match at will. Obviously the exception table or vector table at address zero has to be different for ARM7 vs cortex-m, no way to work around that. If that is the root of the problem and that code wants to move out of the target specific rtl (stellaris.pp, lpc21x4.pp, etc) then, yeah, there is a big problem. If the exception and vector tables can be custom to the target as they are now (stellaris.pp, lpc21x4.pp, etc) then you could do a couple of things. One would be the interwork thing. The arm startup code, within the target specific rtl would have to do a two step to get from arm mode to thumb/interwork mode. The arm cores traditionally handles exceptions in arm mode. What I described in the prior email but not necessarily exactly like that. Any shared code between the ARM and cortex-m would be strictly thumb (limited to ARMv4T ideally). Any instructions like mrs/msr that thumb is lacking would want to be calls to arm code in the target specific startup area. The cortex-m vector table could simply point directly at the thumb mode shared code (and have matching named functions for mrs/msr and other instructions) The second solution, would be to use the lowest common denominator, everything except the exception/vector tables, and some architecture specific stuff (like any need for mrs/msr calls) be compiled for thumb (limited to ARMv4T). Unfortunately there is no thumb backend. With the second solution the compiler could be compiled one time, one way and so far all the targets are supported by that one compiler. I guess a third solution would be to treat the cortex-m3 as a completely different architecture, in the same way that the avr is a separate target (looks like there is at least a directory for the avr, but
