Timeline for Hardware accelerated text processing
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:40 | history | edited | CommunityBot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Oct 12, 2015 at 5:35 | comment | added | Davislor |
On the 8086 and derivatives, as you know, C-style, null-terminated strings are supported in hardware by the instruction prefix repne. repne scasb is strlen() and repne movsb() is strcpy(). The rep prefix implements explicit-length strings and vectors. Either might or might not be faster than a loop on a given CPU. However, secure code today is supposed to bounds-check to avoid buffer overruns, and the shortcut doesn't do that.
|
|
| Dec 9, 2014 at 22:25 | vote | accept | toniedzwiedz | ||
| Dec 9, 2014 at 15:23 | comment | added | Jörg W Mittag |
I wouldn't be surprised to find out that string length follows a power law distribution, meaning that almost every string is only 1 to a few characters long, but there is a very small number of strings which are extremely long. If I look through some of my scripts and apps, the overwhelming majority of strings are literals such as "Y", "N", "Yes", "No", "Retry?" …
|
|
| Dec 9, 2014 at 9:48 | comment | added | James Anderson | Basic problem is that apart from the basic "copy" operation the string functions are mostly serial and do not lend themselves to parallelism. | |
| Dec 9, 2014 at 7:46 | history | edited | rwong | CC BY-SA 3.0 |
added 202 characters in body
|
| Dec 9, 2014 at 7:39 | history | answered | rwong | CC BY-SA 3.0 |