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
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 int
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
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
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
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. T
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 acti
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
___
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 be
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
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?
Somet
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 defi
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
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
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 Thumb
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?
htt
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
per
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 woul
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
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 featu
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
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
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 existi
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!
Nikola
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 b
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
__
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
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:
/op
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 deve
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 debug
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 th
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 f
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
__
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 withou
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 consta
35 matches
Mail list logo
