Почему в C/C++/rtl нет функциональности Z80, подобной LDIR?

Я считаю, что это соответствует философии дизайна C и C++. Как Бьярн Страуструп один раз сказал, один из основных руководящих принципов разработки C++: "Что вы не используете, вы не платите за то, за что вы не платите". И хотя Деннис Ричи, возможно, сказал это не совсем теми же словами, я считаю, что принцип, лежащий в основе его дизайна C (и дизайна C последующими людьми). Теперь вы можете подумать, что если вы выделяете память, она должна автоматически инициализироваться значением NULL, и я склонен с вами согласиться. Но это требует машинных циклов, и если вы кодируете в ситуации, когда каждый цикл имеет решающее значение, это может быть неприемлемым компромиссом. В основном C и C++ стараются держаться подальше от вас, поэтому, если вы хотите что-то инициализировать, вы должны сделать это самостоятельно.

memmove и memcpy не работают таким образом, потому что это бесполезная семантика для перемещения или копирования памяти. В Z80 удобно иметь возможность заполнять память, но почему вы ожидаете, что функция с именем «memmove» заполнит память одним байтом? Это для перемещения блоков памяти. Это реализовано для получения правильного ответа (байты источника перемещаются в место назначения) независимо от того, как перекрываются блоки. Это полезно, чтобы получить правильный ответ для перемещения блоков памяти.

Если вы хотите заполнить память, используйте memset, который предназначен именно для того, что вам нужно.

Был более быстрый способ очистить область памяти с помощью стека. Хотя использование LDI и LDIR было очень распространенным, Дэвид Уэбб (который продвигал ZX Spectrum всевозможными способами, такими как обратный отсчет чисел в полноэкранном режиме, включая границу) придумал эту технику, которая работает в 4 раза быстрее:

• сохраняет указатель стека, а затем перемещает его в конец экрана.
• ЗАГРУЖАЕТ пару регистров HL нулем,
• переходит в массивный цикл, ПУШЯ HL в стек.
• Стек перемещается вверх по экрану и вниз по памяти, очищая при этом экран.

Объяснение выше взято из обзора игры Дэвида Уэбба Starion.

  DI              ; disable interrupts which would write to the stack.
  LD HL, 0
  ADD HL, SP      ; save stack pointer
  EX DE, HL       ; in DE register
  LD HL, 0
  LD C, 0x18      ; Screen size in pages
  LD SP, 0x4000   ; End of screen
PAGE_LOOP:
  LD B, 128       ; inner loop iterates 128 times
LOOP:
  PUSH HL         ; effectively *--SP = 0; *--SP = 0;
  DJNZ LOOP       ; loop for 256 bytes
  DEC C
  JP NZ,PAGE_LOOP
  EX DE, HL
  LD SP, HL       ; restore stack pointer
  EI              ; re-enable interrupts

LOOP:
   PUSH HL
   PUSH HL
   ...
   PUSH HL         ; repeat 128 times
   DEC C
   JP NZ,LOOP

Несомненно, техника неоднократно изобреталась заново. Например, ранее он появлялся в Симулятор полета 1 компании sub-Logic для TRS-80 в 1980 году.

Почему так себя ведут memmove и memcpy?

Возможно, потому, что не существует специального современного компилятора C++, ориентированного на аппаратное обеспечение Z80? Напишите один. ;-)

Языки не определяют, как данное оборудование реализует что-либо. Это полностью зависит от программистов компилятора и библиотек. Конечно, написание собственной строго определенной версии для каждой мыслимой аппаратной конфигурации требует большой работы. Это будет причиной.

Есть ли разумный способ выполнить такую ​​инициализацию массива? Есть ли разумный способ выполнить такую ​​инициализацию массива?

Что ж, если ничего не помогает, вы всегда можете использовать встроенную сборку. Кроме этого, я ожидаю, что std::fill будет работать лучше всего в хорошей реализации STL. И да, я полностью осознаю, что мои ожидания слишком высоки и что std::memset часто работает лучше на практике.

Показанная вами последовательность Z80 была самым быстрым способом сделать это в 1978 году. Это было 30 лет назад. Процессоры сильно продвинулись с тех пор, и сегодня это едва ли не самый медленный способ сделать это.

Memmove предназначен для работы, когда диапазоны источника и назначения перекрываются, поэтому вы можете переместить фрагмент памяти на один байт вверх. Это часть его поведения, определенного стандартами C и C++. Memcpy не указан; он может работать идентично memmove или отличаться, в зависимости от того, как ваш компилятор решит его реализовать. Компилятор может выбрать более эффективный метод, чем memmove.

Если вы возитесь на аппаратном уровне, то некоторые ЦП имеют контроллеры DMA, которые могут чрезвычайно быстро заполнять блоки памяти (намного быстрее, чем когда-либо мог бы ЦП). Я сделал это на процессоре Freescale i.MX21.

Это можно сделать в сборке x86 так же легко. Фактически, это сводится к почти идентичному коду вашего примера.

mov esi, source    ; set esi to be the source
lea edi, [esi + 1] ; set edi to be the source + 1
mov byte [esi], 0  ; initialize the first byte with the "seed"
mov ecx, 100h      ; set ecx to the size of the buffer
rep movsb          ; do the fill

Однако просто более эффективно устанавливать более одного байта за раз, если вы можете.

Наконец, memcpy/memmove - это не то, что вам нужно, они предназначены для копирования блоков памяти из одной области в другую (memmove позволяет источнику и месту назначения быть частью одного и того же буфера). memset заполняет блок байтом по вашему выбору.

