date:20110820

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Alex Shishkin


21.08.2011 7:03, Paul Ishenin пишет:

21.08.2011 6:28, Jonas Maebe wrote:
To make sure that credit is given where credit is due: I want to 
especially thank Paul Ishenin for his work on implementing 
Delphi-style "advanced records" and extending the class support with 
nested classes, class constants, final classes etc, because without 
him I would have had to implement all of that myself for this port :) 
And Florian/Peter for the code generator design, that made it 
possible to gradually add a high level code generator on top of it 
rather than having to completely rewrite it.
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.


Best regards,
Paul Ishenin


It`s a time to unblock it, I think.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Paul Ishenin


21.08.2011 6:28, Jonas Maebe wrote:
To make sure that credit is given where credit is due: I want to 
especially thank Paul Ishenin for his work on implementing 
Delphi-style "advanced records" and extending the class support with 
nested classes, class constants, final classes etc, because without 
him I would have had to implement all of that myself for this port :) 
And Florian/Peter for the code generator design, that made it possible 
to gradually add a high level code generator on top of it rather than 
having to completely rewrite it.
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.


Best 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

2011-08-20 Thread Hans-Peter Diettrich


Joost van der Sluis schrieb:

On Sun, 2011-08-21 at 00:11 +0200, Hans-Peter Diettrich wrote:
A .NET or Dalvik backend is feasable as easy as a JVM backend. Question 
is the use of such an code generator, without an RTL, FCL, debugger etc.


As 'easy'?


'As' easy!

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread dmitry boyarintsev

On Sat, Aug 20, 2011 at 6:28 PM, Jonas Maebe  wrote:
> And Florian/Peter for the code generator design, that made it possible to 
> gradually add a high level code generator on top of it rather than having to 
> completely rewrite it.

So there're actually 2 code generators right now. One is used for JVM
and another is used for native machine code?

thanks,
Dmitry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] ARM patch to switch to controller records rather than arrays

2011-08-20 Thread 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.

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.

4) t_embed.pas was changed.  The case() statement is still in there, but  all 
the cases fall down to the same code - which uses the cpuinfo.pas  memory 
definitions to create the linker file.

5) put a test in t_embed.pas - if we are only compiling to assembly,  then we 
skip the Internal Error on not having a link definition.

6) option.pas, globals.pas, ncgutil.pas and pmodules.pas were modified to 
accommodate the addition of the structure.

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)

NOTE:  The Makefile changes were picked up by svn diff - not sure why  they 
changed so much, my incantation of fpcmake must be different than  the original 
sources code

NOTE:  The AVR link script generation has not been changed to  accommodate the 
additional information - the original link script did  not set memory sizes to 
match the processor.

JohnIndex: rtl/embedded/Makefile.fpc
===
--- rtl/embedded/Makefile.fpc   (revision 18278)
+++ rtl/embedded/Makefile.fpc   (working copy)
@@ -48,7 +48,7 @@
 SYSINIT_UNITS=
 
 ifeq ($(ARCH),arm)
-CPU_UNITS=lpc21x4 at91sam7x256 stellaris stm32f103
+CPU_UNITS=lpc21x4 at91sam7x256 stellaris stm32f103 lm3fury
 endif
 
 ifeq ($(ARCH),avr)
Index: rtl/embedded/Makefile
===
--- rtl/embedded/Makefile   (revision 18278)
+++ rtl/embedded/Makefile   (working copy)
@@ -1,8 +1,8 @@
 #
-# Don't edit, this file is generated by FPCMake Version 2.0.0 [2011/08/11]
+# Don't edit, this file is generated by FPCMake Version 2.0.0 [2011/04/23]
 #
 default: all
-MAKEFILETARGETS=i386-linux i386-go32v2 i386-win32 i386-os2 i386-freebsd 
i386-beos i386-haiku i386-netbsd i386-solaris i386-qnx i386-netware 
i386-openbsd i386-wdosx i386-darwin i386-emx i386-watcom i386-netwlibc 
i386-wince i386-embedded i386-symbian i386-nativent i386-iphonesim m68k-linux 
m68k-freebsd m68k-netbsd m68k-amiga m68k-atari m68k-openbsd m68k-palmos 
m68k-embedded powerpc-linux powerpc-netbsd powerpc-amiga powerpc-macos 
powerpc-darwin powerpc-morphos powerpc-embedded powerpc-wii sparc-linux 
sparc-netbsd sparc-solaris sparc-embedded x86_64-linux x86_64-freebsd 
x86_64-solaris x86_64-darwin x86_64-win64 x86_64-embedded arm-linux arm-palmos 
arm-darwin arm-wince arm-gba arm-nds arm-embedded arm-symbian powerpc64-linux 
powerpc64-darwin powerpc64-embedded avr-embedded armeb-linux armeb-embedded 
mipsel-linux
+MAKEFILETARGETS=i386-linux i386-go32v2 i386-win32 i386-os2 i386-freebsd 
i386-beos i386-haiku i386-netbsd i386-solaris i386-qnx i386-netware 
i386-openbsd i386-wdosx i386-darwin i386-emx i386-watcom i386-netwlibc 
i386-wince i386-embedded i386-symbian m68k-linux m68k-freebsd m68k-netbsd 
m68k-amiga m68k-atari m68k-openbsd m68k-palmos m68k-embedded powerpc-linux 
powerpc-netbsd powerpc-amiga powerpc-macos powerpc-darwin powerpc-morphos 
powerpc-embedded sparc-linux sparc-netbsd sparc-solaris sparc-embedded 
x86_64-linux x86_64-freebsd x86_64-solaris x86_64-darwin x86_64-win64 
x86_64-embedded arm-linux arm-palmos arm-darwin arm-wince arm-gba arm-nds 
arm-embedded arm-symbian powerpc64-linux powerpc64-darwin powerpc64-embedded 
avr-embedded armeb-linux armeb-embedded mipsel-linux
 BSDs = freebsd netbsd openbsd darwin
 UNIXs = linux $(BSDs) solaris qnx haiku
 LIMIT83fs = go32v2 os2 emx watcom
@@ -189,11 +189,7 @@
 TARGETSUFFIX=$(OS_TARGET)
 SOURCESUFFIX=$(OS_SOURCE)
 else
-ifneq ($(findstring $(OS_TARGET),$(LIMIT83fs)),)
-TARGETSUFFIX=$(OS_TARGET)
-else
 TARGETSUFFIX=$(FULL_TARGET)
-endif
 SOURCESUFFIX=$(FULL_SOURCE)
 endif
 if

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Jonas Maebe

On 21 Aug 2011, at 00:02, Joost van der Sluis wrote:

> On Sun, 2011-08-21 at 00:11 +0200, Hans-Peter Diettrich wrote:
>> A .NET or Dalvik backend is feasable as easy as a JVM backend. Question 
>> is the use of such an code generator, without an RTL, FCL, debugger etc.

Debuggers exist (any debugger that can deal with Java byte code should work). 
It's true that the usefulness will largely depend on people interested in 
fleshing out the RTL, and possibly also an FCL. A lot of functionality can be 
replicated by wrapping JDK classes though.

> I think you could
> expressed yourself differently without the unmentioned negative tone.

No harm done.

> I'm really happy with Jonas hard work on this target, and want to thank
> him for all this (and other) work he did and does for fpc.

To make sure that credit is given where credit is due: I want to especially 
thank Paul Ishenin for his work on implementing Delphi-style "advanced records" 
and extending the class support with nested classes, class constants, final 
classes etc, because without him I would have had to implement all of that 
myself for this port :) And Florian/Peter for the code generator design, that 
made it possible to gradually add a high level code generator on top of it 
rather than having to completely rewrite it.

Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Joost van der Sluis

On Sun, 2011-08-21 at 00:11 +0200, Hans-Peter Diettrich wrote:
> A .NET or Dalvik backend is feasable as easy as a JVM backend. Question 
> is the use of such an code generator, without an RTL, FCL, debugger etc.

As 'easy'? Do you have any idea how much work Jonas, one of the most
experienced developers who are working on fpc, has done to accomplish
this?

I've seen a lot of mails on this mailing list about all sort of
features, including a JVM target. But no-one who actually started to
work seriously on it.

I know that you did not mean to degrade Jonas' work with this comment.
But please think about that before you send emails. I think you could
expressed yourself differently without the unmentioned negative tone.

I'm really happy with Jonas hard work on this target, and want to thank
him for all this (and other) work he did and does for fpc.

-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

2011-08-20 Thread David Welch



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?


If I remove the offending fpc/2.7.1 directory and rebuild. (without 
trying to change the prefix)  it puts the same stuff back in that directory:


/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


Am I doing this wrong?

make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded 
CPU_TARGET=arm


If I change it to this?

make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded 
CPU_TARGET=cortexm3


and provide the necessary cortexm3-embedded-* tools.

make: -iVSPTPSOTO: Command not found
make: -iSP: Command not found
make: -iTP: Command not found
make: -iSO: Command not found
make: -iTO: Command not found
Makefile:203: *** The Makefile doesn't support target cortexm3-embedded, 
please run fpcmake first.  Stop.


Thanks,
David





"/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/" is unsafe for
cross-compilation




The problem is that you are using an RTL built for ARM. That's what the
warning is about. You installed the compiler in /fpcarm, but it's using
units from /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/

A correctly compiled unit would look like this:
 :
0: f8df 1034 ldr.w r1, [pc, #52] ; 38 
4: 4a0d ldr r2, [pc, #52] ; (3c )
6: 4b0e ldr r3, [pc, #56] ; (40 )
8: 429a cmp r2, r3
a: bf9e ittt ls


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Jonas Maebe


On 20 Aug 2011, at 22:07, Jonas Maebe wrote:

> No, I have not created any gui test programs.

There's also the problem mentioned at 
http://wiki.freepascal.org/FPC_JVM/Language#Using_JDK_functionality :

"The javapp utility cannot handle circular references involving nested classes, 
because they cannot be expressed in Pascal. There is one such circular 
reference in the standard JDK, between java.awt.Window and java.awt.Dialog. 
This is currently worked around declaring java.awt.Dialog as a formal class, 
which means that none of its methods, fields or nested classes are available."

Dialogs are generally fairly common in GUI programs...

The problem is that the following circular dependency: java.awt.Dialog is a 
subclass of java.awt.Window and hence java.awt.Window has to be declared first. 
However, java.awt.Window has a field (modalExclusionType) whose type is 
java.awt.Dialog.ModalExclusionType (i.e., a nested class of java.awt.Dialog, so 
java.awt.Dialog has to be declared first).

Normally, issues of this second kind are resolved by creating a forward 
declaration of the involed class (type JADialog.ModalExclusionType = class;), 
but you can't do that for nested classes outside their enclosing class. I could 
extend the javapp utility to enable specifying also nested classes as formal 
classes so that you'd only lose the definition for 
java.awt.Dialog.ModalExclusionType rather than for all of java.awt.Dialog, but 
that still would only partially work around the basic problem.


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Hans-Peter Diettrich


Mattias Gaertner schrieb:


A jvm backend for fpc is great. I hope it is not too much work to
maintain.


A .NET or Dalvik backend is feasable as easy as a JVM backend. Question 
is the use of such an code generator, without an RTL, FCL, debugger etc.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

2011-08-20 Thread Jeppe Græsdal Johansen


Den 20-08-2011 22:24, David Welch skrev:


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 d<>0 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 :
 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 
 80001a4:e004  b.n80001b0 
 80001a6:bf00  nop
 80001a8:f44f 3000 mov.wr0, #131072; 0x2
 80001ac:f7ff ffd8 bl8000160 
 80001b0:e7fa  b.n80001a8 
 80001b2:f000 f8ff bl80003b4 
 80001b6:46dd  movsp, fp
 80001b8:b001  addsp, #4
 80001ba:e91d 8800 ldmdbsp, {fp, pc}
 80001be:bf00  nop
...
08000404 :
 8000404:e59f103c ldrr1, [pc, #60]; 8000448 

 8000408:e59f203c ldrr2, [pc, #60]; 800044c 

 800040c:e59f303c ldrr3, [pc, #60]; 8000450 


 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 
instructions.

It implies thumb mode, which is the only valid mode on Cortex-M3

Looking at that first instruction in the reset handler

08000404 :
 8000404:e59f103c ldrr1, [pc, #60]; 8000448 

The problem is that you are using an RTL built for ARM. That's what the 
warning is about. You installed the compiler in /fpcarm, but it's using 
units from /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/


A correctly compiled unit would look like this:
 :
   0:   f8df 1034   ldr.w   r1, [pc, #52]   ; 38 

   4:   4a0dldr r2, [pc, #52]   ; (3c 
)
   6:   4b0eldr r3, [pc, #56]   ; (40 
)

   8:   429acmp r2, r3
   a:   bf9eitttls

   IPUBWL
1110 01011001 r15, r1, 0x03C

And that was properly decoded by objdump, immediate offset 
rn+offset12, load, word sized, etc.
PC is 0x800040C at that time so load address is 0x800040C+0x03C = 
0x8000448


You can tell both by 32 bit numbers in the dump but the dominance of 
an 0xE as the first nibble also implies these are arm instructions not 
thumb (need to see a long chunk of code to see the pattern).  Had they 
been thumb instructions but decoded wrong by the disassembler then the 
first and fourth nibbles would have been dominated by like 6's and 7's 
or at least would stand out compared to the other

nibbles.

if we decode this as thumb/thumb2

0xE59F

//B(2) unconditional branch
if((inst&0xF800)==0xE000)
{
rb=(inst>>0)&0x7FF;
if(rb&(1<<10)) rb|=(~0)<<11;
rb<<=1;
rb+=pc;
rb+=2;
write_register(15,rb);
return(0);
}

111001011001

11100 1011001

...111011001
...1110110010
...11  1011 0011 1110

pc = 0x405+4 = 0x409
pc + 0x...FFB3E =
0x409 - (0x4C1 + 1) =  0x747

Unconditional branch to 0x0747  so it is a valid instruction, but 
doesnt make much sense



This does though, the start code from stm32f103.pp

.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 .Lco

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Nikolai Zhubr


Hi,
20.08.2011 12:49, Jonas Maebe:

Hi,

There is a new branch in svn (branches/jvmbackend) that contains support for 
compiling Pascal code into Java virtual machine bytecode.


This is really amazing, even if functionality is somewhat limited at the 
moment.


Thanks for the great work!


Nikolai
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Nikolai Zhubr


20.08.2011 19:02, Graeme Geldenhuys:

On 20 August 2011 13:30, Felipe Monteiro de Carvalho wrote:


I ask because Android does not use Java Bytecode, it has it's own,
completely different bytecode.


Why did Google do that? Why not stay with the standardized Java and
get the benefits of all existing Java and Mobile Java apps?


IIRC Google was unhappy with java's licensing and/or management and did 
not happen to arrange it all with Sun in peacefull and mutually 
acceptable manner so they (Google) then opted to step away and create a 
separate new product formally unrelated of java and not bearing Sun's 
copyrights (which still didn't prevent subsequent patent harassment from 
Oracle however)


Now, regarding mobile java, you might notice that while you still can do 
a checkout at svn.java.net/svn/phoneme~svn (and it will still mostly 
work), the project looks and feels like essentially abandoned (no 
bugfixes/cleanups around, links bringing you to 404 pages etc etc) Of 
course there might be some development going on at Oracle internally, 
but there is no visible sign of it AFAICS.



Nikolai
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

2011-08-20 Thread David Welch



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 d<>0 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:   2000fffcstrdcs  pc, [r0], -ip
 804:   08000405stmdaeq r0, {r0, r2, sl}
 808:   08000405stmdaeq r0, {r0, r2, sl}
 80c:   08000405stmdaeq r0, {r0, r2, sl}
 810:   08000405stmdaeq r0, {r0, r2, sl}
 814:   08000405stmdaeq r0, {r0, r2, sl}
 818:   08000405stmdaeq r0, {r0, r2, sl}
...
08000194 :
 8000194:   46ecmov ip, sp
 8000196:   e92d 4800   stmdb   sp!, {fp, lr}
 800019a:   f1ac 0b04   sub.w   fp, ip, #4
 800019e:   b08asub sp, #40 ; 0x28
 80001a0:   f000 f844   bl  800022c 
 80001a4:   e004b.n 80001b0 
 80001a6:   bf00nop
 80001a8:   f44f 3000   mov.w   r0, #131072 ; 0x2
 80001ac:   f7ff ffd8   bl  8000160 
 80001b0:   e7fab.n 80001a8 
 80001b2:   f000 f8ff   bl  80003b4 
 80001b6:   46ddmov sp, fp
 80001b8:   b001add sp, #4
 80001ba:   e91d 8800   ldmdb   sp, {fp, pc}
 80001be:   bf00nop
...
08000404 :
 8000404:   e59f103cldr r1, [pc, #60]   ; 8000448 

 8000408:   e59f203cldr r2, [pc, #60]   ; 800044c 

 800040c:   e59f303cldr r3, [pc, #60]   ; 8000450 

 8000410:   e1520003cmp r2, r3
 8000414:   94910004ldrls   r0, [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 
instructions.


Looking at that first instruction in the reset handler

08000404 :
 8000404:   e59f103cldr r1, [pc, #60]   ; 8000448 


   IPUBWL
1110 01011001 r15, r1, 0x03C

And that was properly decoded by objdump, immediate offset rn+offset12, 
load, word sized, etc.

PC is 0x800040C at that time so load address is 0x800040C+0x03C = 0x8000448

You can tell both by 32 bit numbers in the dump but the dominance of an 
0xE as the first nibble also implies these are arm instructions not 
thumb (need to see a long chunk of code to see the pattern).  Had they 
been thumb instructions but decoded wrong by the disassembler then the 
first and fourth nibbles would have been dominated by like 6's and 7's 
or at least would stand out compared to the other

nibbles.

if we decode this as thumb/thumb2

0xE59F

//B(2) unconditional branch
if((inst&0xF800)==0xE000)
{
rb=(inst>>0)&0x7FF;
if(rb&(1<<10)) rb|=(~0)<<11;
rb<<=1;
rb+=pc;
rb+=2;
write_register(15,rb);
return(0);
}

111001011001

11100 1011001

...111011001
...1110110010
...11  1011 0011 1110

pc = 0x405+4 = 0x409
pc + 0x...FFB3E =
0x409 - (0x4C1 + 1) =  0x747

Unconditional branch to 0x0747  so it is a valid instruction, but 
doesnt make much sense



This does though, the start code from stm32f103.pp

.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

The instructions the assembler was able to encode it did:

 8000404:   e59f103cldr r1, [pc, #60]
 8000408:   e59f203cldr r2, [pc, #60]
 800040c:   e59f303cldr r3, [pc, #60]
 8000410:   e1520003cmp r2, r3
 8000414:   94910004ldrls   r0, [r1], #4

 8000448:   08000468stmdaeq r0, {r3, r5, r6, sl}
 800044c:   2000an

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Jonas Maebe


On 20 Aug 2011, at 21:40, Max Vlasov wrote:

> Great new indeed! Just curious, is there an example program in pascal for
> jvm that can be compiled and seen in action? I checked out tests, but
> looking at random ones, they looks like console mode ones testing different
> rtl aspects. I'm talking about maybe a simplest one for example drawing a
> rectangle at the center of the window.

No, I have not created any gui test programs.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Max Vlasov

On Sat, Aug 20, 2011 at 12:49 PM, Jonas Maebe wrote:

>
> 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.
>
>

Great new indeed! Just curious, is there an example program in pascal for
jvm that can be compiled and seen in action? I checked out tests, but
looking at random ones, they looks like console mode ones testing different
rtl aspects. I'm talking about maybe a simplest one for example drawing a
rectangle at the center of the window.

Max
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

2011-08-20 Thread David Welch



I am rapidly seeing the problem, the linker script is hardcoded both by 
family (ARM as a whole) and by target.  So for example if you wanted a 
ram-only ARM generic target, you are in trouble, or if you wanted a 
flash/ram target arm generic target you are in trouble.  You have to 
override the compiled in maps.  Once you get target specific compiled in 
memory maps then the compiled in register addresses make sense.  At that 
point do the libraries, pll init, timers, etc make sense?


David


On 08/20/2011 11:57 AM, DaWorm wrote:

I'm not sure how FPC should handle the peripherals, but I don't think it
should be at the compiler level.  Even if the part I'm using has, for
instance, an ADC, if I'm not using it I do not want support for it built
in to my app.  With what I use currently (IAR C) I uncomment a #define
for each peripheral I want to add support for.  I'm sure something
similar can be done for FPC at the unit level.



___
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

2011-08-20 Thread David Welch



right, when I build for stellaris or stm32f103re I get the cortex-m like 
vector table that uses arm 32 bit instruction startup code that branches 
to a pascalmain that is thumb2.  something that wont execute on 
hardware.  Had it been a thumb target with a traditional exeception 
table that would have been good and in fact desirable for some platforms 
(nintendo gba for example).  but the arm/thumb2 combination doesnt mix 
very well.


Maybe I need to re-try everything from scratch to see if I skipped a 
step or left out something and specified the wrong target or cpu.


Note you are giving up a stack location by using addresses in the form 
0x10007FFC instead of 0x10008000.  Minor point but it stands out in the 
binary.


This is all clearly a work in progress, I understand that...

David

On 08/20/2011 11:49 AM, John Clymer wrote:

The thumb2 is meant to support Cortex M3 devices (STM32, Stellaris,
etc.) AFAIK - the mixing of modes is not currently an option.



*From:* Jeppe Græsdal Johansen 
*To:* FPC developers' list 
*Sent:* Sat, August 20, 2011 7:23:39 PM
*Subject:* Re: [fpc-devel] Arm Thumb2 - Stellaris status

Den 20-08-2011 16:46, David Welch skrev:
 > 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.
Why thumb support? The choices are indeed currently only either ARM or
Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length
instruction set that looks like an arm+thumb mix, so I guarantee you
that it works :)
___
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

2011-08-20 Thread DaWorm

I'm not sure how FPC should handle the peripherals, but I don't think it
should be at the compiler level.  Even if the part I'm using has, for
instance, an ADC, if I'm not using it I do not want support for it built in
to my app.  With what I use currently (IAR C) I uncomment a #define for each
peripheral I want to add support for.  I'm sure something similar can be
done for FPC at the unit level.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Mattias Gaertner

On Sat, 20 Aug 2011 17:02:17 +0200
Graeme Geldenhuys  wrote:

> On 20 August 2011 13:30, Felipe Monteiro de Carvalho wrote:
> >
> > I ask because Android does not use Java Bytecode, it has it's own,
> > completely different bytecode.
> 
> Why did Google do that?

Why don't you google yourself?

http://lmgtfy.com/?q=android+byte+code

> Why not stay with the standardized Java and
> get the benefits of all existing Java and Mobile Java apps?

What benefits do you miss?

> Sometimes these software vendors can be really brain dead!

Let's summarize. You

1. do not understand something
2. ask this list
3. do not wait for the answer
4. call it "brain dead"

That is not very clever, is it?
I guess some people would call this "brain dead".

> They just
> love proprietary or incompatible stuff. Java was designed to be
> compatible on all platforms, now Android calls it "java", but it's not
> compatible with Sun/Oracle's Java. This sounds just like what
> Microsoft did years ago - luckily Sun put a stop to that.
> 
> I don't know much about Android, but just when I thought it sounded
> great, I hear things like this. :-(

Java is just a language. Normally you need the jdk and
some third party libs. And here you got the x-platform problems. I
know some projects that had too many problems porting their
java projects and switched to fpc.

A jvm backend for fpc is great. I hope it is not too much work to
maintain.

Mattias
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

2011-08-20 Thread John Clymer

The thumb2 is meant to support Cortex M3 devices (STM32, Stellaris, etc.)  
AFAIK 
- the mixing of modes is not currently an option.






From: Jeppe Græsdal Johansen 
To: FPC developers' list 
Sent: Sat, August 20, 2011 7:23:39 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status

Den 20-08-2011 16:46, David Welch skrev:
> 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. 
>
Why thumb support? The choices are indeed currently only either ARM or 
Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length 
instruction set that looks like an arm+thumb mix, so I guarantee you that it 
works :)
___
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] (no subject)

2011-08-20 Thread 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.

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.

4) t_embed.pas was changed.  The case() statement is still in there, but  all 
the cases fall down to the same code - which uses the cpuinfo.pas  memory 
definitions to create the linker file.

5) put a test in t_embed.pas - if we are only compiling to assembly,  then we 
skip the Internal Error on not having a link definition.

6) option.pas, globals.pas, ncgutil.pas and pmodules.pas were modified to 
accommodate the addition of the structure.

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)

NOTE:  The Makefile changes were picked up by svn diff - not sure why  they 
changed so much, my incantation of fpcmake must be different than  the original 
sources code

NOTE:  The AVR link script generation has not been changed to  accommodate the 
additional information - the original link script did  not set memory sizes to 
match the processor.

JohnIndex: rtl/embedded/Makefile.fpc
===
--- rtl/embedded/Makefile.fpc   (revision 18278)
+++ rtl/embedded/Makefile.fpc   (working copy)
@@ -48,7 +48,7 @@
 SYSINIT_UNITS=
 
 ifeq ($(ARCH),arm)
-CPU_UNITS=lpc21x4 at91sam7x256 stellaris stm32f103
+CPU_UNITS=lpc21x4 at91sam7x256 stellaris stm32f103 lm3fury
 endif
 
 ifeq ($(ARCH),avr)
Index: rtl/embedded/Makefile
===
--- rtl/embedded/Makefile   (revision 18278)
+++ rtl/embedded/Makefile   (working copy)
@@ -1,8 +1,8 @@
 #
-# Don't edit, this file is generated by FPCMake Version 2.0.0 [2011/08/11]
+# Don't edit, this file is generated by FPCMake Version 2.0.0 [2011/04/23]
 #
 default: all
-MAKEFILETARGETS=i386-linux i386-go32v2 i386-win32 i386-os2 i386-freebsd 
i386-beos i386-haiku i386-netbsd i386-solaris i386-qnx i386-netware 
i386-openbsd i386-wdosx i386-darwin i386-emx i386-watcom i386-netwlibc 
i386-wince i386-embedded i386-symbian i386-nativent i386-iphonesim m68k-linux 
m68k-freebsd m68k-netbsd m68k-amiga m68k-atari m68k-openbsd m68k-palmos 
m68k-embedded powerpc-linux powerpc-netbsd powerpc-amiga powerpc-macos 
powerpc-darwin powerpc-morphos powerpc-embedded powerpc-wii sparc-linux 
sparc-netbsd sparc-solaris sparc-embedded x86_64-linux x86_64-freebsd 
x86_64-solaris x86_64-darwin x86_64-win64 x86_64-embedded arm-linux arm-palmos 
arm-darwin arm-wince arm-gba arm-nds arm-embedded arm-symbian powerpc64-linux 
powerpc64-darwin powerpc64-embedded avr-embedded armeb-linux armeb-embedded 
mipsel-linux
+MAKEFILETARGETS=i386-linux i386-go32v2 i386-win32 i386-os2 i386-freebsd 
i386-beos i386-haiku i386-netbsd i386-solaris i386-qnx i386-netware 
i386-openbsd i386-wdosx i386-darwin i386-emx i386-watcom i386-netwlibc 
i386-wince i386-embedded i386-symbian m68k-linux m68k-freebsd m68k-netbsd 
m68k-amiga m68k-atari m68k-openbsd m68k-palmos m68k-embedded powerpc-linux 
powerpc-netbsd powerpc-amiga powerpc-macos powerpc-darwin powerpc-morphos 
powerpc-embedded sparc-linux sparc-netbsd sparc-solaris sparc-embedded 
x86_64-linux x86_64-freebsd x86_64-solaris x86_64-darwin x86_64-win64 
x86_64-embedded arm-linux arm-palmos arm-darwin arm-wince arm-gba arm-nds 
arm-embedded arm-symbian powerpc64-linux powerpc64-darwin powerpc64-embedded 
avr-embedded armeb-linux armeb-embedded mipsel-linux
 BSDs = freebsd netbsd openbsd darwin
 UNIXs = linux $(BSDs) solaris qnx haiku
 LIMIT83fs = go32v2 os2 emx watcom
@@ -189,11 +189,7 @@
 TARGETSUFFIX=$(OS_TARGET)
 SOURCESUFFIX=$(OS_SOURCE)
 else
-ifneq ($(findstring $(OS_TARGET),$(LIMIT83fs)),)
-TARGETSUFFIX=$(OS_TARGET)
-else
 TARGETSUFFIX=$(FULL_TARGET)
-endif
 SOURCESUFFIX=$(FULL_SOURCE)
 endif
 ifn

Re: [fpc-devel] Arm Thumb2 - Stellaris status

2011-08-20 Thread Jeppe Græsdal Johansen


Den 20-08-2011 16:46, David Welch skrev:
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. 
Why thumb support? The choices are indeed currently only either ARM or 
Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length 
instruction set that looks like an arm+thumb mix, so I guarantee you 
that it works :)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

2011-08-20 Thread David Welch




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.


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.


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.


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 understand this is a work in progress and sorting everything out will 
take some time.


David

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Graeme Geldenhuys

On 20 August 2011 13:30, Felipe Monteiro de Carvalho wrote:
>
> I ask because Android does not use Java Bytecode, it has it's own,
> completely different bytecode.

Why did Google do that? Why not stay with the standardized Java and
get the benefits of all existing Java and Mobile Java apps?

Sometimes these software vendors can be really brain dead! They just
love proprietary or incompatible stuff. Java was designed to be
compatible on all platforms, now Android calls it "java", but it's not
compatible with Sun/Oracle's Java. This sounds just like what
Microsoft did years ago - luckily Sun put a stop to that.

I don't know much about Android, but just when I thought it sounded
great, I hear things like this. :-(

-- 
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

2011-08-20 Thread Alex Shishkin




I thought it was possible to convert Java class files into Dalvik class files?


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


AFAIK android SDK works just so. It converts lava`s .class files to 
dalvik .dex with "dx" utility.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Jonas Maebe

