- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
void *memcpy(void *__dest, __const void *__src, size_t __n)
{
int i = 0;
unsigned char *d = (unsigned char *)__dest, *s = (unsigned char *)__src;
for (i = __n >> 3; i > 0; i--) {
*d++ = *s++;
*d++ = *s++;
*d++ = *s++;
*d++ = *s++;
*d++ = *s++;
*d++ = *s++;
*d++ = *s++;
*d++ = *s++;
}
if (__n & 1 << 2) {
*d++ = *s++;
*d++ = *s++;
*d++ = *s++;
*d++ = *s++;
}
if (__n & 1 << 1) {
*d++ = *s++;
*d++ = *s++;
}
if (__n & 1)
*d++ = *s++;
return __dest;
}
Follow us!
а ты говоришь линукс
Не все ARM'ы умеют читать и писать невыровненные инты. Видимо, автор надеется на то, что гцц сам свернёт эти 8 копирований в одно большое, елси платформа умеет в невыровненный доступ.
З.Ы. Ну хотя, блоки в куче обычно выровнены. Так что хотя бы для них будет пошустрее копировать.
То тоже можно что-нибудь придумать, например читать uint32t_1, маской убрать четвертый байт, сдвинуть потом на 1 байт вправо (и сохраняем, этот байт нам потом понадобится) и записать в uint32t_3, после чего читаем uint32t_2, сдвигаем вправо на 8(сохранив опять-таки вытолкнутый байт), и тот старый байт что был сохранен на предыдущем этапе из uint32t_1 - мы его суем в старший байт этой хни, и потом записываем в uint32_4
А теперь дз: оптимизируем strlen
В uintptr_t всё-таки.
З.Ы. Хотя для этой задачи и uint8_t сойдёт.
Впрочем и там поинтер бывает и 32 и 16, забыл чтоли про дальние указатели?
ключ находится в названии директории файла: "arm/boot".
это часть бутстрапа, и к самому ядру линуха имеет мало отношения.
похоже на компромис между размером кода и производительностью.
типы из free-electrons умееют бенчить. они достаточно хорошо известны в кругах встроенного линукс/арм.
Тогда не будет ли вся эта магия с анроллом стрельбой из пушки по тараканам? Стоит ли все это городить ради куска, который проживёт пару-тройку миллисекунд, настроит окружение и сгорит в атмосфере?
копирование распаковоного кернела длится 100-500мс на мелких системах. почему бы и не сэкономить несколько десятков миллисекунд, если это и не так сложно?
и что значит "городить" - раз написал, и будет работать годами. это не код на котором все будут спотыкаются, или в нем что-то будет ломатся.
boot time на встроенных линух системах это проблема, и все что-то на эту тему предпринимают.
http://elinux.org/Boot_Time
Хоть бы скобочки расставили...
Линус запретил поди. Он же всегда выступал против агрессивных оптимизаций, которые ломают кривой код.