Hi,

I've spoken to Tom and he agreed. We moved the EpikTimer repository to Github. The Lazarus-CCR version will be deleted by Tom in due time.

I applied some of my changes to code in Github (more changes recently discussed in this mailing list will follow soon), fixed the "etdemo" project to be compilable again, updated the demo to use FPC Resources instead of the old *.lrs files.

I've also bumped the version number and created a new release. Hopefully this will resolve the issue about people downloading the 2006 old archive version.

I've also updated the Free Pascal Wiki page with the latest information.

Wiki Page:
http://wiki.freepascal.org/EpikTimer

Source code:
git clone https://github.com/graemeg/epiktimer.git

Release downloads:
https://github.com/graemeg/epiktimer/releases

Regards,
- Graeme -

Thanks a lot for that!

/home/junior/lazarus/components/epiktimer-1.0.1/epiktimer.pas(403,29) Error: Identifier not found "clock_gettime"

Lazarus 1.3 r45165 FPC 2.6.4 i386-linux-gtk 2

Great !

As EpikTimer internals seem to be discussed here rather than in fc-devel, I add some comments in this thread.

I use EpikTimer in my (soon to be released) work on the ActiveNoGUI Widget Type.

Here I found, that it is a rather appropriate use for EpikTimer to handle it in a "static" way, not creating an instance of TEpikTimer with every use of same, but simply to use class properties, class procedures and class functions of TEpikTimer.

To allow for this, during the weekend, I modified the (not absolutely latest) version of epiktimer.pas in a very straight forward manner, just defining some variables as "class var", and adding "class" to some properties, procedures and functions.

Moreover I moved the function "InitTimebases" out of the creator and made it to be a private "class procedure TEpikTimer.InitTimebases;"

Also TEpikTimer.InitTimebases is called in an initialization section of the EpikTimer unit.

The advantage of this is that the overhead when creating an EpikTimer is reduced to zero.

The only disadvantage I see is is, that with that modification, different instances of TEpikTimer don't have their own tuning parameters, as they are calculated only in the initializing phase of the application.

Hence deriving siblings of TEpikTimer and overloading the virtual functions SystemSleep, CalibrateCallOverheads, and CalibrateTickFrequency does not seem to make sense.

(In fact I am not sure, what happens when deriving siblings of TEpikTimer, as I am astonished that doing things like "class function SystemSleep(Milliseconds: Integer):integer; Virtual;" is even possible. I fail to understand how a virtual class function is supposed to work, as I understand that without an instance there is no virtual message table.)

Is deriving siblings of TEpikTimer and overloading the virtual functions SystemSleep, CalibrateCallOverheads, and CalibrateTickFrequency really a viable feature of EpikTimer ? If yes, I am sure that I can find a way to combine it with the static usability I introduced.

If you want me to, I of course can provide an appropriately modified version of epiktimer.pas derived from the version you tell me you consider stable.

Thanks for listening,
-Michael

Michael Schnell wrote

As EpikTimer internals seem to be discussed here rather than in fc-devel, I add some comments in this thread.

fpc-devel is only for FPC related/included units. EpikTimer is not included in FPC. I also believe that not everything must always be included with FPC - that makes it harder to experiment and apply changes.

The only disadvantage I see is is, that with that modification, different instances of TEpikTimer don't have their own tuning parameters, as they are calculated only in the initializing phase of the application.

I believe that change to be a big disadvantage for EpikTimer.