On 20 Aug 2011, at 13:30, Felipe Monteiro de Carvalho wrote:

> Does this port generate Java Bytecode directly or does it generate
> first Java Assembler and then feeds that into an internal assembler?

It generates Java assembler and then feeds it into an external assembler 
(Jasmin).

> I ask because Android does not use Java Bytecode, it has it's own,
> completely different bytecode.

I thought it was possible to convert Java class files into Dalvik class files?

Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] New FPC target: JVM

2011-08-20 Thread Felipe Monteiro de Carvalho

Hello,

Does this port generate Java Bytecode directly or does it generate
first Java Assembler and then feeds that into an internal assembler?

I ask because Android does not use Java Bytecode, it has it's own,
completely different bytecode.

-- 
Felipe Monteiro de Carvalho
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] C++ gets language-internal concurrency support

2011-08-20 Thread Alexander Klenin

On Fri, Aug 19, 2011 at 21:33, Michael Schnell  wrote:
> Does C++11 also provide a more "automatic" parallel processing feature than
> just something similar to worker threads (Object Pascal TThread), maybe
> similar to Prism's "parallel loop" ?

Basically, no.
Here is a quite recent "call for action" in this regard:
http://software.intel.com/en-us/blogs/2011/08/09/parallelism-as-a-first-class-citizen-in-c-and-c-the-time-has-come/

