Forum unknown
· Programming
#lattice C
23 messages in this thread
movmem? That's an arcane way to do it! How about strcpy(string, "string");
, which is not only simpler but also makes sure the terminating null is
present in the destination string, which it would not have been in your
example unless the '6' was changed to a '7'?
If you want to settle for slow, use strcpy! I'll stick with movmem.
>If you want to settle for slow, use strcpy! I'll stick with movmem
I don't understand why strcpy is slower than movmem (at least to the
noticible range – I don't want to count cycles, but they'd be close). At
least with Lattice 4.0, both of these are 'builtin' functions that generate
similar inline loops to perform the moves. Strcpy is definitely more
'friendly' when using strings, since the programmer doesn't have to count
the number of characters in the source string (and remember to add 1 to
insure that the terminating null was copied). And the 'right' way to count
the length of the source string is to use the strlen() function, which will
then increase the time taken / instructions executed to perform the move.
movmem() will work (with the above caveat), but strcpy() is definitely a
better choice unless the source field is not known to be a null-terminated
string.
Thanks ok Bob, do it your way and be slow. Try counting the cycles
sometimes. With a strcpy you have to do a check on every character to see
if it's a null. strlen() is also slow. String handling is not a a part of
the C language. It's an add-on via the "standard libraries". Using them
may make it easier on the novice, but if you want speed and efficiency, do
it yourself.
Hmm. I think your assumptions need a spring-cleaning, Steve. Here's the
loop from the Aztec strcpy:
loop move.b (a1)+,(a0)+
bne loop
The whole function consists of that loop plus three instructions to set up
the two address registers and d0 for the return value (the address of the
target string), plus an rts. Though I don't propose to verify it right now,
I strongly suspect that strcpy is _faster_ than movmem, not slower. Plus
there's less setup (two args instead of movmem's three, and you don't need
to worry about the length of the string, provided you know it will fit in
the destination buffer).
The same goes for the other standard C string-handling functions – they're
fast and tight, and it generally pays to use them. Of course, if you're
moving kilobytes of text around, or if there is the possibility of the
target string and the source string overlapping (with the target string
higher in memory), movmem starts to look better. But neither of those is
the general case.
Of course, if you _like_ doing it the hard way… 🙂
Hehehe — ok — guess I was incorrect. I never looked at it on the Amiga.
With Lattice 3.xx on the PC, movmem was faster.
But wasn't that the same version of Lattice that generated a subroutine
call to cast a pointer to an int? 🙂
hehehehe — could be. I'd check, but after I got the 2000 my MS-DOS box
went into the basement and I see no reason to stick MS-DOS Lattice on the
bridgeboard.
hehehehe — could be. I'd check, but after I got the 2000 my MS-DOS box
went into the basement and I see no reason to stick MS-DOS Lattice on the
bridgeboard.
But wasn't that the same version of Lattice that generated a subroutine
call to cast a pointer to an int? 🙂
Hehehe — ok — guess I was incorrect. I never looked at it on the Amiga.
With Lattice 3.xx on the PC, movmem was faster.
Hmm. I think your assumptions need a spring-cleaning, Steve. Here's the
loop from the Aztec strcpy:
loop move.b (a1)+,(a0)+
bne loop
The whole function consists of that loop plus three instructions to set up
the two address registers and d0 for the return value (the address of the
target string), plus an rts. Though I don't propose to verify it right now,
I strongly suspect that strcpy is _faster_ than movmem, not slower. Plus
there's less setup (two args instead of movmem's three, and you don't need
to worry about the length of the string, provided you know it will fit in
the destination buffer).
The same goes for the other standard C string-handling functions – they're
fast and tight, and it generally pays to use them. Of course, if you're
moving kilobytes of text around, or if there is the possibility of the
target string and the source string overlapping (with the target string
higher in memory), movmem starts to look better. But neither of those is
the general case.
Of course, if you _like_ doing it the hard way… 🙂
Thanks ok Bob, do it your way and be slow. Try counting the cycles
sometimes. With a strcpy you have to do a check on every character to see
if it's a null. strlen() is also slow. String handling is not a a part of
the C language. It's an add-on via the "standard libraries". Using them
may make it easier on the novice, but if you want speed and efficiency, do
it yourself.
>If you want to settle for slow, use strcpy! I'll stick with movmem
I don't understand why strcpy is slower than movmem (at least to the
noticible range – I don't want to count cycles, but they'd be close). At
least with Lattice 4.0, both of these are 'builtin' functions that generate
similar inline loops to perform the moves. Strcpy is definitely more
'friendly' when using strings, since the programmer doesn't have to count
the number of characters in the source string (and remember to add 1 to
insure that the terminating null was copied). And the 'right' way to count
the length of the source string is to use the strlen() function, which will
then increase the time taken / instructions executed to perform the move.
movmem() will work (with the above caveat), but strcpy() is definitely a
better choice unless the source field is not known to be a null-terminated
string.
If you want to settle for slow, use strcpy! I'll stick with movmem.
Nope, there would be no null unless you did a string[6] = 0; Again, you can
use strcpy if you want to pay a large speed penalty. I wouldn't use it for
any app that's text manipulation intensive.
Not much difference between movmem and strcpy with manx, anyway. Certainly
not a 'large speed penalty'. sdb
If the app is text manipulative intensive you pay a speed and size penalty
not the mention the overhead of the library.
Well, I disagree, movmem() is also in the library, BTW. A typical
implementation of strcpy() on a 68000 would be
lab: move.b (a0)+,(a1)+
bne.s lab
This compares favorably with:
lab move.b (a0)+,(a1)+
dbra d0,lab
which also restricts you to copies less than 64k in size. You could do
something like:
move.l d0,d1
swap d1
bra lab2
lab move.b (a0)+,(a1)+
lab2 dbra d0,lab
dbra d1,lab
which would be quite quick, but I still maintain strcpy() as shown above
compares favorably with the dbra versions of memcpy(), especially if you
add in the extra instructions needed for stuffing a null at the end on the
return.
Well, I disagree, movmem() is also in the library, BTW. A typical
implementation of strcpy() on a 68000 would be
lab: move.b (a0)+,(a1)+
bne.s lab
This compares favorably with:
lab move.b (a0)+,(a1)+
dbra d0,lab
which also restricts you to copies less than 64k in size. You could do
something like:
move.l d0,d1
swap d1
bra lab2
lab move.b (a0)+,(a1)+
lab2 dbra d0,lab
dbra d1,lab
which would be quite quick, but I still maintain strcpy() as shown above
compares favorably with the dbra versions of memcpy(), especially if you
add in the extra instructions needed for stuffing a null at the end on the
return.
If the app is text manipulative intensive you pay a speed and size penalty
not the mention the overhead of the library.
Not much difference between movmem and strcpy with manx, anyway. Certainly
not a 'large speed penalty'. sdb
Nope, there would be no null unless you did a string[6] = 0; Again, you can
use strcpy if you want to pay a large speed penalty. I wouldn't use it for
any app that's text manipulation intensive.