Pascal 8Byte / C 4Byte bei procedure Stack

[Mathias]

Ich habe folgendes Experiment gemacht, da ist mir aufgefallen, das die Adressen Abstände bei Pascal 8Byte ist und bei C nur 4Byte.
Auch die Reihenfolge ändert die Richtung.
Das cdecl; scheint keinen Einfluss zu haben.

Code: Alles auswählen

program Project1;

  procedure test(a, b, c: integer); cdecl;
  begin
    WriteLn(PtrUInt(@a));  // xxx328
    WriteLn(PtrUInt(@b));  // xxx320
    WriteLn(PtrUInt(@c));  // xxx312
  end;

begin
  test(1, 1, 1);
end.  

Code: Alles auswählen

#include <stdio.h>

void test(int a,int b,int c)
{
  printf("addr: %i\n", &a);  // xxx740
  printf("addr: %i\n", &b);  // xxx744
  printf("addr: %i\n", &c);  // xxx748
}

int main(int argc, char *argv[])
{
  test(1,1,1);
  return 0;}

Bei diesen Einfachen Programm hat dies keinen Einfluss. Aber was passiert, wen man untereinander mit libs Funtionen austauscht.
Dies würde ja Knallen, wen Pascal 4Byte Abstand hat und in C würden 8Byte abgearbeitet werden.

Wird dies irgendwie über den ELF-Standard geregelt ?

[PascalDragon]

Ich habe folgendes Experiment gemacht, da ist mir aufgefallen, das die Adressen Abstände bei Pascal 8Bit ist und bei C nur 4Bit.

Die Abstände sind in Byte, nicht Bit.

Kompilierst du beide Programme auch mit der gleichen Bitness? Sprich 32- vs. 64-bit?

[Mathias]

Kompilierst du beide Programme auch mit der gleichen Bitness? Sprich 32- vs. 64-bit?

Lazarus ist definitiv 64bit.

Das C-Beispiel kompiliere ich so:

Code: Alles auswählen

gcc main.c

Ich vermute, das gcc auch 54bit kompiliert.

Da wird folgendes ausgespuckt:

Code: Alles auswählen

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 

Auch wen ich 64bit mit -m64 erzwinge, sind die Abstände 4Byte.
So nebenbei wird friss mein gcc -m32 nicht mal.

Die Abstände sind in Byte, nicht Bit.

Da habe ich mich vertan,
Habe es korrigiert.

[martin_frb]

Du misst die Abstände im "stack frame", nicht aber in der Übergabe.

Übergeben werden die Werte in diesem Beispiel wahrscheinlich in CPU Registern.

Beide Compiler sollten die gleiche Übergabe machen, aber dann können Sie entscheiden wie es weiter geht.

Die Verwendung des Adress-Operators zwingt den Compiler die Variablen ins Memory (stack / frame) zu schreiben. Da das nach der Übergabe ist, kann da jeder Compiler machen was er will.

[Mathias]

Übergeben werden die Werte in diesem Beispiel wahrscheinlich in CPU Registern.

Dies wäre eine Erklärung.