-- 
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Delphi XE2 uses FPC for iOS target

2011-08-20 Thread Graeme Geldenhuys

On 18 August 2011 22:27, Max Vlasov wrote:
> I glanced at the quick guide. Actually MiGLayout looks promising, but
> personally I'd use it if it's implemented with intuitiveness and visual
> sense in mind.

"visual" doesn't always make things better. In fact, visual often
posses more limitations. Think Linux vs Windows. I can backup our
linux server's config files for all services. Install a new linux
system, copying in the configs and be up and running in no time.
Windows with all it's non-visual configuration dialogs, there is no
way to backup configs and restore them on another Windows server. This
is just one of many such examples.

If you do want to see what MiGLayout is doing, simply enable the
"debug" option in Layout, Column or Row constraint. In then visualizes
how things are laid out and calculated. Run the Swing Layout demo, and
see the Debug section for more details. Right-click anywhere in the
form see and change the constraint settings.

> context menu items or maybe some tool buttons. Otherwise if one have to
> learn the string constraint language, he can fall into the same trap as with

If you look at all the constraint options, it does seem overwhelming
at first glance. But in reality you only need very few options to
start building usable UI's. Once you are familiar with those, you can
revisit your UI designs to improve there behaviour with more advanced
settings.

Anyway, this message thread has strayed way off topic now. :)