(In fact I am not sure, what happens when deriving siblings of TEpikTimer, as I am astonished that doing things like "class function

Best create a small example, and raise it in the fpc-devel or fpc-users mailing list.

If you want me to, I of course can provide an appropriately modified version of epiktimer.pas derived from the version you tell me you consider stable.

If you want, please publish your git repo somewhere like on Github, Gitorious etc. That way I (and everybody else) can look and your changes. I don't like people sending me complete units, I also don't prefer patch files any more. Git is a distributed version control system, and it is much easier and quicker for everybody to simply fetch a branch from somebody else's public Git repo, evaluate and merge changes if needed. The full history and ownership of those changes stay intact too.

Regards,
Graeme

Graeme Geldenhuys wrote

fpc-devel is only for FPC related/included units. EpikTimer is not included in FPC. I also believe that not everything must always be included with FPC - that makes it harder to experiment and apply changes.

I see.

How do you suggest a not Lazarus enabled user of a finally released version should use it ?

I believe that change to be a big disadvantage for EpikTimer.

If you think so - while I think it's a big advantage - I will try to find a way that both - using the tuning parameters found in the application initialization phase and calculating new tuning parameters when creating an instance - is possible

Best create a small example, and raise it in the fpc-devel or fpc-users mailing list.

No problem. I already tested it with the version I found in Lazarus CCR and re-do this with the newer version you come up with.

If you want, please publish your git repo somewhere like on Github, Gitorious etc. ...

Agreed.

I'll be back
-Michael

"Michael Schnell" wrote

Here I found, that it is a rather appropriate use for EpikTimer to handle

it in a "static" way, not creating an instance of TEpikTimer with every use of same, but simply to use class properties, class procedures and class functions of TEpikTimer.

Why not simply instantiate a single instance and use that where necessary instead of completely reworking the class?

(In fact I am not sure, what happens when deriving siblings of

TEpikTimer, as I am astonished that doing things like "class function SystemSleep(Milliseconds: Integer):integer; Virtual;" is even possible.

Yes, virtual class methods are a big advantage of Object Pascal compared to e.g. C++. You don't believe how much I miss that feature when working with C++ at work. :/

I fail to understand how a virtual class function is supposed to work, as

I understand that without an instance there is no virtual message table.)

The VMT is not per instance, but per type, so there is no difference there regarding virtual instance and class methods.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140526/79844bc7/attachment.html>

Sven Barth wrote

Why not simply instantiate a single instance and use that where necessary instead of completely reworking the class?

I am not doing an application, but an enhancement to the LCL. Hence this in any case would be an _additional_ instance.

The VMT is not per instance, but per type, so there is no difference there regarding virtual instance and class methods.

Thanks for this explanation (from here this does look obvious ;-) )

-Michael

Here I found, that it is a rather appropriate use for EpikTimer to handle it in a "static" way, not creating an instance of TEpikTimer with every use of same, but simply to use class properties, class procedures and class functions of TEpikTimer.

You know that the Pascal implementation of such singletons is called a "unit"?

DoDi

Michael Schnell wrote

How do you suggest a not Lazarus enabled user of a finally released version should use it ?

Like its always been done. Lazarus is NOT the only way to use FPC. Define the Unit Path (source code path) or Compiled Unit Path (path to *.ppu files) in your Editor or IDE of choice. Then compile your project with FPC. You can also define all the compiler settings in a cfg file and pass that to FPC instead (fpGUI Toolkit's demos use this). There are many alternative ways.

I for one don't like the Lazarus Packages any more. I much prefer to define my paths to used units, and include path macros to make it work on multiple systems. MSEide and Maximus IDE does that. I believe you can do the same with Lazarus IDE too. The advantage of this is that changing a compiler parameter (new define, extra debug info or optimisation setting etc) immediately applies to all units used in your project. With Lazarus Packages that is a pain in the butt - having to manually modify many *.lpk packages. But that is my personal opinion - others are welcome to disagree.

Regards,
Graeme

You don't have to edit all lpk files. In fact you don't need to touch a single lpk

http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Add_a_flag_to_project_and_all_packages

And for those packages, that do not support your flag, you can define excludes. How does MSEide and Maximus define excludes?

Mattias

Mattias Gaertner wrote

You don't have to edit all lpk files. In fact you don't need to touch a single lpk ... last I remember one had to modify each package to support multiple

build modes from Lazarus IDE. That defeated the point for me. I must admit, I haven't gotten a Lazarus update since end of last year. So it seems things in that front has improved.

And for those packages, that do not support your flag, you can define excludes. How does MSEide and Maximus define excludes?

You have multiple build modes (columns) in the grid. eg: B, M, 1, 2 etc. and keyboard shortcuts for those build modes. You then setup a matrix (grid) of options, and you simply need to tick which setting applies to which build mode. Maximus (not sure about MSEide) supports global and user defined macros in any of the Project and Compiler options you can set. The same macros could also have different values for each build mode - so cross-compiling for example can easily be accomplished.

To exclude any settings, just make sure they are not ticked for a specific build mode.

Attached are two screenshots from Maximus (MSEide looks pretty much the same).

Regards,
Graeme

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-Project Options.png
Type: image/png
Size: 49173 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140526/d0e7f52e/attachment-0002.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-Project Options2.png
Type: image/png
Size: 62185 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140526/d0e7f52e/attachment-0003.png>

You know that in Object Pascal one does not need to restrict oneself to merely units anymore?

Regards,
Sven

It exists since 1.1, so more than year.
Deja vu?

Lazarus has all this. But that is not what I meant.

What if a package crashes with an optimization? How can you compile your project and all other packages with the optimization?

Attached are two screenshots from Maximus (MSEide looks pretty much the same).

Thanks. Can you give the modes names instead of M,B,1,2,3,4?

Mattias

Will EpikTimer work in a console app? If so, an example on the wiki page would sure be appreciated. I need it now (for an Android Linux console program)! :)