Существует также calloc, который выделяет и инициализирует память до 0 перед возвратом указатель. Конечно, calloc инициализируется только 0, а не тем, что указывает пользователь.

Если это наиболее эффективный способ установить для блока памяти заданное значение на Z80, то вполне возможно, что memset() может быть реализовано, как вы описываете, в компиляторе, ориентированном на Z80.

Возможно, memcpy() также может использовать аналогичную последовательность в этом компиляторе.

Но почему компиляторы, предназначенные для процессоров с совершенно отличными от Z80 наборами инструкций, должны использовать идиому Z80 для таких вещей?

Помните, что архитектура x86 имеет аналогичный набор инструкций, перед которыми может стоять код операции REP, чтобы они выполнялись повторно для выполнения таких действий, как копирование, заполнение или сравнение блоков памяти. Однако к тому времени, когда Intel выпустила 386 (или, может быть, это была 486), процессор фактически выполнял эти инструкции медленнее, чем более простые инструкции в цикле. Поэтому компиляторы часто отказывались от использования инструкций, ориентированных на REP.

Серьезно, если вы пишете на C/C++, просто напишите простой цикл for и позвольте компилятору побеспокоиться за вас. В качестве примера, вот некоторый код VS2005, сгенерированный именно для этого случая (с использованием шаблонного размера):

template <int S>
class A
{
  char s_[S];
public:
  A()
  {
    for(int i = 0; i < S; ++i)
    {
      s_[i] = 'A';
    }
  }
  int MaxLength() const
  {
    return S;
  }
};

extern void useA(A<5> &a, int n); // fool the optimizer into generating any code at all

void test()
{
  A<5> a5;
  useA(a5, a5.MaxLength());
}

Вывод ассемблера следующий:

test PROC

[snip]

; 25   :    A<5> a5;

mov eax, 41414141H              ;"AAAA"
mov DWORD PTR a5[esp+40], eax
mov BYTE PTR a5[esp+44], al

; 26   :    useA(a5, a5.MaxLength());

lea eax, DWORD PTR a5[esp+40]
push    5               ; MaxLength()
push    eax
call    useA

Это не более эффективно. Перестаньте беспокоиться и доверьтесь своему компилятору или, по крайней мере, посмотрите, что выдает ваш компилятор, прежде чем пытаться найти способы оптимизации. Для сравнения я также скомпилировал код, используя std::fill(s_, s_ + S, 'A') и std::memset(s_, 'A', S) вместо цикла for, и компилятор выдал идентичный результат.

Если вы используете PowerPC, _dcbz().

Существует ряд ситуаций, когда было бы полезно иметь функцию «memsread», определяемое поведение которой состояло в том, чтобы копировать начальную часть диапазона памяти во всем этом. Хотя memset() прекрасно работает, если целью является распространение одного байтового значения, бывают случаи, когда, например. можно захотеть заполнить массив целых чисел одним и тем же значением. Во многих реализациях процессора копирование побайтов из источника в место назначения было бы довольно неудобным способом реализации, но хорошо спроектированная функция может дать хорошие результаты. Например, начните с того, что посмотрите, меньше ли объем данных 32 байта или около того; если это так, просто сделайте побайтовую копию; в противном случае проверьте выравнивание источника и назначения; если они выровнены, округлить размер в меньшую сторону до ближайшего слова (если необходимо), затем скопировать первое слово везде, где оно идет, скопировать следующее слово везде, где оно идет, и т. д.

Иногда мне тоже хотелось, чтобы функция работала как восходящая memcpy, предназначенная для использования с перекрывающимися диапазонами. Что касается того, почему нет стандартного, я думаю, никто не подумал, что это важно.

memcpy() должно иметь такое поведение. memmove() не делает этого по дизайну, если блоки памяти перекрываются, он копирует содержимое, начиная с концов буферов, чтобы избежать такого поведения. Но чтобы заполнить буфер определенным значением, вы должны использовать memset() в C или std::fill() в C++, которые большинство современных компиляторов оптимизируют для соответствующей инструкции заполнения блока (например, REP STOSB на архитектурах x86).

Как было сказано ранее, memset() предлагает желаемую функциональность.

memcpy() предназначена для перемещения по блокам памяти во всех случаях, когда исходный и целевой буферы не перекрываются, или когда место назначения ‹ источник.

memmove() решает случай перекрытия буферов и назначения > источника.

В архитектурах x86 хорошие компиляторы напрямую заменяют вызовы memset встроенными инструкциями по ассемблеру, очень эффективно устанавливая память целевого буфера, даже применяя дальнейшие оптимизации, такие как использование 4-байтовых значений для заполнения как можно дольше (если следующий код не полностью синтаксически верен, виноват это из-за того, что я давно не использую ассемблерный код X86):

lea edi,dest
;copy the fill byte to all 4 bytes of eax
mov al,fill
mov ah,al
mov dx,ax
shl eax,16
mov ax,dx
mov ecx,count
mov edx,ecx
shr ecx,2
cld
rep stosd
test edx,2
jz moveByte
stosw
moveByte:
test edx,1
jz fillDone
stosb
fillDone:


На самом деле этот код гораздо более эффективен, чем ваша версия Z80, так как он не делает память в память, а только регистрирует перемещение памяти. Ваш код Z80 на самом деле является хаком, поскольку он основан на том, что каждая операция копирования заполняет источник последующей копии.

Если компилятор наполовину хорош, он может обнаружить более сложный код C++, который можно разбить на memset (см. пост ниже), но я сомневаюсь, что это действительно происходит с вложенными циклами, возможно, даже с вызовом функций инициализации.