-- 
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] Arm Thumb2 - Stellaris status

2011-08-20 Thread John Clymer

For the cortex-m3 parts, one standard run-time is sufficient for all cortex 
parts, as their core systems are defined enough to get into a main pascal 
routine with the same code.

I'm specifically looking at Stellaris right now, specifically the Fury line of 
controllers, which is the largest line thus far.

However, in reviewing the Stellaris lineup - ALL Stellaris parts have their 
peripherals mapped out at exactly the same locations.  Which means that 1 
peripheral / register definition file could be used for all Stellaris parts.  
The confusion on this would be that symbols would exist for peripherals that 
might not exist for a specifically chosen part.  I'm just peeking around at 
other vendor's product lines to see how much work would be involved - and also 
trying to make things as generic as possible for re-use.

There are 180+ Stellaris parts currently active, of which 79 are Fury class 
parts.  Of the Fury class parts, there are 8 possible combinations of FLASH and 
SRAM amounts.  I'm looking to put all 79 parts into the table of controllers, 
HOWEVER, each part will reference a unit specific the same controller unit 
file.  I'm looking to change cpuinfo.pas to a structure, and part of that 
structure will be the FLASH and SRAM configurations, so that t_embed.pas won't 
even need a gazillion case() statements to generate the link info.

Once done with Fury class, I would move on to STM32 - as I have those available 
for ready use as well.