Regards,
Paul
www.TurboControl.com

Mattias Gaertner wrote

It exists since 1.1, so more than year.

Wow, then time flies! :) I'll pull and build a new version to see what's new.

What if a package crashes with an optimization? How can you compile your project and all other packages with the optimization?

Umm, guess I've just been lucky using well maintained frameworks & versions. ;-) If something like that happens, I would normally delve into the code and fix it - if the original author hasn't yet. I'm not afraid to look at other peoples code (but I know very well, that not everybody is like me).

Thanks. Can you give the modes names instead of M,B,1,2,3,4?

In Maximus yes, in MSEide no.

Regards,
Graeme

Paul Breneman wrote

Will EpikTimer work in a console app?

Yes, since 4 years ago. ;-)

If so, an example on the wiki page would sure be appreciated.

The wiki already does.

http://wiki.freepascal.org/EpikTimer#Usage

If you don't have an "Application" object instance, simply create the EpikTimer instance as follows:

  ET := TEpikTimer.Create(nil)

and then use it as indicated. Also remember to free it manually when you are done.

Regards,
Graeme

In Lazarus, you can even set the project's build mode/overrides such that packages gets different output directories depending on the build mode, target cpu, target os, etc... This prevents unnecessary recompilation of packages (in theory) when changing build modes.

You can even setup the default compiler options to include your common cross-compilation build modes so that each new project is cross-compiler ready. Switching build modes is 2 mouse clicks away.

I have even made an IDE add-on package that allows you to switch fpc versions on the fly from within the IDE. However I could not make a dedicated switching button as IDEIntf does not expose the IDE toolbar.

Stephano

Until you hit a compiler bug that surfaces with e.g. -O2 or -O3. Those happen, too. Then again, you're probably not afraid to delve into the compiler code, I suppose <SCNR> :)

Reinier Olislagers wrote

Until you hit a compiler bug that surfaces with e.g. -O2 or -O3.

I don't ever use -O3

Those happen, too. Then again, you're probably not afraid to delve into the compiler code, I suppose <SCNR> :)

Been there, done that. But Compiler code isn't my cup of tea, sorry. :)

Regards,
Graeme

All that is possible with Maximus and MSEide too. :)

For your first option, I actually prefer to recompile all units when I change build modes etc. My system and FPC is fast enough that I don't even notice it compiling. It also ensure that I have my latest compiler options active in the compiled units.

In Maximus and MSEide they are called template projects. MSEide can even export and import user selected options from and to projects. I still need to implement something like that in Maximus.

