Ivo Steinmann wrote:
Hello all
I started some wiki for dynamic loading libraries support discussion.
http://wiki.freepascal.org/Dynamically_loading_headers
I already added an experimental implementation. If you have got some
ideas, whises and criticism, don't hesitate to write.
-Ivo Steinmann
Marco van de Voort wrote:
In our previous episode, Jeppe Johansen said:
-Ivo Steinmann
<http://www.dict.cc/englisch-deutsch/criticism.html>
What about saying that
procedure proc; external 'libname' name 'proc';
denotes a function that's dynam
Jonas Maebe wrote:
procedure proc; external 'libname' name 'proc';
denotes a function that's dynamically loaded implicitly, while
procedure proc; external name 'proc';
denotes a static linked function.
In my opinion that seems like the only logical solution. Explicit
dynamic loading will of
: word;
..
is not the same as
constructor init(
x1, y1, zeilen, spalten: word;
titel : String;
...
Regards,
Jeppe Johansen
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Your installation probably didn't went well. installbase should copy
both binaries and units to the proper directories. Try running "make
clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm PREFIX=C:\FPC"
Geoffrey Barton skrev:
I have been trying to build and run the a
1)
stm32f103 is a thumb2 only device, and you cannot generate a rtl for
both <=armv5 and thumb2. You need to modify the makefile to generate
either a thumb2 rtl or a arm rtl. You can do that by removing the arm
core units from CPU_UNITS and overriding the FPC_OPT to include -Cpcortexm3
2)
You
CPU_TARGET=arm OS_TARGET=embedded CROSSINSTALL=1 CROSSOPT="-Cpcortexm3 -O-""
Geoffrey Barton skrev:
Date: Mon, 19 Apr 2010 15:06:23 +0200
From: Jeppe Johansen
Subject: Re: [fpc-devel] arm embedded
To: FPC developers' list
Message-ID: <4bcc554f.9070...@kom.aau.dk>
C
What kind of hardware are you going to test it on?
Geoffrey Barton skrev:
Thanks, I would never have guessed the CROSSOPT in quotes. I can now
see thumb2 code in the object file.
Next step try it with hardware :-)
Geoffrey
On 21 Apr 2010, at 10:18, Jeppe Johansen wrote:
Yes, change
I would be interested in knowing whether it would be feasible to create
DSP backends for FPC. I recently had the experience of using a TMS320C26
which probably has to be programmed in assembler due to the limits of
the instruction set. But I hear newer DSPs use instruction sets geared
alot more
Florian Klaempfl skrev:
I recently had the experience of using a TMS320C26
which probably has to be programmed in assembler due to the limits of
the instruction set. But I hear newer DSPs use instruction sets geared
alot more towards highlevel compilers
Michael:
Cortex A8 runs ARMv7A. All the In
Add the missing instructions to the bottom of armins.dat, run mkarmins
in the same directory. (and then submit patch) :-)
Geoffrey Barton skrev:
I wrote a procedure to turn on interrupts:-
procedure intenable;nostackframe;
begin
asm
cpsie i
end;
end;
The compilation fails with 'Error
uctions to work
The special registers should be added to armreg.dat(and then run
mkarmreg). I didn't add all the cortex registers. Is primask a real
register btw? It just assembles to cpsr
Geoffrey Barton skrev:
On 12 Jul 2010, at 19:06, Jeppe Johansen wrote:
Add the missing instruction
I think that'll only complicate things. I think the compiler should be
able to do anything, down to lowest level. Just like you have CLI, HLT,
FXSTOR, WRMSR, etc instruction support in x86
Hans-Peter Diettrich skrev:
Geoffrey Barton schrieb:
It now recognises the mnemonic 'cpsie' but not the
Well, this is off topic, but ARM is quite a bit backwards compatible.
All ARM versions are backwards compatible(if we ignore thumb, which fpc
doesn't support anyway) :)
Geoffrey Barton skrev:
On 14 Jul 2010, at 10:49, Bernd Mueller wrote:
Michael Schnell wrote:
On 07/14/2010 11:02 AM, Bern
May I ask why do we need a CONFIG_OABI_COMPAT=y in the kernel to for
fpc to work on arm-linux?
regards
Nataraj
On Wed, Jul 14, 2010 at 3:42 PM, Jeppe Johansen <mailto:jepj...@kom.aau.dk>> wrote:
Well, this is off topic, but ARM is quite a bit backwards
compatible. All AR
I think it is on Thumb2 devices. To my understanding, they did so on
purpose so you no longer have to use interwork intermidiate functions to
switch between arm and thumb mode
Michael Schnell skrev:
On 07/15/2010 11:12 AM, Geoffrey Barton wrote:
A normal procedural call seems to assemble as
I wouldn't miss not having the name of the function as a result variable
in mode objfpc, at all. I think it would be a valid addition, as a
compiler directive that was turned on as default, as not to break
existing code
Hans-Peter Diettrich skrev:
I just had to chase an strange bug, in a local
orks as I suggested
I think alot of other people would think of this as an unnecessary
"addition", but well, I like my compilers strict :)
Hans-Peter Diettrich skrev:
Jeppe Johansen schrieb:
I wouldn't miss not having the name of the function as a result
variable in mode objfpc, a
hard to figure out why it didn't work as
intended(thought I was doing recursion, but it was just reading the
result variable)
Marco van de Voort skrev:
In our previous episode, Jeppe Johansen said:
The semantics are really hard to figure out too, whereas it makes
perfect sense when you us
Florian Klaempfl skrev:
Am 28.07.2010 15:10, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
IMO we should have at least an option, that a function name can *not* be
used for the function result any more, for the result we have the Result
variable. Then we can safely distinguis
Graeme Geldenhuys skrev:
Why doesn't the Linux version of FPC (or any other platform for that
matter) have it's own internal linker? Is it simply because nobody wrote it
yet, or is there some other technical reason for not doing it?
I have made part of an ELF internal linker.
The main hurdle is
The only reference I could find about it was in the GNU w32api
files(__W32API_VERSION, __W32API_MAJOR_VERSION, __W32API_MINOR_VERSION)
I couldn't find any meaning of this either, and don't know how to
interpret it
Den 22-09-2010 09:56, Michael Van Canneyt skrev:
On Tue, 21 Sep 2010, Thoma
Den 27-10-2010 23:14, Florian Klämpfl skrev:
Am 27.10.2010 22:52, schrieb Andrew Brunner:
My SCS project which is a scalable unified collaboration and
communication server that uses counting for transactions and network
consumption across all implemented protocols. Bytes, when aggregated
can cl
Den 28-10-2010 10:11, Florian Klaempfl skrev:
Am 28.10.2010 10:02, schrieb Jeppe Johansen:
Den 27-10-2010 23:14, Florian Klämpfl skrev:
Am 27.10.2010 22:52, schrieb Andrew Brunner:
My SCS project which is a scalable unified collaboration and
communication server that uses counting for
Den 03-11-2010 20:02, Andrew Brunner skrev:
On a 64bit fpc compile, and 64bit system with pointers, which
interlocked exchange is best used? Aren't pointers on x64 64bit
pointers? Shouldn't we be using InterlockedExhange64 code to access
specific x64 swaps?
Thanks.
Frankly, from a quick skim read, the only thing I find interesting about
that language is the column selection operator, for multidimensional
arrays, and I think that it might even be possible to integrate that
into FreePascal. Such a feature would make FreePascal much easier to use
in scientif
While trying to find a nice solution for generating interrupt vector
tables on ARM, I found that the usually employed solution is to generate
weak references to symbols, that are initialized to a single handler.
This way an application can override the weak reference, by declaring a
new symbol
Den 12-01-2011 06:56, Paul Ishenin skrev:
12.01.2011 12:29, Jeppe Johansen wrote:
A short example:
procedure NoHandler;
begin
end;
procedure TestProc; weakexternal name 'TestProc' set 'NoHandler';
...
begin
TestProc; // This will call NoHandler
end.
If we modify th
b) What happen if NoHandler is not found?
Then TestProc cannot be resolved to any symbol, and will generate a weak
undefined reference. Eg. it won't complain about an undefined reference
I don't see where you reference the "weakinitial" symbol in your patch
that's why I'm asking this questio
Den 12-01-2011 10:34, Florian Klaempfl skrev:
Am 12.01.2011 06:29, schrieb Jeppe Johansen:
What do you think about this proposal?
Is the current solution of using procedure variables so bad? Or what
does it lack?
___
fpc-devel maillist - fpc-devel
Den 12-01-2011 11:25, michael.vancann...@wisa.be skrev:
That's not correct. You must write all the default handlers.
For each procedure signature you must write a handler. So you must
write more code.
And if you want a correct error message at runtime, then you must
write a handler per weakex
Den 12-01-2011 12:42, Jonas Maebe skrev:
On 12 Jan 2011, at 06:29, Jeppe Johansen wrote:
While trying to find a nice solution for generating interrupt vector
tables on ARM, I found that the usually employed solution is to
generate weak references to symbols, that are initialized to a single
Den 12-01-2011 20:47, Jonas Maebe skrev:
The weakexternal directive already "defines" a symbol, it will exist at
runtime, but it might be nil.
What I meant is that there is a semantic difference between referencing a
symbol that may or may not be defined somewhere else (regardless of whether a
Den 12-01-2011 23:18, Jonas Maebe skrev:
On 12 Jan 2011, at 22:54, Jeppe Johansen wrote:
Den 12-01-2011 20:47, Jonas Maebe skrev:
I can't immediately think of a good syntax to directly define MyIRQHandler as a
weak symbol with the address of NoHandler as default value. Maybe this,
alt
t; since
I figured default made more sense than set, in the given context. I
still think using weakexternal makes sense(over adding a new "weak"
keyword), since the meaning and functionality still is the same
You can find the slightly modified patch here:
http://j-software.dk/weake
Den 14-02-2011 14:00, Jonas Maebe skrev:
On 14 Feb 2011, at 13:45, Jeppe Johansen wrote:
I did a little change to the patch though. I changed the syntax to be
"weakexternal ['library'] [name 'name'] [default 'initialvalue'];"
since I figured defaul
Den 14-02-2011 15:06, Jonas Maebe skrev:
On 14 Feb 2011, at 14:36, Jeppe Johansen wrote:
Sure, the weak declaration as a procedure directive could be added,
and it would indeed be something different from a weakexternal
procedure. Weakexternal should stay as it is, a procedure declaration
Den 14-02-2011 18:11, Jonas Maebe skrev:
On 14 Feb 2011, at 15:47, Jeppe Johansen wrote:
Okay, I understand what you mean. But then something more than "weak"
functionality should be added. Aliasing isn't the same, that's what
the "default" part does
proce
Den 15-02-2011 19:31, Jonas Maebe skrev:
On 15 Feb 2011, at 19:01, Jeppe Johansen wrote:
What about allowing a new keyword "weak" and let it have two forms(something
like you suggested back in one of the mails from 12th january)? Name mangling is an issue
of course. It would be
Den 15-02-2011 21:40, Jonas Maebe skrev:
On 15 Feb 2011, at 20:13, Jeppe Johansen wrote:
Den 15-02-2011 19:31, Jonas Maebe skrev:
I don't understand why you again propose to change the meaning of "external name 'xxx'"
for weak symbols. As I mentioned in my previ
As I wrote a while back, I would like to make it easier to handle
interrupts when using fpc for embedded work
The current solution is to use procedure variables with indirect jumps
in inline assembler. While that works okay it takes up a lot of space on
devices with lots of interrupts, and intro
Den 07-03-2011 09:43, Mark Morgan Lloyd skrev:
Jeppe Johansen wrote:
As I wrote a while back, I would like to make it easier to handle
interrupts when using fpc for embedded work
The current solution is to use procedure variables with indirect
jumps in inline assembler. While that works okay
Den 07-03-2011 13:49, Marco van de Voort skrev:
In our previous episode, Jeppe Johansen said:
A better idea, I think, is to use the old interrupt procedure directive.
For some embedded platforms simply allow also specifying a interrupt
vector/index after the interrupt keyword. Ex:
procedure
Den 15-03-2011 11:32, michael skrev:
I am trying to understand how to work with the various floating point options
available for FPC when running on ARM under Linux. I'm not to familiar with
all this so please bear with me.
Specifically I have a system comprising an TI OMAP3530: ARM CORTEX A8 ru
Den 16-03-2011 11:51, michael skrev:
So it seems fpc does not pass the correct options to as. Is there anyway I can
make it do so? My approach is obviously something of a hack.
Not as it is currently. I don't know why fpc doesn't pass the cpu
argument to gas. I guess it's because the arguments a
Den 13-03-2011 16:37, Florian Klämpfl skrev:
Am 13.03.2011 16:34, schrieb Jonas Maebe:
On 13 Mar 2011, at 16:31, Florian Klämpfl wrote:
Am 06.03.2011 22:46, schrieb Jeppe Johansen:
Further, a future benefit of using the interrupt keyword could be
generation of procedure exit code. Some
On 04/12/2015 02:11 AM, Georg Hieber wrote:
A few days ago the file avrsim.pp - startup code for an avr simulator
appeared.
Has anybody actually run (and debugged) code produced with fpc on an
avr simulator? If yes, a few hints about how the whole thing is set up
would be highly appreciated.
On 04/16/2015 12:49 PM, Paul Michell wrote:
I assume this is because string handling support is not included in the
embedded RTL generated with the compiler, or that I am not linking the right
object files if I need to do this by hand? What would be the best way to
enable string handling? Even s
There's a missing ; after the specialization
On 04/27/2015 09:46 PM, Michael Ring wrote:
Did not work, now I get
Fatal: Syntax error, ";" expected but "identifier PUBLIC" found
I did a cut & paste of your code into my code
Michael
Am 27.04.15 um 21:19 schrieb Sven Barth:
On 27.04.2015 20:31
On 10/11/2015 03:54 PM, Paul Breneman wrote:
On 10/10/2015 01:49 PM, Paul Breneman wrote:
On 05/28/2015 08:45 AM, Paul Breneman wrote:
Wow, yesterday I started this new message:
http://forum.lazarus.freepascal.org/index.php/topic,28561.0.html
And today Laksen says it's committed to SVN trunk
On 10/11/2015 10:10 PM, Michael Ring wrote:
Wow Jeppe, I am impressed, you used your time much better than I did,
your port looks pretty complete!
Please have a look at
https://github.com/yunkot/pxl
this lib was mentioned yesterday on lazarus list, this looks like a
good layer above the lowl
for me to make cmsis work)
Am 11.10.15 um 22:33 schrieb Jeppe Johansen:
On 10/11/2015 10:10 PM, Michael Ring wrote:
Wow Jeppe, I am impressed, you used your time much better than I
did, your port looks pretty complete!
Please have a look at
https://github.com/yunkot/pxl
this lib was
01VB,stm32f401x,stm32f4xx.lkr,%FLASHBASE:0x0800,%FLASHSIZE:0x0002,%SRAMBASE:0x2000,%SRAMSIZE:0x0001
Am 11.10.15 um 22:58 schrieb Jeppe Johansen:
Not sure what you are referring to here?
On 10/11/2015 10:47 PM, Michael Ring wrote:
I want to interface my Freedom-K64F code with thi
Not sure the timer initialization is right, but it looks ok.
One thing you need is the interrupt procedure directive:
procedure TIMER0_overflow; interrupt; public name 'TIMER0_COMPA_ISR';
Otherwise it'll probably reset at some point.
What compiler commandline are you using?
Best Regards,
Jepp
On 11/29/2015 11:35 PM, Andrew Haines wrote:
On 11/29/2015 02:13 PM, Jeppe Johansen wrote:
Not sure the timer initialization is right, but it looks ok.
One thing you need is the interrupt procedure directive:
procedure TIMER0_overflow; interrupt; public name 'TIMER0_COMPA_ISR';
On 12/16/2015 10:13 AM, Jonas Maebe wrote:
Anthony Walter wrote:
Because these devices have a fairly large amount of memory I have been
using ARM instruction set (-CIARM option) to simplify the assembler code
required for the low level interfaces, however early on I noticed that
if I specify the
On 03/19/2016 04:47 AM, Andrew Haines wrote:
I'm guessing there is some define I have to use and everything will
start working :)
Where do I go from here?
You need to remove classes from your used units. It needs a thread
manager to work.
The default thread manager simply halts the program if
On 09/08/2016 11:02 AM, Jy V wrote:
Hello to all assembler experts,
I would greatly appreciate if some people could help me prepare some
asm code for FreePascal for Win32, Win64, Linux x86, Linux x64 (and
maybe some ARM32bit + AARCH64)
I am using Lazarus 1.6, FPC 3.0.0 SVN revision 51630
x86_
On 10/31/2016 07:33 PM, Nikolai Zhubr wrote:
Hello all,
Is there any good generic (portable) function to ensure memory cache
flush for a thread on a multicore system?
What I'm trying to do is essentially fetch some debugging counters
from multiple threads. They might happen to run on separat
On 01/26/2017 04:12 PM, peter green wrote:
mricron is failing to build for Debian armhf, specifically we are
getting a bunch of "co-processor offset out of range" errors.
(9009) Assembling parconvert
parconvert.s: Assembler messages:
parconvert.s:3775: Error: co-processor offset out of range
On 10/20/18 4:07 PM, Simon Kissel wrote:
The requirements for my bounty would be:
- Must bring executable speed for non-Floating point load
on both multihreaded and non-multithreaded workloads to
the Speed of Kylix combined binaries
- Improvements should also help on ARM targets
- An LLV
Does the attached patch work?
On 1/26/19 12:20 PM, Michael Ring wrote:
I thought I was going crazy when debugging code that worked fine on
cortex m3/4 but created unexpected results on cortex m0.
Turns out that the compiler creates incorrect assembler code for
cortexm0 for div when used with
I can only reproduce this with peephole optimization turned on (O2). Can
you share more code that reproduces it?
Either way here's a patch that might fix it?
Best Regards,
Jeppe
On 2/3/19 5:31 PM, Michael Ring wrote:
Forgot to mention I am using Trunk compiler from today revision 41187
ond o
On 3/17/19 9:58 PM, Florian Klämpfl wrote:
Am 17.03.19 um 21:47 schrieb Martok:
Am 17.03.2019 um 18:57 schrieb Florian Klämpfl:
How is it better than intrinsics support (similiar to gcc/icc etc.)?
It *exists*?
Remember how long it took to get PopCnt support?
PopCnt is not really an intrins
That can't happen or won't benefit much, before the compiler supports
super-natual alignments. So there's a deeper level of support needed.
And personally I don't think that's the right long term direction. It
takes a long time to develop and maintain this stuff and you never know
what the mar
On 4/7/19 12:16 AM, Ben Grasset wrote:
On Sat, Apr 6, 2019 at 5:27 PM Jeppe Johansen <mailto:je...@j-software.dk>> wrote:
That can't happen or won't benefit much, before the compiler
supports super-natual alignments. So there's a deeper level of
support neede
Should be fixed now.
On 6/2/19 10:34 AM, Dimitrios Chr. Ioannidis via fpc-devel wrote:
Hi,
I got "Error: Internal error 2017091103" when I build the Laksen's
fp-ethernet with > -O1 optimization . AFAIK, the internal error's is a
compiler bug and something that should never happen. Should I c
On 6/1/19 3:37 PM, Dimitrios Chr. Ioannidis via fpc-pascal wrote:
Hi,
I started to write a driver (
https://github.com/dioannidis/fp_ethernet_enc28j60.git ) for this chip
( ENC28J60 Ethernet Controller ) first for the AVR platform, ( heavily
inspired from the UIPEthernet library (
https:/
It's been snuck in now :)
On 5/26/19 1:14 PM, Michael Ring wrote:
Just one note of caution:
When you encounter strange behaviour of your Code on Cortex-M0 in
respect to DIV commmand then check the mailinglist, Jeppe has provided
a fix but I am not quite sure if the fix has made it into offic
Probably because of the missing softfpu support. It's failing while
writing debug info for floating point stuff in variants.
It will be fixed some day :)
On 6/2/19 10:54 PM, Michael Ring wrote:
Thank you, not using -gw2 did the trick for avr5.
Is this issue also known to you? I am trying to
On 6/5/19 8:21 AM, Dimitrios Chr. Ioannidis via fpc-devel wrote:
Hi Jeppe,
Στις 2/6/2019 5:46 μ.μ., ο Jeppe Johansen έγραψε:
On 6/1/19 3:37 PM, Dimitrios Chr. Ioannidis via fpc-pascal wrote:
< snip >
As I'm not a compiler guy, isthe "volatile" intrinsic supported
One issue with the current state of the intrinsics is that they don't
really follow the common style among other languages, and there's no
agreed consensus about what path to take yet. To implement the more
common style would be a lot of work though compared to the current
autogenerated way
A
On 8/8/24 09:23, Pavel Pisa via fpc-devel wrote:
The problem with keeping virtual registers instead of mapping
to RV64 hardware ones in full Lazarus make bigide build
seems to be exactly reproducible on real hardware same
as in user space QEMU RISC-V Debian in chroot install.
Assembling formed
On 4/16/22 16:41, Sven Barth via fpc-devel wrote:
Benito van der Zander via fpc-devel
schrieb am Sa., 16. Apr. 2022, 15:43:
Hi,
it could always inline it.
For small sizes do that mov and for large sizes do rep stosb on
x86. It is very fast nowadays. Faster than FillChar on my
Hi,
A much more deterministic version would do it as this:
function HiInteger(value: LongInt): LongInt; nostackframe; assembler;
asm
mov r0, r0, asr #16
end;
If you do it with an inline ASM block and without stackframes it becomes
much harder to predict how you need to address variables by n
75 matches
Mail list logo