When STM32 and part of Stellaris have been created, a good framework should be 
in place to more easily add more vendors and/or parts.

From: David Welch 
To: FPC developers' list 
Sent: Sat, August 20, 2011 12:01:14 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status

Just jumping in here and maybe it was discussed but the cortex-m3 appears to 
have been designed so that if you match the arm abi you can put the address of 
handlers directly in the vector table and not have to trampoline off of a 
wrapper function.  basically 8 well chosen register are put on the stack so you 
dont have to preserve them, so that the handler has the look and feel of a 
standard function and not the look and feel of an interrupt handler.

I would not mix all cortex-m3 based devices into one definition.

Perhaps lumping all the stellaris parts into one but that would still get huge. 

Maybe all the 800 series in one, all the 1000 series in another, and so on.  
That is the way the vendors tend to manage information for their parts, and it 
makes sense as a sub-set of a larger family is very closely related and easier 
to manage the subtle differences.

Is it your intention to get all of the stellaris parts into this project all at 
once?  Or build some framework, add one or a few parts from each family and 
then 
over the course of time add a part or two here and there?

I would start with one family 800 series or 1000 series, one of the more 
simpler 
ones, and try to capture that series. If one series of parts is too bulky or 
complicated that is your answer, you may need to isolate each part by itself.