For your last point, in Maximus (I haven't tried in MSEide but probably works too), you simply use one of the macro variables you have setup. Different build modes could then use different FPC versions - all with a single keyboard shortcut.

Regards,
Graeme

Graeme Geldenhuys wrote

Like its always been done.

So it will be a ZIP file containing a directory with the source code and an lpk file to allow using it as a Lazarus package.

This is OK for me, provided there is a documentation file that briefly explains how to use it within Lazarus (install package) and without (define unit path).

Thanks !
-Michael

Soft answer: Yes

Long answer:

My current test-state of the "interfaces.pas" unit for the would-be "ActiveNoGUI" widget type in Lazarus happily uses the current half-released state of EpikTimer. It provides a Lazarus compatible TTimer implementation.

It is used in a test project (a command-line tool) and works perfectly for me (in Linux X86 32 Bit Linux ).

I did not yet do any tests with Android or ARM, though.

-Michael

I used EpikTimer on Android ARM, it works.... Well, at least it seems to work. Why you need an example? Just use it; the process is obvious and straightforward. Add epiktimer unit to uses seciton of ur source file; clear timer, start timer, stop timer, read result

28.05.2014, 13:26, "Michael Schnell" :

Michael Schnell wrote

So it will be a ZIP file containing a directory with the source code and an lpk file to allow using it as a Lazarus package.

https://github.com/graemeg/epiktimer/releases

This is OK for me, provided there is a documentation file that briefly explains how to use it within Lazarus (install package) and without (define unit path).

http://wiki.freepascal.org/EpikTimer

G.

Hi Michael,

I'm having a little trouble understanding where new functionality is needed for your use case. With the existing code, you don't need to create an EpikTimer instance each time you need a new timer. A single instance supports an unlimited number of timers using the TimerData record from the EpikTimer unit:

TimerData = record
  Running:Boolean; // Timer is currently running
  TimebaseUsed:TimeBaseSelector; // keeps timer aligned with the source
that started it.
  StartTime:TickType; // Ticks sample when timer was started
  TotalTicks:TickType; // Total ticks... for snapshotting and pausing
end;

You can declare any number these records to create as many timers as you need. Here's an example for a single ET instance of EpikTimer:

Function TimedExecution: Extended;
Var
  i:integer;
  TimerA,TimerB:TimerData;
  TickTick:Array[1..1000] of TimerData; // if you need a thousand timers
Begin
  ET.Clear(TimerA);
  ET.Clear(TimerB); // Declared timers must be cleared before use
  For i:=1 to 1000 do ET.Clear(TickTick[i]);
  ET.Start(TickTick[someindex])
    ET.Start(TimerA);
    ExecuteTimedSectionA;
    ET.Stop (TimerA);
    ET.Start(TimerB);
    ExecuteTimedSectionB;
    ET.Stop (TimerB);
  ET.Stop(TickTick[someindex])
  etc...

The mechanism is pretty efficient as the record for each timer is only a few dozen bytes. One instance is necessary to do the initialization that detects the available timebases and does a rough overhead calibration for system calls. There's always going to be edge jitter with userland calls, so calibrating each timer wouldn't add certainty to the overall measurement.

If I'm not understanding the problem you're trying to solve, could you please explain it a little further?

Thanks,

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140528/bd11aaea/attachment-0001.html>

Graeme Geldenhuys wrote

https://github.com/graemeg/epiktimer/releases

I attached to that and will base all future on it.

Does it make sense that I directly to the repository ?

-Michael

Of course you are right that I don't exactly need it. In my source code I use a {?ifdef to decide whether or not to create an instance (my current source of epiktimer.pas allows for both, I just added the code that allows for statistically using the class functions).

OTOH, the discussion in the fpc-pascal mailing list shows that the low level / arch dependent stuff should be removed from epiktimer.pas and moved into a new file that at best would finally be integrated in the rtl. My ActiveNoGUI stuff will just call this basic function(s) and hence be independent of epiktimer.pas. I will offer a version of epiktimer.pas plus an additional low level file using vDSO in Linux) as soon as I find the time to do some testing. This will not break anything !

With the existing code, you don't need to create an EpikTimer instance each time you need a new timer.

In fact I don't need any "timer" at all. I just need to read a reliable (not to be modified behind our back as GetTimeOfDay) time counter that can be read with as little overhead as possible. And finally this should be available for all archs and done by an arch independent call and (this is why a am greatly interested in "EpikTimer" be used as broadly as possible, so that it hopefully is well supported in future.

-Michael

Graeme Geldenhuys wrote

https://github.com/graemeg/epiktimer/releases

Graeme,

I am trying to base my future work on your git.

