Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2009-09

Move() vs MemCopy()

17 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

I'm still porting code from SpeedSoft's Pascal compiler. The code I am porting often uses MemCopy(), but Free Pascal doesn't seem to have such an implementation. So I looked at the next best thing... Move()

But as the name suggests (...Move()...), I would have expected it to actually move the data and not copy the data. The following example program demonstrates this. Shouldn't S1 = '' after the Move() call?

------------------------------------
Program Example42;

{ Program to demonstrate the Move function. }

Var S1,S2 : String [30];
begin
  S1 := 'Hello World!';
  S2 := 'Bye, bye   !';
  Move (S1,S2,Sizeof(S1));
  Writeln ('S2:', S2);
  Writeln ('S1:', S1);   // Why does this still hold "Hello World!"
end.

------------------------------------

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Marco van de Voort
to Graeme Geldenhuys

In our previous episode, Graeme Geldenhuys said:

Show quoted text 7 lines
I'm still porting code from SpeedSoft's Pascal compiler. The code I am porting often uses MemCopy(), but Free Pascal doesn't seem to have such an implementation. So I looked at the next best thing... Move() But as the name suggests (...Move()...), I would have expected it to actually move the data and not copy the data. The following example program demonstrates this. Shouldn't S1 = '' after the Move() call?

No.

Graeme Geldenhuys
to Marco van de Voort

2009/9/29 Marco van de Voort :

No.

So why is the function called MOVE instead of COPY? :-)