I would not try to cross vendors to the stm or lpc/nxp cortex-m3 or cortex-m0 
parts etc.  the memory maps and peripherals across vendors are too different.  
boot strategies, flash programming, etc.  I suspect everyone using an arm7 in a 
controller now will be using one of the cortex-m cores before long if they are 
not already.  Is it st or lpc that has both cortex-m3 and cortex-m0 based parts 
now?  I would have to look up the difference but know I bought/saw both at some 
point.

David

On 08/20/2011 02:20 AM, John Clymer wrote:
> Also, just peeked at current line up of STM32 controllers, there are 150
> different controllers available, consisting of 33 possible combinations
> of FLASH memory and SRAM size.
> 
> I will try to get the controller specific parts boiled up into record
> structures this weekend, and get some added controllers installed into
> cpuinfo.pas. (And fix any compiler breakages from the change.) I have
> the SVN download - so generated diffs should be a bit easier (still
> learning SVN though...)
> 
> Also, I read through the ARM docs regarding the "standard" library - and
> can setup registers based on the each vendors published "C" library so
> they match the ARM/vendor docs. However, as each controller in the
> line-up has only certain peripherals, is it the intention that EACH
> controller gets it's own controller file with memory definitions for
> peripherals ? That's 300+ unit files between STM32 and TI's Stellaris
> line-ups.
> 
> OR - does one try to merge as many controllers into 1 memory definition
> as possible. i.e. ALL of stellaris could be defined for the maximal
> configuration of peripherals (as they have a standard mapping layout for
> peripherals i.e. ALL LM3 devices have UART0 at the exact same location -
> and all have the same register layout.) The caveat to this that one
> could compi