Unfortunately this version of EpikTimer.pas does not compile on Linux: "clock_gettime()" is not found. (And the comment there says " Experimental, no idea if this works or is implemented correctly", so this is intentional.

As this is exactly what I am going to use, do you suggest that I should fix/implement this ?

I supposedly would do a very small separate unit/source file for this (and related) low level / potentially arch depending functions and finally try to have it integrated in the fpc RTL

What do you think ?

Thanks,
-Michael

Just add unit linux to the uses clause under {$IFDEF LINUX}. clock_gettime is in there, not in the baseunix/unix.

Michael.

Michael Van Canneyt wrote

Just add unit linux to the uses clause under {$IFDEF LINUX}. clock_gettime is in there, not in the baseunix/unix.

Thanks.

So I do have an example for this.

In the end I am willing to do an implementation of this using vDSO...

-Michael

if you do a vDSO implementation, please do not limit the implementation to the clock_gettime, but implement all calls that support it.

Michael.

I do see your point.

Right now I extracted (most of) the hardware depending stuff (i.e. the performance timer access including calibration) out of EpikTimer.pas in a new not class-driven unit EpikTimerBase that is used by EpikTimer and in the end should be usable without EpikTimer.pas.

Right now it just accesses the X86 performance register directly.

This unit could use a vDSO Unit that contains access via __vdso_clock_gettime().

Here other such functions could be places (e.g. for x86 and x86/64:: __vdso_getcpu(), __vdso_gettimeofday() and __vdso_time() ).

-Michael

Michael Schnell wrote

Does it make sense that I directly to the repository ?

That's fine.

Regards,
- Graeme -

I am not an expert with git. So I'll need some help.

For the beginning I created a folder in the git project folder and in that I created symlinks to the files I want to add.

I created a new branch and did stage and a commit (seemed to haw worked).

Now I tried "git push".

Here I (of course) need to provide a password.

How to proceed ?

-Michael

Michael Schnell wrote

I am not an expert with git. So I'll need some help.

The easiest is to simply create a Github account, then go to the EpikTimer repository in my account and click "Fork". Github will do the rest and give you instructions on how to checkout your forked version.

Git has excellent documentation at http://git-scm.com/documentation. The Internet is also full of very good tutorials and other documentation/tips on git.

Regards,
- Graeme -

Thanks,

I created a github account and did the forking as described.

Seems to have worked.

I could do

git fetch upstream
From https://github.com/mschnell1/epiktimer
* [new branch] gg-changes -> upstream/gg-changes
* [new branch] master -> upstream/master

and

git push origin master
Everything up-to-date

and after committing my changes locally finally

git push
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 2.55 KiB, done.
Total 4 (delta 3), reused 0 (delta 0)
To https://github.com/mschnell1/epiktimer.git
b320f58..33120b0 master -> master

could you check if this did work ?

Thanks,
-Michael

Am I correct to assume that a "fork" is similar to a "branch" and hence the branches can share common files (e.g. updated demo/test projects).

-Michael

Michael Schnell wrote

Am I correct to assume that a "fork" is similar to a "branch" and hence the branches can share common files (e.g. updated demo/test projects).

Not really, 'fork' means you copy everything from one repo to another, and from then on your repo is totally independent from whatever it was 'forked' from.

Maintainer of the 'original' repo can then 'pull' changes, 'merge' them back into his own, then 'push' them to his own repo, from which you can 'pull' all you want...

More advanced usage, you can do 'branch' on your repo that you tell people to 'pull' from, and so on.

(that's just gliding over having not read a lot about git, mostly lkml ;) )

el_es

-Michael

Michael Schnell wrote

could you check if this did work ?

Yes I can see your change.

TIP:
If you are tracking another repository, don't develop in the "master" branch. Leave that branch so it can track the upstream repository without causing any conflicts. Rather develop in a branch, and keep each feature or bugfix in a separate branch.

That makes the upstream developers and your life much easier. You will then be able to keep your repository up to date with the official one (Github doesn't do that for you), and others can pull specific branches from you with whatever features they want in the official repo.

Moving commits to a new branch is very easy. Afterwards you will have to reset your "master" branch to the last official commit, then do a forced push to update your Github repository.

Regards,
- Graeme -

Michael Van Canneyt wrote

if you do a vDSO implementation, please do not limit the implementation to the clock_gettime, but implement all calls that support it.

For a starter, I did a testing project that (without using any external library) finds an verifies the ELF structure in memory that contains the vDSO functions.

Unfortunately the old Kernel I am using here only seems to provide the entries __kernel_sigreturn() and __kernel_vsyscall.

I suppose I need to upgrade before proceeding.

-Michael

Michael Schnell wrote

I suppose I need to upgrade before proceeding.

Off-Topic in this list, but maybe you might be able to help

On my PC (with rather old 32 Bit Suse) I installed the current released version of Debian in Virtual Box. One virtual box "machine" holding the 32 Bit version and one machine holding the 64 bit version.

Now I am stuck with three problems.

1) The 64 Bit Debian works perfectly. I could install a shared folder and copied the 32 bit Lazarus/fpc generated program "vdso_test" to a "virtual" user folder.
Here the file has "rwxr-xr-x" properties

When I type "./" the TAB key nicely adds the file name.

But with "Enter" I get:

"bash: ./vdso_test: no such file or directory"

Is a 64 bit Linux not supposed to run 32 bit programs ? Should there not be a more "speaking" error message ?

2) in the 32 bit system, I did not yet dare to try to have Lazarus cross-compile the program to 64 bit. (I would not like to install fpc and Lazarus in the virtual machines.)

3) In the other virtual box machine with the 32 Bit Debian, I seem not to be able to correctly install the "guest additions":
- Other than with the 64 bit Debian, the Desktop size does not auto-adapt to the window the host supplies
- I can't install a shared folder and hence I can't easily transfer the program file to be tested to the guest file system.

