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
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 "impor
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:
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
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
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 d
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
> col
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 smartph
On Sunday, 21 August 2011, Jonas Maebe
> 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).
> > 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 wh
On Sat, Aug 20, 2011 at 5:02 PM, Graeme Geldenhuys
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 d
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 sp
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 abou
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 wou
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
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) +
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 may
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
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 com
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
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 t
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
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
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 interpre
On Sun, Aug 21, 2011 at 3:45 AM, Jonas Maebe 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 oth
On Sun, Aug 21, 2011 at 5:33 PM, Jonas Maebe 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
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
On Sat, Aug 20, 2011 at 11:49 AM, Jonas Maebe wrote:
> 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
On 21 Aug 2011, at 19:05, dmitry boyarintsev wrote:
> On Sun, Aug 21, 2011 at 3:45 AM, Jonas Maebe
> 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?
>
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
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 -, this only allows the
RTL to compiled for one or the other.
This may be by design - in whic
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
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:
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
intermix
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 ba
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 throu
36 matches
Mail list logo
