Hi,
I want to convert a h-file of a c-library and h2pas has problems with it. The file contains "static inline" functions.
A second problem is the "volatile" keyword that's used in the function.

How do I approach this ?
Google helped me understand the "volatile" keyword, but is there a Pascal alternative ?
The "static inline" is more difficult to understand. I add the original source, and the resulting h2pas file so you can see what's happening.

Any help ?
As allways, TIA.

Regards,
Koenraad Lelong

Koenraad Lelong wrote

Google helped me understand the "volatile" keyword, but is there a Pascal alternative ?

No. FPC is at this time unlikely to perform any optimisations on pointer or global variables accesses that would be inhibited by making them "volatile" though.

The "static inline" is more difficult to understand.

Just declare them as regular functions (with or without inline). It's C's way of doing cross-module inlining:
a) the code has to be available in the header file, so the C compiler has the C code available to inline when the function is called b) if you declare the same function more than once, you are going to get multiple symbols with the same name and these will clash at link time. Therefore such inline functions in headers (which are almost always included in more than one source file) have to be declared static, as this makes these symbols private to that particular file.

Jonas

What I made of the h-file you can see in the archive. This compiles fine, both on i386-linux and arm-linux. But when I compile the testprogram for arm-linux I get this :
....
Searching file /opt/arcom/bin/arm-linux-ld... found Using util /opt/arcom/bin/arm-linux-ld
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `getpagesize'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `getenv'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `malloc'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `open'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `mmap'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `printf'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `printf'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `free'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `printf'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_open':
: undefined reference to `printf'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_close':
: undefined reference to `munmap'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_close':
: undefined reference to `close'
/opt/arcom/bin/../arm-linux/lib/libdevmem.a(libdevmem.o): In function `libdevmem_close':
: undefined reference to `free'
testdevmem.pas(29,1) Error: Error while linking
testdevmem.pas(29,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

I think I'm missing some file to link in, but I think I included every path. I use make.sh to know exactly what is included and what not, to try to debug this.
The original c-sample-application needs to statically link in the library. And I don't have the source of libdevmem, only the h-file.

fpc is 2.2.2rc2. I know 2.2.2 is out but I need time to test if it's ok to use it for my arm-system.

Thanks for any hints,
Koenraad Lelong.

2008/9/15 Koenraad Lelong :

seems like it's not finding libc?

henry

Henry Vermaak wrote

2008/9/15 Koenraad Lelong : > .... >

...

Thanks, but I do have -Fl/opt/arcom/arm-linux/lib/* in the script and /opt/arcom/arm-linux/lib contains a libc.a, libc.so, libc.so.6 and a libc-2.3.3.so. I tried with -Fl/opt/arcom/arm-linux/lib with the same result.
libc.a contains amongst others printf.o, getpagesize.o, getenv.o. Still missing something, but I can't see it.
Koenraad.

hmm, is -lc passed to arm-linux-ld? you might have to add -k-lc to the fpc command line. btw, which arcom board do you have? i'm getting a new one very soon, so we can team up on this :)

henry

Thanks, the application compiles and links on my host. It runs on the target, but unfortunately, the outputs and inputs don't do what I tell them. Time to dust off my little gdb-debugging skill I have.

Regarding my Arcom ( board : it's a Viper 400 M64 F32. I purchased the Linux dev. kit with the LCD, which contains all you need to develop in C. I'm using fpc :-).
P.S. I can't recommend Lazarus. It works but it's slow. I use MSEgui. Some time I'm going to try fpGUI.
Thanks again for the help.
Koenraad.

I was wondering, what exactly is slow in Lazarus, because I use it via remote desktop over a long-distance WiFi connection and it still is very fast..?

From: "Koenraad Lelong"

P.S. I can't recommend Lazarus. It works but it's slow. I use MSEgui. Some time I'm going to try fpGUI.

I don't know. On my 400MHz pxa255 processor, if you click on a button, the response comes about a second later (I didn't exactly time this). It's not usable.
It's been a while, end last year, I tried. Maybe things improved. Regards,
Koenraad.

Did you try remote debugging with MSEide? I use it daily with a AVR32 C project I work on currently and the AVR One! Nexus interface. The SVN trunk version of MSEide has some improvement for embedded debugging.

Martin

I tried on my 600 MHz XScale and it's indeed dog slow but this is true for all gtk2 applications I tried.

I made my first try for my application in "native" GTK2, and it was usable. I found designing it was a nightmare, if you are used to Delphi and Lazarus. Of course if you know GTK2 by heart it would be easyer. With "native" GTK2 I mean handcrafting all widgets and events. I designed the GUI with Glade, and then converted the C-ouput to Pascal.

Koenraad.

There are some possibilities to increase the speed of your lazarus software:

* Use gtk 1
* Use Qt 4 (needs a commercial license for non-gpl software)
* Improving the fpgui interface to Lazarus and use that. You can test the existing one to see if it has a higher speed. Information in the wiki:

http://wiki.lazarus.freepascal.org/fpGUI_Interface http://wiki.lazarus.freepascal.org/Roadmap#Status_of_components_on_each_widgetset

I think it would be very interresting if you test the lazarus-fpgui interface. I wonder if it performs better then gtk2, which give a higher value to investing time in it.

Felipe Monteiro de Carvalho wrote

* Use Qt 4 (needs a commercial license for non-gpl software)

Did you notice this:
http://www.klc.net.nz/linux/?page_id=13

regards,

Den Jean

Felipe Monteiro de Carvalho wrote

I think it would be very interresting if you test the lazarus-fpgui interface. I wonder if it performs better then gtk2, which give a higher value to investing time in it.

What to test there? A form and a button? Other widgetset are not implemented there and graphic too.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

> ... Other widgetset are not implemented there and graphic too.

Read as "other widgets" (or other controls).

Best regards,
Paul Ishenin.

Paul Ishenin wrote

What to test there? A form and a button? Other widgetset are not implemented there and graphic too.

There was a very vague description about it being slow, so anything could be slow, even a button. If only some parts are slow, then we need a better description of the problem.

Den Jean wrote

Did you notice this: http://www.klc.net.nz/linux/?page_id=13

kool!! So lcl-qt is already working with qtopia, is that it?

Paul Ishenin wrote

What to test there? A form and a button? Other widgetset are not implemented there and graphic too.

If you re-read my e-mail:

* Improving the fpgui interface to Lazarus and use that.

I think I made it clear that one would need to improve the existing interface.

guess I should update this page again ;)

FYI I develop in lazarus on x86_64.
To cross-compile to arm I just run command line while lazarus still running...
ppcrossarm -darm project.lpr

couldn't be more simple.

The builtin vncviewer works well too...

http://www.klc.net.nz/gum-vnc-boa.png

The main reason I love the lcl-qt is that fonts work and scale perfectly
- not the case with GTK / GTK2

And it ain't slow at all on the 400MHz gumstix.

Terry

2008/9/20 Koenraad Lelong :
--8<--

Regarding my Arcom ( board : it's a Viper 400 M64 F32. I purchased the Linux dev. kit with the LCD, which contains all you need to develop in C. I'm using fpc :-).

excellent. i've got a vulcan, which is big-endian (with fpu), and a quantum with big lcd. unfortunately fpc doesn't work with the vulcan. probably something to do with the fpu. i'm starting testing on the quantum soon.

henry

2008/9/21 Felipe Monteiro de Carvalho :

i'm keen to try lazarus with fpgui interface on my arm-linux board, i'll give feedback soon. (and hopefully help to improve the interface)

henry