- any help on one of theses ?
TIA,
-Michael

Stating the obvious: A 64bit Linux is supposed to run 64 bit programs. Have you installed the 32bit libraries?

Should there not be a more "speaking" error message ?

No one bothered enough.

2) in the 32 bit system, I did not yet dare to try to have Lazarus cross-compile the program to 64 bit. (I would not like to install fpc and Lazarus in the virtual machines.)

What is the question?

3) In the other virtual box machine with the 32 Bit Debian, I seem not to be able to correctly install the "guest additions": - Other than with the 64 bit Debian, the Desktop size does not auto-adapt to the window the host supplies

That's off topic.

- I can't install a shared folder [...]

Yes, you can. Try harder.

Mattias

Mattias Gaertner wrote

Stating the obvious: A 64bit Linux is supposed to run 64 bit programs. Have you installed the 32bit libraries? > Should there not be a more "speaking" error message ? No one bothered enough.

Do you suggest the "Missing file" is a library the 32 bit program calls ? If yes the error message in fact would be erroneous as it states the wong filename to be missing)

Do you suggest it is necessary / possible to install one or more libraries in the 64 bit system to allow 32 bit programs to run ? I'll try to find instructions for that.

What is the question?

Is it easy to cross compile for 64 bit Linux in 32 bit Linux ? I seem to remember tat certain 32/64 bit cross-compile variants are not recommended.

> - I can't install a shared folder [...] Yes, you can. Try harder.

Obviously I need working "guest additions".

I'll try to solve this.

Thanks !
-Michael

In this case I guess it misses the 32bit loader. And yes, the error message is misleading.

Do you suggest it is necessary / possible to install one or more libraries in the 64 bit system to allow 32 bit programs to run ?

Yes.

[...] Is it easy to cross compile for 64 bit Linux in 32 bit Linux ? I seem to remember tat certain 32/64 bit cross-compile variants are not recommended.

It is easier to install a 64bit system and use that for both.

Mattias

Mattias Gaertner wrote

Stating the obvious: A 64bit Linux is supposed to run 64 bit programs. Have you installed the 32bit libraries?

After "adding" the 32 bit architecture to the package manager and apt-getting "ia32-libs", I get a decent error message about a missing library when starting the program.

Unfortunately installing the appropriate libary (gdk-pixbuf2.0-dev) did not help.

Keeping on trying...

-Michael

Michael Schnell wrote

Keeping on trying...

In fact I do not need a GUI for this test. So I did a simpler testing program without using the LCL (Results see the other mail)

-Michael

First testing results:

On Kernel 3.1.10 (32 bit):
- I do find the vDSO ELF structure (always at FFFFE000)
- it seems to provide "__kernel_sigreturn", "__kernel_rt_sigreturn" , and "__kernel_vsyscall"

On Kernel 3.2.0 64 bit, using a 32 Bit testing program:
- I do find the vDSO ELF structure at (e.g. at F774300, the location varies for any program start. This behavior is documented for vDSO)
- it also seems to provide "just __kernel_sigreturn", "__kernel_rt_sigreturn" , and "__kernel_vsyscall"

