Recent

Author Topic: RAM allocation  (Read 3302 times)

StephanB

  • Newbie
  • Posts: 1
RAM allocation
« on: November 30, 2020, 07:36:22 am »
Just for curiosity: When a program coded for Win32 is run on Win64, hoch much RAM does a DOUBLE variable (8 bytes) use? 8 or 16 bytes?

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: RAM allocation
« Reply #1 on: November 30, 2020, 07:46:56 am »
Hello StephanB,
Welcome to the forum.

According to the documentation, double variables are always 8-bytes. (On that page, you need to scroll down to see the table).
https://wiki.freepascal.org/Variables_and_Data_Types
« Last Edit: November 30, 2020, 07:50:14 am by Handoko »

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: RAM allocation
« Reply #2 on: November 30, 2020, 09:15:48 am »
Most types do not change their size. There are some exceptions though like IntPtr which represents an offset of a pointer and thus changes depending on the processor.

What can change is the endianness, so if you write/read values from a stream, you need to make sure it is the same endianness or swap the byte order otherwise.
Conscience is the debugger of the mind

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: RAM allocation
« Reply #3 on: November 30, 2020, 09:36:57 am »
Two particular types
Code: Pascal  [Select][+][-]
  1. SizeInt, SizeUInt
are designed to change size according to platform bitness, as their names clearly indicate.

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: RAM allocation
« Reply #4 on: November 30, 2020, 12:38:56 pm »
There are some exceptions though like IntPtr which represents an offset of a pointer and thus changes depending on the processor.

Two particular types
Code: Pascal  [Select][+][-]
  1. SizeInt, SizeUInt
are designed to change size according to platform bitness, as their names clearly indicate.

Correct me if I'm wrong but those size differences are set at compile time, aren't they? So a 32bit binary won't magically use 64bit SizeInt if run in, say, Windows 64bit, will it?
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: RAM allocation
« Reply #5 on: November 30, 2020, 01:08:01 pm »
Correct me if I'm wrong but those size differences are set at compile time, aren't they? So a 32bit binary won't magically use 64bit SizeInt if run in, say, Windows 64bit, will it?

These types only differ at compile time.

Seenkao

  • Hero Member
  • *****
  • Posts: 546
    • New ZenGL.
Re: RAM allocation
« Reply #6 on: November 30, 2020, 05:02:18 pm »
Если я правильно понял вопрос, то уже скомпилированная программа под Win32, должна использовать отведённую ей область памяти как для Win32, а не для Win64.
А регистры будут использоваться 64-х битные (я могу ошибаться).

это не IDE решает, это решает сама системаWin32/Win64.

google translate:
If I understood the question correctly, then a program already compiled for Win32 should use the memory area allocated to it as for Win32, and not for Win64.
And the registers will be 64-bit (I could be wrong).

The IDE does not solve this, this is decided by the Win32/Win64 system itself.
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: RAM allocation
« Reply #7 on: November 30, 2020, 06:57:08 pm »
Well the question isn't clear about whether or not the program is compiled for the target system. With a cross platform approach, I imagine that the program would be recompiled for each specific system but it is true that on Windows you can still run 32-bit programs. The 32-bit environment is emulated and in theory the programs runs the same as if the machine were 32-bit. Though that might not be true forever.
Conscience is the debugger of the mind

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
Re: RAM allocation
« Reply #8 on: November 30, 2020, 07:34:43 pm »
Well the question isn't clear about whether or not the program is compiled for the target system. With a cross platform approach, I imagine that the program would be recompiled for each specific system but it is true that on Windows you can still run 32-bit programs. The 32-bit environment is emulated and in theory the programs runs the same as if the machine were 32-bit. Though that might not be true forever.
Most - if not all -  of that is also true for Linux: multiarch: https://wiki.debian.org/Multiarch
On both Windows and Linux it is NOT emulated but a real native sub system..
« Last Edit: November 30, 2020, 07:43:47 pm by Thaddy »
Specialize a type, not a var.

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: RAM allocation
« Reply #9 on: December 01, 2020, 01:37:22 am »
I do not disagree
Conscience is the debugger of the mind

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: RAM allocation
« Reply #10 on: December 01, 2020, 09:15:05 am »
If I understood the question correctly, then a program already compiled for Win32 should use the memory area allocated to it as for Win32, and not for Win64.
And the registers will be 64-bit (I could be wrong).

If you run a 32-bit application on a 64-bit OS then the registers will be as if the application is running on a 32-bit variant of the CPU. So in case of x86 the general purpose registers (EAX, etc.) will be 32-bit not 64-bit.

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: RAM allocation
« Reply #11 on: December 01, 2020, 10:45:23 am »
Well the program is made to believe the OS is 32-bit and that the registers are 32-bit. Though at some level, the registers are in fact 64-bits even if the upper bits are ignored by 32-bit instructions.

At the assembler level, you can in fact access the 64-bit registers by adding the operand-size override prefix (0x48 for 64-bit). That's a byte you would add in the machine code just before the instruction you want to modify.

You could do the same when running 16-bit programs on a 32-bit processor. The prefix to use 32-bit operands was 0x66.
Conscience is the debugger of the mind

Seenkao

  • Hero Member
  • *****
  • Posts: 546
    • New ZenGL.
Re: RAM allocation
« Reply #12 on: December 01, 2020, 11:04:44 am »
At the assembler level, you can in fact access the 64-bit registers by adding the operand-size override prefix (0x48 for 64-bit). That's a byte you would add in the machine code just before the instruction you want to modify.

You could do the same when running 16-bit programs on a 32-bit processor. The prefix to use 32-bit operands was 0x66.
I will lose it ... :'(
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: RAM allocation
« Reply #13 on: December 02, 2020, 12:19:01 pm »
You mean you will miss it?
Conscience is the debugger of the mind

Seenkao

  • Hero Member
  • *****
  • Posts: 546
    • New ZenGL.
Re: RAM allocation
« Reply #14 on: December 03, 2020, 11:17:47 pm »
You mean you will miss it?
когда мне это может понадобится, я не смогу это найти.

Google translate:
when I may need it, I cannot find it.
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

 

TinyPortal © 2005-2018