I grep searched the *full* FPC source and found a implementation of MemCopy() in the packages/pasjpeg/* directory... So it seems to confirm what you (Marco) said. MOVE = MEMCOPY. It that case, MOVE is a pretty stupid and confusing name for a procedure that actually copies memory and not move memory. Just my 2c worth. ;-)

procedure MEMCOPY(dest, src : pointer; size : size_t);
begin
  Move(src^, dest^, size);
end;

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Florian Klaempfl
to Graeme Geldenhuys
Show quoted text 5 lines
2009/9/29 Marco van de Voort : > No. So why is the function called MOVE instead of COPY? :-)

Because it doesn't copy your ram modules ;)

Graeme Geldenhuys
to Michael Van Canneyt

2009/9/29 Michael Van Canneyt :

Because move predates memcopy. memcopy is a windows function. Move existed in the system unit of TP even before windows existed.

Windows has 'memcpy()', not 'memcopy()' ;-)

As for the origins of Move(), I can't comment.... except to say that the original author of that procedure is trying to f*ck with my mind. :-) I would have imagined that with all our new found knowledge we might have come up with a better name for that procedure by now.

Maybe it is worth adding a MemCopy() method in FPC? Which simply calls Move() internally.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Jonas Maebe
to Graeme Geldenhuys: 2009/9/29 Michael Van Canneyt : Windows has 'memcpy()', not 'memcopy()' ;-) As for the…
Graeme Geldenhuys wrote
Windows has 'memcpy()', not 'memcopy()' ;-)

memcpy() is from the C library. And the C library also has memmove(), for that matter.

The difference between memcpy() and memmove() is that memcpy() has undefined behaviour if the source and destination overlap, while memmove() ensures that everything always works fine.

As a result, calling the Pascal version "move" is logical.

Jonas

Marco van de Voort
to Graeme Geldenhuys: 2009/9/29 Marco van de Voort : So why is the function called MOVE instead of COPY? :-)…

In our previous episode, Graeme Geldenhuys said:

> No. So why is the function called MOVE instead of COPY? :-)

Historical reasons apparantly.

Show quoted text 5 lines
I grep searched the *full* FPC source and found a implementation of MemCopy() in the packages/pasjpeg/* directory... So it seems to confirm what you (Marco) said. MOVE = MEMCOPY. It that case, MOVE is a pretty stupid and confusing name for a procedure that actually copies memory and not move memory. Just my 2c worth. ;-)

I've no idea what memcopy is, and why we should support it. Probably it is some pascalized version of the standard C memcpy command.

Move is in use for 20 years, and I think it will generate 1000 times more confusion than it will ever solve if you change or add to it.

Florian Klaempfl
to Graeme Geldenhuys: 2009/9/29 Florian Klaempfl : Well, if I move something (no matter what it is), it doesn't…
Show quoted text 6 lines
2009/9/29 Florian Klaempfl : > Because it doesn't copy your ram modules ;) Well, if I move something (no matter what it is), it doesn't exist in the original location any more. Hence my confusion about the Move() procedure.

Indeed, the serious answer is:
move handles overlapping memory blocks correctly (so the data might not existing anymore at the old location), memcpy doesn't do this and screws things up when handling overlapping blocks. This is why e.g. C++ has memmove as well which is more expensive than memcpy due to overlap checks.

Florian Klaempfl
to Jonas Maebe: memcpy() is from the C library. And the C library also has memmove(), for that matter.…
Show quoted text 13 lines
On 29 Sep 2009, at 15:46, Graeme Geldenhuys wrote: > Windows has 'memcpy()', not 'memcopy()' ;-) memcpy() is from the C library. And the C library also has memmove(), for that matter. The difference between memcpy() and memmove() is that memcpy() has undefined behaviour if the source and destination overlap, while memmove() ensures that everything always works fine. As a result, calling the Pascal version "move" is logical.

Jonas was quicker ;(

Graeme Geldenhuys
to Florian Klaempfl: Indeed, the serious answer is: move handles overlapping memory blocks correctly (so the…

2009/9/29 Florian Klaempfl :

Show quoted text 6 lines
Indeed, the serious answer is: move handles overlapping memory blocks correctly (so the data might not existing anymore at the old location), memcpy doesn't do this and screws things up when handling overlapping blocks. This is why e.g. C++ has memmove as well which is more expensive than memcpy due to overlap checks.

I thought simple pointer arithmetic would solve the issue of memcpy()?

Anyway, so based on your answer, if we apply the following code (shown belowe) to FPC, we have the best of both worlds! :-) MemCopy() does exactly what Move() does - but without the name confusion. :-)

Could this "alias" procedure be applied somewhere in FPC? This was done before - the case of AssignFile() vs Assign()

procedure MemCopy(src, dest: pointer; size: SizeInt);
begin
  Move(src^, dest^, size);
end;

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys
to Graeme Geldenhuys

2009/9/29 Graeme Geldenhuys :

Show quoted text 8 lines
Could this "alias" procedure be applied somewhere in FPC?  This was done before - the case of AssignFile() vs Assign() procedure MemCopy(src, dest: pointer; size: SizeInt); begin  Move(src^, dest^, size); end;

here is an improved MemCopy(), with the same parameter list as Move().

procedure MemCopy(const src; var dest; size: SizeInt);
begin
  Move(src, dest, size);
end;

-
Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Vincent Snijders
to Marco van de Voort: In our previous episode, Graeme Geldenhuys said: Historical reasons apparantly. I've no…
Marco van de Voort wrote 6 lines
In our previous episode, Graeme Geldenhuys said: >> No. > So why is the function called MOVE instead of COPY? :-) Historical reasons apparantly.

I never thought that
mov ax, bx (8086 assembler)
would clear the register after the move.

So I never thought that move would clear the memory (or leave it in a undefined state).

Vincent

Florian Klaempfl
to Graeme Geldenhuys: 2009/9/29 Florian Klaempfl : I thought simple pointer arithmetic would solve the issue of…
Show quoted text 13 lines
2009/9/29 Florian Klaempfl : > Indeed, the serious answer is: > move handles overlapping memory blocks correctly (so the data might not > existing anymore at the old location), memcpy doesn't do this and screws > things up when handling overlapping blocks. This is why e.g. C++ has > memmove as well which is more expensive than memcpy due to overlap checks. I thought simple pointer arithmetic would solve the issue of memcpy()? Anyway, so based on your answer, if we apply the following code (shown belowe) to FPC, we have the best of both worlds! :-) MemCopy() does exactly what Move() does - but without the name confusion. :-)

It does not. MemCopy is simpler and because of the missing overlapping checks, it as faster and it can be often inlined.

Show quoted text 22 lines
Could this "alias" procedure be applied somewhere in FPC? This was done before - the case of AssignFile() vs Assign() procedure MemCopy(src, dest: pointer; size: SizeInt); begin Move(src^, dest^, size); end; Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Graeme Geldenhuys
to Vincent Snijders: I never thought that mov ax, bx (8086 assembler) would clear the register after the move.…

2009/9/29 Vincent Snijders :

I never thought that mov ax, bx (8086 assembler) would clear the register after the move.

If you put it like that, it never (for some strange reason) confused be either. :-) I guess that's probably because everything in assembler confused me, so nothing stood out above the rest. ;-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hans Mårtensson
to Graeme Geldenhuys
Graeme Geldenhuys wrote 14 lines
2009/9/29 Vincent Snijders : >I never thought that >mov ax, bx (8086 assembler) >would clear the register after the move. > > If you put it like that, it never (for some strange reason) confused be either. :-) I guess that's probably because everything in assembler confused me, so nothing stood out above the rest. ;-)

Move was used in assembler code of the first Intel processors and has then moved on (!) into later programming languages. It is indeed confusing, because we are talking about information, which is not located like physical objects. Hence move is meaningless. If you make a photocopy, a new representation of the information is made and the paper is moved through the maschine, but it makes no sense to say that the information is moved.
Yet more confusing, I think, was that the old
mov a, b (8080 assembler)
normally was understood as "move b into a".
A better translation would be "make a copy in a of b". So I would say about the use of move: It's not logic, it's tradition.

Hans Maartensson