So I seem to be out of luck hoping for vDSO support for the performance counter or similar arch depending time-source access with 32 bit systems :-(

It _might_ be possible the __kernel_vsyscall could be done in a way that it provides arch independent timer counter access that stays in user mode if possible. I'll keep researching...

-Michael

This is as documented in the vdso man page. i386 only exports those 3 functions. If your testing program is 32 bit, it won't give you the 64 bit vdso image, obviously.

Try with a 64 bit test program.

Henry

I guess it's because
http://kernelnewbies.org/Linux_3.15-DriversArch#head-293bf8d606065cc1e6324f65a017e79144467d3f

i.e. explicit time functions support was just added recently to mainline...

Lukasz

Henry Vermaak wrote

This is as documented in the vdso man page. i386 only exports those 3 functions. If your testing program is 32 bit, it won't give you the 64 bit vdso image, obviously.

I do know this. But I in fact hope that the Linux team is going to do improvements. I suppose that the structure of vDSO is done as it is (compatible to an ELF so) to at any time allow the Kernel developers to add more functions without breaking anythings.

Try with a 64 bit test program.

Of course I am going to do this. I'll post results ASAP.

-Michael

Thanks for the hint !

Do you have an idea which Kernel versions do have this support (and how to try them in Debian 32 and 64 Bit)

Thanks,
-Michael

I *think* what I pasted means, from 3.15 onwards...

maybe someone has a debian repository with such kernel (but I think it'll require debian sid, i.e. unstable...)

see if any of bit.ly/1l2AyWt may be of any help ?

(long form link : https://www.google.co.uk/search?q=debian+repository+mainline+kernel&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a&channel=fflb&gfe_rd=cr&ei=CIWhU_X8B4bN5Aao_YGgCA)

(especially end of http://forums.debian.net/viewtopic.php?f=10&t=73002 page, seems interesting)

Lukasz

Thanks, -Michael

Great !

I'll take a look ASAP.

I installed the 64 bit fpc in the 64 bit Debian and could check the vDSO. See my other mail.

-Michael

Checking with a 64 Bit program (after overcoming the shock that with 64 fpc "Integer" is 32 bit =-O ):

On Kernel 3.2.0 64 bit, using a 64 Bit testing program:
- I do find the vDSO ELF structure at (e.g. at 00007FFF5D2C9000, the location varies for any program start. This behavior is documented for vDSO)
- it seems to provide "__vdso_clock_gettime", __vdso_gettimeofday", "__vdso_time", "__vdso_getcpu"

but not "__kernel_sigreturn", "__kernel_rt_sigreturn" , and "__kernel_vsyscall"

funny....

-Michael

I think this vdso time thing is so fresh, it'll be great if you contact the maintainer (Andy Lutomirski) or the guy that wrote it (Stefani Seibold)

(i think kernel source tree has a nice script scripts/get-maintainer.pl to help with it, see and search https://www.kernel.org/doc/linux/MAINTAINERS in any case).

see http://search.gmane.org/search.php?group=gmane.linux.kernel&query=vdso there are interesting links I think you'd be interested in as well.

-Michael

Lukasz

Lukasz Sokol wrote

I think this vdso time thing is so fresh, it'll be great if you contact the maintainer (Andy Lutomirski) or the guy that wrote it (Stefani Seibold)

I wrote a mail to Andy

Lets see what he says.

-Michael

Why do you think this is funny? Those functions are not needed for x64, and presumably no-one cared enough to add the time functions to x86 (until recently).

Henry

I don't know what these functions really do and why they are not sensible with 32 Bit.

Of course vDSO is a moving target right now, but in the end it would be great if it provides a common set of functions for all archs, so that (non-C) programs can make use of those in an arch-independent way, instead of linking to arch depending libraries - coming with the Kernel
- that are originally done for C.

-Michael

Lukasz Sokol wrote

I think this vdso time thing is so fresh, it'll be great if you contact the maintainer (Andy Lutomirski) or the guy that wrote it (Stefani Seibold)

I wrote to Andy and he replied very quickly.

Unfortunately it seems that ubiquitous availability for vDSO based timing (and other) functions is not expected in near future. So I supposedly have to give up on that issue for the moment :-( .

-Michael

Is it possible to call about any syscall (timing included) through (32bit) exising vdso ? And measure how it goes vs 'normal' way of doing it via library chain?

Lukasz

No, only the ones that are exported via the VDSO. __kernel_vsyscall() is used to find the fastest way to make a syscall on your processor (i.e. sysenter vs int 0x80).

Henry

Lukasz Sokol wrote

Is it possible to call about any syscall (timing included) through (32bit) exising vdso ?

I understand that is what "__kernel_vsyscall" is supplied for (and I don't understand why it is nit supplied in 64 Bit).

And measure how it goes vs 'normal' way of doing it via library chain?

In fact that is not in my agenda.

I suppose for normal syscalls there will be no significant difference, as the switch to Kernel-mode and back will take the greatest amount of latency. But there might be certain syscalls that in fact are handled completely in user mode by the vDSO variant and hence will perform better.

I did not yet actually _call_ any vDSO function right now. I only checked how to find the vDSO ELF structure and dumped it's content on the screen so that I can see, what functions are implemented.

I did not yet try to do code that analyzes the ELF structure itself to find the procedure entry points.

If you want do do some tests yourself, I can send you my pure-pascal source code (no C-library calls ) that is able to locate the ELF structure (as well 32 as 64 Bits), so that you can enhance it.

-Michael

Henry just corrected me : that's not what this function is for: it's to select int 0x80 vs sysenter...

and I remember seeing somewhere on lkml (long time ago) that 64bit x86 don't need it, (either they both are equivalent or int 0x80 doesn't exist any more, or something...)

Can't comment on that, I'm afraid, you wouldn't know till you tried though.

That too I remember had some coverage on lkml since creators of one compiler (the Go language) got it wrong (the ELF parsing). But it seems they tried, at least.

I'm sorry :) I've neither time or knowledge required ... (I run Wheezy here, with kernel 3.2.0 i probably can't be of any help here either...)

Having a timer component, however, that can use this, could provide us application writers to have a way to detect&select what we want, when it comes to implementation.

-Michael

Lukasz

Lukasz Sokol wrote

Having a timer component, however, that can use this, could provide us application writers to have a way to detect&select what we want, when it comes to implementation.

IMHO a timer component that uses vdso's clock_gettime would be _very_ advantageous, provided this would be implemented in many archs and thus would free us from the necessity to use code to select which kind of timer we use. As long as most archs in vDSO do not provide clock_gettime, we can just as well implement the access to the timer hardware (e.g. performance counter register in X86 32 and X86-64) in our own code.

This already is done in the current Windows (and in my Linux 32 Bit) implementation of EpkiTimer and works just fine.

I'll add Linux 64 Bit support ASAP.

-Michael

Why you need an example?

I am not doing a program but a tool, that maybe might become integrated in Lazarus. Hence the code should be decently tested and verified to be as good (low latency) as it gets for any architecture.

-Michael

Lukasz Sokol wrote

Henry just corrected me : that's not what this function is for: it's to select int 0x80 vs sysenter... and I remember seeing somewhere on lkml (long time ago) that 64bit x86 don't need it, (either they both are equivalent or int 0x80 doesn't exist any more, or something...)

I see.

But this is really silly !

Why did they not simply (additionally) implement a function that just performs the best possible system call variant for the currant arch ?

-Michael

"Michael Schnell" wrote

On 06/20/2014 02:15 PM, Lukasz Sokol wrote: > > Henry just corrected me : that's not what this function is for: it's to

select int 0x80 vs sysenter... and I remember seeing somewhere on lkml (long time ago) that 64bit x86 don't need it, (either they both are equivalent or int 0x80 doesn't exist any more, or something...)

performs the best possible system call variant for the currant arch ?

Because you'd need to link in that code then. Where should that code be then? The glibc? What about other c-libraries then or FPC's c-library-less approach? A library? Oh wait that needs kernel calls to load...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140623/baf7d01b/attachment.html>

Sven Barth wrote

Because you'd need to link in that code then.

I don't see the what you mean by this.
vDSO is not really "linked". In an initialization phase, the static address of such a function is detected and when you want to call it, you just do an indirect call. (OK this is very similar to using an so ;-) .)

Where should that code be then? The glibc? What about other c-libraries then or FPC's c-library-less approach? A library? Oh wait that needs kernel calls to load...

Of course glibc _could_ forward calls to it's traditional functions to appropriate vDSO functions, but IMHO a real benefit of such vDSO functions would be exactly with languages like fpc that do not (like to) use the gnu provided libraries. Here, the RTL easily could do the call to the vDSO function, instead of either implementing arch depending stuff (like an optimized way of calling the Kernel via "int" or other means) but simply do an indirect function call using a pointer initialized in the program start phase - which should be easily doable in any language.

I did a preliminary test for this in pure fpc code. Seems rather easy.

In fact, in the initialization phase you read a virtual file (in proc) and hence you of course do an old-style system call. Hence, if you want to do all system calls by an (assumed) vDSO function, before the initialization is complete the code does need a fallback to a traditional internal "int" based function.

-Michael

Graeme Geldenhuys wrote

...

Finally I found that using theTSC supposedly in fact will not work reliabbly in SMP systems (which are ubiquitous right now).

http://linux.die.net/man/3/clock_gettime :
NOTE for SMP systems

The CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks are realized on many platforms using timers from the CPUs (TSC on i386, AR.ITC on Itanium). These registers may differ between CPUs and as a consequence these clocks may return bogus results if a process is migrated to another CPU.

.-Michael