[fpc-devel] New FPC target: JVM

2011-08-20 Thread Jonas Maebe

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!


Jonas

PS: no, this does not mean that FPC development from now on will only, or even 
primarily, focus on managed language support. And the infrastructure added for 
JVM support will make an LLVM port a lot more feasible in the future, because 
there is now a code generator layer that uses high level type 
information.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

2011-08-20 Thread Geoffrey Barton


On 20 Aug 2011, at 09:01, David Welch wrote:

> 
> Just jumping in here and maybe it was discussed but the cortex-m3 appears to 
> have been designed so that if you match the arm abi you can put the address 
> of handlers directly in the vector table and not have to trampoline off of a 
> wrapper function.  basically 8 well chosen register are put on the stack so 
> you dont have to preserve them, so that the handler has the look and feel of 
> a standard function and not the look and feel of an interrupt handler.
> 
> I would not mix all cortex-m3 based devices into one definition.
> 
> Perhaps lumping all the stellaris parts into one but that would still get 
> huge.  Maybe all the 800 series in one, all the 1000 series in another, and 
> so on.  That is the way the vendors tend to manage information for their 
> parts, and it makes sense as a sub-set of a larger family is very closely 
> related and easier to manage the subtle differences.
> 
> Is it your intention to get all of the stellaris parts into this project all 
> at once?  Or build some framework, add one or a few parts from each family 
> and then over the course of time add a part or two here and there?
> 
> I would start with one family 800 series or 1000 series, one of the more 
> simpler ones, and try to capture that series. If one series of parts is too 
> bulky or complicated that is your answer, you may need to isolate each part 
> by itself.
> 
> I would not try to cross vendors to the stm or lpc/nxp cortex-m3 or cortex-m0 
> parts etc.  the memory maps and peripherals across vendors are too different. 
>  boot strategies, flash programming, etc.  


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


> I suspect everyone using an arm7 in a controller now will be using one of the 
> cortex-m cores before long if they are not already.
>  Is it st or lpc that has both cortex-m3 and cortex-m0 based parts now?  I 
> would have to look up the difference but know I bought/saw both at some point.
> 
> David
> 
> 
> 
> On 08/20/2011 02:20 AM, John Clymer wrote:
>> Also, just peeked at current line up of STM32 controllers, there are 150
>> different controllers available, consisting of 33 possible combinations
>> of FLASH memory and SRAM size.
>> 
>> I will try to get the controller specific parts boiled up into record
>> structures this weekend, and get some added controllers installed into
>> cpuinfo.pas. (And fix any compiler breakages from the change.) I have
>> the SVN download - so generated diffs should be a bit easier (still
>> learning SVN though...)
>> 
>> Also, I read through the ARM docs regarding the "standard" library - and
>> can setup registers based on the each vendors published "C" library so
>> they match the ARM/vendor docs. However, as each controller in the
>> line-up has only certain peripherals, is it the intention that EACH
>> controller gets it's own controller file with memory definitions for
>> peripherals ? That's 300+ unit files between STM32 and TI's Stellaris
>> line-ups.
>> 
>> OR - does one try to merge as many controllers into 1 memory definition
>> as possible. i.e. ALL of stellaris could be defined for the maximal
>> configuration of peripherals (as they have a standard mapping layout for
>> peripherals i.e. ALL LM3 devices have UART0 at the exact same location -
>> and all have the same register layout.) The caveat to this that one
>> could compile code that won't actually run on a given device.
>> 
>> OR - we could leave the peripheral definitions to the user. (Which I'm
>> assuming is not the preferred route.)
>> 
>> John
>> 
>> 
>> *From:* Florian Klämpfl 
>> *To:* FPC developers' list 
>> *Sent:* Fri, August 19, 2011 12:19:05 PM
>> *Subject:* Re: [fpc-devel] Arm Thumb2 - Stellaris status
>> 
>> Am 19.08.2011 05:28, schrieb John Clymer:
>> > Currently, everything is in a handful of giant arrays. Just wondering
>> > if it would be better to switch to a record structure for the controller
>> > entries - rather than individual arrays. (Add in a variety of STM parts
>> > and the other manufacturers, and there could easily be over 100 memory
>> > configurations in the table.)
>> 
>> Maybe it's indeed better to have an array of records, each record
>> describing one controller.
>> 
>> >
>> > My suggestion would be that the register definitions come in an UNIT
>> > file that only defines registers. The controller unit in the compiler
>> > source would only provide the bare minimum necessary to bring the system
>> > up and call PASCALMAIN. However, if it is deemed better to have the
>> > entire register set defined inside t

Re: [fpc-devel] Arm Thumb2 - Stellaris status

2011-08-20 Thread Geoffrey Barton


On 20 Aug 2011, at 07:20, John Clymer wrote:

> Also, just peeked at current line up of STM32 controllers, there are 150 
> different controllers available, consisting of 33 possible combinations of 
> FLASH memory and SRAM size.  
> 
> I will try to get the controller specific parts boiled up into record 
> structures this weekend, and get some added controllers installed into 
> cpuinfo.pas.  (And fix any compiler breakages from the change.)  I have the 
> SVN download - so generated diffs should be a bit easier (still learning SVN 
> though...)
> 
> Also, I read through the ARM docs regarding the "standard" library - and can 
> setup registers based on the each vendors published "C" library so they match 
> the ARM/vendor docs.  However, as each controller in the line-up has only 
> certain peripherals, is it the intention that EACH controller gets it's own 
> controller file with memory definitions for peripherals ?  That's 300+ unit 
> files between STM32 and TI's Stellaris line-ups.  
> 
> OR - does one try to merge as many controllers into 1 memory definition as 
> possible.  i.e. ALL of stellaris could be defined for the maximal 
> configuration of peripherals (as they have a standard mapping layout for 
> peripherals i.e.  ALL LM3 devices have UART0 at the exact same location - and 
> all have the same register layout.)  The caveat to this that one could 
> compile code that won't actually run on a given device.
> 

