Recent

Author Topic: Strange Move(Fillchar) logic for x64  (Read 848 times)

beria

  • Jr. Member
  • **
  • Posts: 70
Strange Move(Fillchar) logic for x64
« on: September 23, 2022, 10:15:53 pm »
Here's where I noticed. Through the memory manager you can allocate a maximum of ptrUint bytes in one continuous block, that is 18446744073709551615.
"function GetMem(size:ptruint):pointer; "
But block copy and fill operations can only work with at most SizeInt bytes, that is 9223372036854775807.
"Procedure Move(const source;var dest;count:{$ifdef MOVE_HAS_SIZEUINT_COUNT}SizeUInt{$else}SizeInt{$endif});"
This is halved and equals only the maximum size of the static array....
" TTest = array[0..9223372036854775806] of byte;"
At the same time on other digits - it is not so and the maximum size of the buffer allocated in memory is equal to the size of procedures to work with them.
It may be a trifle, but I program input-output of large dynamic objects in memory and try to parallelize it as much as possible and to speed it up... :-)
It's not a question - I was just a bit surprised, that there is no uniformity in actually related procedures, for x64, and I have to bring different types of integer variables to each other, which is an unnecessary operation, in my opinion...

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Strange Move(Fillchar) logic for x64
« Reply #1 on: September 24, 2022, 08:39:54 am »
Pascal is signed type based, so GetMem should probably be SizeInt/PtrInt instead...

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Strange Move(Fillchar) logic for x64
« Reply #2 on: September 24, 2022, 09:29:08 am »
In any event there's two things here: whether the types are appropriate (i.e. at compilation time) and whether the parameters are meaningful (i.e. at runtime).

And OP's told us nothing at all about his development and execution environment, so it's impossible to say whether requesting an outrageous amount of memory since whether the swapspace can be extended at runtime is implementation-specific.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 14205
  • Probably until I exterminate Putin.
Re: Strange Move(Fillchar) logic for x64
« Reply #3 on: September 24, 2022, 11:16:18 am »
Pascal is signed type based, so GetMem should probably be SizeInt/PtrInt instead...
GetMem is declared as Unsigned in the manual Sarah: https://www.freepascal.org/docs-html/rtl/system/getmem.html and that is correct.

I always want to have negative memory, but alas days are gone.... ::)
In the olden days we could model back to the future. Current behavior is correct.
« Last Edit: September 24, 2022, 11:20:08 am by Thaddy »
Specialize a type, not a var.

beria

  • Jr. Member
  • **
  • Posts: 70
Re: Strange Move(Fillchar) logic for x64
« Reply #4 on: September 25, 2022, 10:12:30 am »
Pascal is signed type based, so GetMem should probably be SizeInt/PtrInt instead...
In the olden days we could model back to the future. Current behavior is correct.

"640 KB should be enough for everyone" (c)  :P
And more seriously - right now I have to put a check if for the buffer is allocated more than SizeInt bytes, and it may well be.... and if it will be important, then eventually write your own "Move" in assembly language...

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Strange Move(Fillchar) logic for x64
« Reply #5 on: September 25, 2022, 09:29:04 pm »
Pascal is signed type based, so GetMem should probably be SizeInt/PtrInt instead...
GetMem is declared as Unsigned in the manual Sarah: https://www.freepascal.org/docs-html/rtl/system/getmem.html and that is correct.

I know that it's documented (and implemented) like that, but that is not the point. The point is that e.g. arrays and strings only allow SizeInt accesses stressing how Pascal prefers signed types and that GetMem is simply implemented wrong in that regard. Delphi even only uses Integer here just like their array and string related functions only use Integer instead of SizeInt as well.

 

TinyPortal © 2005-2018