честно говоря, последний процессор, на котором я плотно работал с ассемблером, был не совсем стандартный, но смысл такой:
есть команда (приблизительно) rx0=[sp+<константа>], при чём константа должна быть известна на этапе сборки перевода в машинные коды

даже если такой команды нет, то наверняка можно писать так:
a=sp
a+=<константа>
b=[a]

ключевой момент - должен быть такой адрес в стеке, относительно которого можно уже на этапе компиляции сказать адреса всех локальных переменных, тогда есть блок кода для определения адреса, количество команд которого не зависит от количества и типа локальных переменных, и, подозреваю, во всех современных процессорах сейчас это можно делать одной командой

если у нас есть локальный массив переменной длины, то его начало относительно вершины стека компилятору уже неизвестно, да, можно выкрутиться, используя указатель на фрейм стека (не уверен в терминологии) - т.е. в стеке есть две точки, относительно одной из них начало массива имеет константный адрес, поэтому всё ещё хорошо

однако, это - одноразовое решение:
стоит нам добавить ещё один массив и смещение адреса начала второго массива относительно начала текущего фрейма будет зависеть от длины первого массива, а относительно вершины стека - от длины второго массива (ну ещё и от переменных, но их размеры известны), т.е. у нас уже не получается константности

дальше для обеспечения быстрого доступа ко второму массиву и переменным между этими массивами уже придётся либо записывать его адрес в какой-то регистр, либо сохранять его в памяти
первый вариант просто ужасен: регистры, если я не ошибаюсь, - дефицит, когда дело доходит до оптимизации
второй вариант - добавление уровня косвенности - тоже не очень хорошо, особенно, если среди таких переменных окажется несколько важных

ну а с ростом количества локальных массивов всё будет только ухудшаться - ведь начала их адресов нужно посчитать при входе в функцию

-------

некоторое пояснение:

я совсем не против такой возможности, более того - она, скорее всего, будет использована для замены динамической памяти, в которой затраты времени значительно больше всех вышеописанных, так что в этом смысле это - полжительное улучшение

просто, как мне кажется, не очень хорошо делать их расширением старых добрых массивов с длиной, известной на этапе компиляии, - две вещи, которые беглым взглядом не всегда отличишь, имеют довольно-таки серьёзное отличие

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

фууух... длинненько вышло 

Это сообщение отредактировал(а) maxim1000 - 6.6.2008, 20:46

maxim1000, 
так, объясняю упрощенно   

есть код

для реализации массивов переменной длины a, b, c, d представляют собой не массивы, а переменные-указатели, содержащие адреса массивов в стеке
i, j, k, q обычные целочисленные переменные
итого у нас есть 8 локальных переменных в main() общим размером 4 * sizeof(void*) + 4 * sizeof(int) = 32 + 16 = 48 (на 64-х разрядной системе)
для каждого блока кода (между { и }) в рамках функции, в котором определен массив переменной длины необходимо сохранять адрес текущей вершины стека (для раскрутки стека при выходе из блока)
в данном примере блок один, поэтому необходима еще одна локальная переменная-указатель t
48 + 8 = 56



Добавлено через 12 минут и 58 секунд

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

ох, как знал, как знал 
сначала писал про два массива потом сделал приписку:


может получиться такая ситуация:

так вот указателями станут не только a и b, но и, как это ни печально, i,j,k
причём самое плохое, что усложнение доступа к i произошло из-за свойств других переменных - неочевидность удваивается

нет
все локальные переменные размещаются в созданном при входе в функцию стековом фрейме   
т. е в данном случае a, b, n, m, i, j, k размещаются последовательно от [rsp] до [rbp] после декрементации rsp на 36

Это сообщение отредактировал(а) MAKCim - 6.6.2008, 22:19

ннда... про перемещение места под локальные переменные внутренних блоков наверх как-то не подумал
тогда, похоже, остаётся один аргумент про различия в использовании 
(невозможность использовать в структурах, sizeof)
так что всё равно мне кажется, что стоит это как-то по-другому было бы назвать, ввести какое-то визуальное отличие, а не одинаковую запись

P.S.
подумал про дополнительный такт при доступе к массивам: похоже и его не будет, ведь чаще всего к ним будут обращаться, итерируя указатели, а значит, дополнительная операция будет только при их инициализации, а значит, неважно...

maxim1000, с sizeof проблем тоже быть не должно. А вот в структурах использовать нельзя это точно.

ох... а тут как?
ведь sizeof люди привыкли передавать, куда угодно
например, в качестве аргументов шаблонов

можно пример, где ты это видел? возможно всё, но я как-то не припомню...

семантика sizeof нарушается

не, я такого не видел, но учитывая, какие вещи делают на C++, сильно сомневаюсь, что такого ни у кого нету

честно говоря, про sizeof сейчас в голову не приходит, но вот про сам тип такой конструкции вспомнилось, как шаблонами определяли длину массива
так вот там использовалось, что массив из 10-ти int-ов имеет тип int[10], а не просто указатель, и этим пользовались при определении размера

Да, но этим можно пользоваться при массивах константной длины. Конечно, руки всем не открутишь - найдутся те, которые обязательно сделают не так