I think that anybody using a device would have to have already assigned pin 
connections in the board design and should know well which peripherals they are 
using.

> OR - we could leave the peripheral definitions to the user.  (Which I'm 
> assuming is not the preferred route.)

It is to me. People can contribute definitions and drivers as they use the 
parts and these can just go in 'uses'.

Geoffrey

> 
> John
> 
> From: Florian Klämpfl 
> To: FPC developers' list 
> Sent: Fri, August 19, 2011 12:19:05 PM
> Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
> 
> Am 19.08.2011 05:28, schrieb John Clymer:
> > Currently, everything is in a handful of giant arrays.  Just wondering
> > if it would be better to switch to a record structure for the controller
> > entries - rather than individual arrays.  (Add in a variety of STM parts
> > and the other manufacturers, and there could easily be over 100 memory
> > configurations in the table.)
> 
> Maybe it's indeed better to have an array of records, each record
> describing one controller.
> 
> > 
> > My suggestion would be that the register definitions come in an UNIT
> > file that only defines registers.  The controller unit in the compiler
> > source would only provide the bare minimum necessary to bring the system
> > up and call PASCALMAIN.  However, if it is deemed better to have the
> > entire register set defined inside the RTL - that would be fine too.
> 
> Well, isn't it for a user easier just to pass the controller he uses on
> the command line and the compiler does the rest? Why bother with
> addional uses etc. if the compiler knows already anything?
> ___
> 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

2011-08-20 Thread David Welch

Just jumping in here and maybe it was discussed but the cortex-m3 
appears to have been designed so that if you match the arm abi you can 
put the address of handlers directly in the vector table and not have to 
trampoline off of a wrapper function.  basically 8 well chosen register 
are put on the stack so you dont have to preserve them, so that the 
handler has the look and feel of a standard function and not the look 
and feel of an interrupt handler.

I would not mix all cortex-m3 based devices into one definition.

Perhaps lumping all the stellaris parts into one but that would still 
get huge.  Maybe all the 800 series in one, all the 1000 series in 
another, and so on.  That is the way the vendors tend to manage 
information for their parts, and it makes sense as a sub-set of a larger 
family is very closely related and easier to manage the subtle differences.

Is it your intention to get all of the stellaris parts into this project 
all at once?  Or build some framework, add one or a few parts from each 
family and then over the course of time add a part or two here and there?

I would start with one family 800 series or 1000 series, one of the more 
simpler ones, and try to capture that series. If one series of parts is 
too bulky or complicated that is your answer, you may need to isolate 
each part by itself.

I would not try to cross vendors to the stm or lpc/nxp cortex-m3 or 
cortex-m0 parts etc.  the memory maps and peripherals across vendors are 
too different.  boot strategies, flash programming, etc.  I suspect 
everyone using an arm7 in a controller now will be using one of the 
cortex-m cores before long if they are not already.  Is it st or lpc 
that has both cortex-m3 and cortex-m0 based parts now?  I would have to 
look up the difference but know I bought/saw both at some point.

David

On 08/20/2011 02:20 AM, John Clymer wrote:

Also, just peeked at current line up of STM32 controllers, there are 150
different controllers available, consisting of 33 possible combinations
of FLASH memory and SRAM size.

I will try to get the controller specific parts boiled up into record
structures this weekend, and get some added controllers installed into
cpuinfo.pas. (And fix any compiler breakages from the change.) I have
the SVN download - so generated diffs should be a bit easier (still
learning SVN though...)

Also, I read through the ARM docs regarding the "standard" library - and
can setup registers based on the each vendors published "C" library so
they match the ARM/vendor docs. However, as each controller in the
line-up has only certain peripherals, is it the intention that EACH
controller gets it's own controller file with memory definitions for
peripherals ? That's 300+ unit files between STM32 and TI's Stellaris
line-ups.

OR - does one try to merge as many controllers into 1 memory definition
as possible. i.e. ALL of stellaris could be defined for the maximal
configuration of peripherals (as they have a standard mapping layout for
peripherals i.e. ALL LM3 devices have UART0 at the exact same location -
and all have the same register layout.) The caveat to this that one
could compile code that won't actually run on a given device.

OR - we could leave the peripheral definitions to the user. (Which I'm
assuming is not the preferred route.)

John

*From:* Florian Klämpfl 
*To:* FPC developers' list 
*Sent:* Fri, August 19, 2011 12:19:05 PM
*Subject:* Re: [fpc-devel] Arm Thumb2 - Stellaris status

Am 19.08.2011 05:28, schrieb John Clymer:
 > Currently, everything is in a handful of giant arrays. Just wondering
 > if it would be better to switch to a record structure for the controller
 > entries - rather than individual arrays. (Add in a variety of STM parts
 > and the other manufacturers, and there could easily be over 100 memory
 > configurations in the table.)

Maybe it's indeed better to have an array of records, each record
describing one controller.

 >
 > My suggestion would be that the register definitions come in an UNIT
 > file that only defines registers. The controller unit in the compiler
 > source would only provide the bare minimum necessary to bring the system
 > up and call PASCALMAIN. However, if it is deemed better to have the
 > entire register set defined inside the RTL - that would be fine too.

Well, isn't it for a user easier just to pass the controller he uses on
the command line and the compiler does the rest? Why bother with
addional uses etc. if the compiler knows already anything?
___
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] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

[fpc-devel] ARM patch to switch to controller records rather than arrays

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] Arm Thumb2 - Stellaris status

[fpc-devel] (no subject)

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] New FPC target: JVM

Re: [fpc-devel] C++ gets language-internal concurrency support

Re: [fpc-devel] Delphi XE2 uses FPC for iOS target

Re: [fpc-devel] Arm Thumb2 - Stellaris status

[fpc-devel] New FPC target: JVM

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] Arm Thumb2 - Stellaris status

Re: [fpc-devel] Arm Thumb2 - Stellaris status

35 matches

Site Navigation

Mail list logo

Footer information