How to align an array on cache line bounderies ?

[KpjComp]

The following seemed to work fine with my Arch Linux.

Code: [Select]

getconf LEVEL1_DCACHE_LINESIZE

But anyway, thanks for the heads up.  Appreciated.

[ludob]

Looked at the linux kernel sources to see how they get the coherency_line_size and they are using the cpuid instruction on x86 arch. With that info wrote the following code to get the value directly from the cpu (x86 only):

Code: [Select]

function getL1_line_size:integer;
var ebx:integer;
begin
   {$ASMMODE ATT}
   asm
     push %ebx;
     movl $0x80000005,%eax;
     xor %ebx,%ebx;
     xor %ecx,%ecx;
     xor %edx,%edx;
     cpuid;
     mov %ebx,ebx;
     pop %ebx;
   end;
  result:=ebx and $ff;
end;

Returns 32 on my Athlon X2 QL-60 running XP 32.

Edit: functions on AMD only,  for Intel change to

Code: [Select]

    movl $0x4,%eax;
...
  result:=ebx and $fff;


[KpjComp]

I'm no Linux expert, but from what I can gather libc.so seems to be on most distro's, and this seems to expose the sysconf function.  Maybe that will help.  If it could use this then you get the benefits of it been CPU agnostic.  If it doesn't exist, then maybe a fallback of 256b I don't think would be that bad, I'm not sure of any CPU's that uses larger, but I might be wrong.

Lazarus also seems to expose syconf, in the libc package.  Although libc does have "deprecated for new development".  But then the wiki seems to imply that's still OK to use, FPC/Lazarus also appears to use libc too.

I think I'm going to have to install a couple of Linux Distro's in VBox.

[KpjComp]

Ok, I've knocked up a quick console App.

It seems to work with my linux install, so I wonder if anyone could check with different linux installs.

Code: [Select]

program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes, SysUtils
  { you can add units after this };

{$IFDEF UNIX}
function sysconf(__name:longint):longint; cdecl; external 'libc.so.6' name 'sysconf';
const SC_LEVEL1_DCACHE = 190;
{$ENDIF}

begin
  writeln('Level1 cache');
{$IFDEF UNIX}
  writeln(sysconf(SC_LEVEL1_DCACHE));
{$ELSE}
  writeln(256);
{$ENDIF}
end.

On my machine I get 64.  Arch Linux.

[Rails]

Debian Unstable (32 bit install)

Level1 cache
64

[ludob]

getconf LEVEL1_DCACHE_LINESIZE

Debian sid arm926: 0 while cpu specs specify 32
Ubuntu 10.04 on intel atom: 64 OK
Ubuntu 10.04-64 on AMD 64: 64 OK
Solaris 10: invalid argument (LEVEL1_DCACHE_LINESIZE)
FreeBSD 8.1: no such configuration parameter `LEVEL1_DCACHE_LINESIZE`

I wonder if anyone could check with different linux installs.
...

Code: [Select]

{$IFDEF UNIX}

{$IFDEF UNIX} encompasses all *nix flavors, including Mac OSX. Use {$IFDEF LINUX} if you want to limit yourself to linux which looks appropriate seen above results.
Note that I didn't try the fpc version since the command line version doesn't work and even when it did, from experience, assuming that constants such as

Code: [Select]

SC_LEVEL1_DCACHE = 190; have the same value on all these systems is very risky.

[BigChimp]

Lazarus also seems to expose syconf, in the libc package.  Although libc does have "deprecated for new development".  But then the wiki seems to imply that's still OK to use, FPC/Lazarus also appears to use libc too.

If it does, it shouldn't (and to me, it said: "don't use the libc unit for new functionality.... even if you really want to... even if it is the easiest short term solution"). Deprecated for future use means you don't write new code using it.
FPC/Lazarus may still use it, but its use there should be phased out... it just takes a while in such a big project.

Isn't there some alternative in the Linux unit?
Otherwise:
http://wiki.lazarus.freepascal.org/libc_unit#So_what_to_replace_it_with.3F
Step 4

[marcov]

I'm no Linux expert, but from what I can gather libc.so seems to be on most distro's, and this seems to expose the sysconf function.  Maybe that will help.  If it could use this then you get the benefits of it been CPU agnostic.  If it doesn't exist, then maybe a fallback of 256b I don't think would be that bad, I'm not sure of any CPU's that uses larger, but I might be wrong.

Lazarus also seems to expose syconf, in the libc package.  Although libc does have "deprecated for new development".  But then the wiki seems to imply that's still OK to use, FPC/Lazarus also appears to use libc too.

Do not use unit libc. If you need unit libc functionality, define the relevant calls in a new unit. libc is deprecated deprecated deprecated and linux/x86 only (no 64-bit)
 

[KpjComp]

I'm sure there is some glitches to iron out, but it's looking good.

Like I said, I'll maybe go the fallback route of 256 if certain sanity checks fail.  And also make it so it's modifiable, so it can be overridden if needed.  This routine is mainly to make things as automatic as possible.  In this regard it seems to be working well.

The Assembler route, I would think would only hold the same number of barriers, like making it work on ARM/64bit etc.  Also the other worry with Assembler, I know in Windows the OS can get in the way sometimes when talking directly to hardware (permission etc), and using the OS's API is normally the route.