Здравствуйте, merk, Вы писали:

N>>Ты сказал, что нормальные виртуальные машины не имеют такого ограничения. Можешь привести пример такой вируальной машины?

M>через пост от вашего, находится мое расуждение о верифицируемости.
M>оно вас не устраивает?

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

M>(к сожалению не понимаю как указать красиво ссылку на пост в топике)

Копируешь и вставляешь сюда.

Здравствуйте, merk, Вы писали:

M>создание и инициализация такого обьекта также верифицируемы(в силу верифицируемости создания обьекта).
M>итак создание фрейма — верифицируемо.
M>далее. фрейм всегда ассоциирован с некоей конкретной функцией и не может быть ассоциирован с другой(это было бы явным нарушением логики), это тоже верифицируемо, — функция должна получать фрейм как типизированный параметр(он не входит в фрейм — это параметр — "призрак"), проверка типа передачи параметров в функцию тоже д.б. если машина хочет заниматься верификацией. то есть это место тоже верифицируемо...
M>и что ж тогда не верифицируется?

Несколько вопросов...

1. Ты понимаешь, что рантайм дотнета одним из приоритетов (очень важным) считает быстродействие?
2. Понимаешь, что быстродействие можно достичь только проецируя инструкции ВМ на максимально эффективные для некоторой задачи инструкции процессора?
3. Понимаешь, что для сохранения фрейма любого вызова в виде объекта прийдется отказаться от использования инструкций вроде call/ret?

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

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

Здравствуйте, merk, Вы писали:

M>make_frame(f) //команда берет дескриптор f и по описанию локалов генерит и инициализирует фрейм, ссылка на слот помещается на стек, передаваясь функции. во фрейме есть поле — ссылка на дескриптор функции.
M>call_no_frame f; //это спецвызов — функция не генерит себе фрейм, а берет ссылку на него со стека, можно проверить, что ссылка на дескриптор функции во фрейме и в вызове — совпадают. также функция в теле, в прологе, может проверить, что ей дали ее фрейм. то есть фрейм типизирован в рантайме.
M>kill_frame; //ссылка на фрейм лежит на верхушке стека, берется оттуда и фрейм убивается.

Скромный вопрос. А насколько простым ты представляешь себе подобную реализацию?
Не будет ли она сложнее того же самого реализованного в компиляторе (по средствам проекции локальных переменных на поля генерируемого объекта и переписывания функции в ДКА)?

Здравствуйте, merk, Вы писали:

M>>>make_frame(f) //команда берет дескриптор f и по описанию локалов генерит и инициализирует фрейм, ссылка на слот помещается на стек, передаваясь функции. во фрейме есть поле — ссылка на дескриптор функции.

И как этот фрэйм передать другой функции в качестве параметра? Ведь итератор — это объект. Его можно и в поле положить, и функции передать.

Здравствуйте, VladD2, Вы писали:

VD>3. Понимаешь, что для сохранения фрейма любого вызова в виде объекта прийдется отказаться от использования инструкций вроде call/ret?
ИМХО call/ret инструкции паразитные и должны умереть.
Они навязывают соглашения о вызовах что не есть хорошо.
Путь лучше сделают больше регистров тогда очень многие хвостовые вызовы (включая косвенные) можно будет реализовать вобще не трогая стек.
А для большинства не хвостовых в стек будет падать только предыдущий адрес возврата.

VD>Насколько мне известно есть языки в которых реализованы континюэшоны по описанной тобой схеме. При этом эти языки или отказываются от хранения параметров в стеке или используют другие мало-эффективные механизмы.
Если хранить параметры в регистрах...

VD>В результате все они довольно существенно тормозят. Большинство рантаймов реализующих континюэшоны являются интерпретаторами. Именно по этому очень мне тоже очень хотелось услышать о виртуальной машине имеющей встроенные инструкции для реализации подобных фишек.
Итераторы это корутины. Не континюэйшены.
А корутины можно реализовать эффективно.
Ибо для их реализации не нужно копировать стек.
При запуске корутины нужно только создать новый стек.
Погляди хотя бы на вендовые фибиры. Это тоже корутины.

Здравствуйте, nikov, Вы писали:

N>Надо установить F# 1.9.4.19 и заглянуть в C:\Program Files\FSharp-1.9.4.19\source

А как вы пользутесь F#-ом если даже отладчик не работает?

Здравствуйте, AndrewVK, Вы писали:

AVK>Для managed компилятора особой необходимости скрывать исходники все одно нет.

А он появится? И когда?

Здравствуйте, VladD2, Вы писали:

AVK>>Для managed компилятора особой необходимости скрывать исходники все одно нет.

VD>А он появится? И когда?

А это я тебе не скажу. Потому что страшный секрет

Здравствуйте, VladD2, Вы писали:

VD>А он появится? И когда?

Точные сроки не объявлялись, но ты можешь сделать некотороые выводы из следующего:
1) Уже в .NET 3.5 в сборке System.Core есть код, умеющий компилировать выражения
2) Было объявлено, что в предполагаемой будущей версии C# планируется добавить динамический вызом методов, а это значит, что в рантайме будет работать управляемый код, которые умеет делать вывод типов, выбирать перегруженный метод и т.д.

Здравствуйте, WolfHound, Вы писали:

WH>Итераторы это корутины. Не континюэйшены.

Я видимо не вкуриваю разницу. Мог бы ты объяснить (без отсылок) чем, по-твоему, отличаются континюэшоны от корутинов?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Я не знаю, что понимается под "совершенно верифицируемой инструкцией", но подобное можно делать во многих Smalltalk-машинах. (Правда используется не стек, а список объектов — контекстов активации).

А ты проводил исследование на предмет скорости работы этих рантаймов? Большинство Смолтолковских машин интерпретаторы. Те же что что-то там оптимизируют, занимаются джитеньем отдельных вычислительных алгоритмов и, насколько мне известно, один фиг работают очень медленно.

Здравствуйте, merk, Вы писали:

M>какие компиляторы разрабатывает и продает ваша фирма?

Ну, ты тоже можешь похвататься. Я вот работал над R# и сейчас работаю над Nemerle. Продукты не коммерческие, но все же.

Здравствуйте, VladD2, Вы писали:

VD>Я видимо не вкуриваю разницу. Мог бы ты объяснить (без отсылок) чем, по-твоему, отличаются континюэшоны от корутинов?
Общего у них то что можно запомнить некуторую точку в потоке исполнения и потом продолжить выполнение с этой точки.
Разница в том что в случае с корутинами продолжить можно только один раз, а в случае с континюэйшенами произвольное колличество раз.
Те корутина это частный случай континюэйшена.

Здравствуйте, WolfHound, Вы писали:

WH>Общего у них то что можно запомнить некуторую точку в потоке исполнения и потом продолжить выполнение с этой точки.
WH>Разница в том что в случае с корутинами продолжить можно только один раз, а в случае с континюэйшенами произвольное колличество раз.
WH>Те корутина это частный случай континюэйшена.

Но тогда как раз итераторы легко доработать чтобы они удовлетворяли этому условию. Ведь все состояние хранится в объекте. Нужно просто реализовать клонирование (что можно даже через рефлексию сделать) и можно будет возобновлять их сколько угодно раз.

Здравствуйте, WolfHound, Вы писали:

Кстати, файберы это немного другое. Они ведь не могут ничего возвращать при приостановке, а корутины (наверно все же сопрограммы) и континюэшоны как раз именно на это и рассчитаны.

Здравствуйте, VladD2, Вы писали:

VD>А ты проводил исследование на предмет скорости работы этих рантаймов? Большинство Смолтолковских машин интерпретаторы. Те же что что-то там оптимизируют, занимаются джитеньем отдельных вычислительных алгоритмов и, насколько мне известно, один фиг работают очень медленно.

На сколько я знаю, при вычислениях JIT VW медленнее "обычного C++" в 3-5 раз. Т.е. меньше чем на порядок. Естественно, контексты активации мапяться на стек процессора и превращаются в объект только при необходимости (типа попытки чтения/записи контекста или для очистки процессорного стека при переполнении). Скорее всего, манипуляции со стеком (в грубом или в "облагороженном" виде a-la call/cc и shift/reduce) не реализованы только потому, что никто не думал, что такая фича понадобиться.

Что касается "абстрактой" скорости, то в форумах я время от времени видел ругань на скорость WPF, и есть такая штука как тормознутый GUI в Squeak. Squeak — читстый интерпретатор. WPF — статически типизируемый JIT. А результат — один Так что не всё то скорость, что в микро-бенчмарках

Здравствуйте, VladD2, Вы писали:

VD>Кстати, файберы это немного другое. Они ведь не могут ничего возвращать при приостановке, а корутины (наверно все же сопрограммы) и континюэшоны как раз именно на это и рассчитаны.
Это лечится очень тонкой надстройкой.
Обрати внимание на:

LPVOID CreateFiber(
  SIZE_T dwStackSize,
  LPFIBER_START_ROUTINE lpStartAddress,
  LPVOID lpParameter
);

lpParameter
[in] Pointer to a variable that is passed to the fiber. The fiber can retrieve this data by using the GetFiberData macro.

и

The GetFiberData macro returns the fiber data associated with the current fiber.

PVOID GetFiberData(void);

Через этот самый lpParameter можно организовать передачу чего угодно.
Могу продемонстрировать но мне лень код писать.

Здравствуйте, VladD2, Вы писали:

VD>Но тогда как раз итераторы легко доработать чтобы они удовлетворяли этому условию. Ведь все состояние хранится в объекте. Нужно просто реализовать клонирование (что можно даже через рефлексию сделать) и можно будет возобновлять их сколько угодно раз.
Еще раз: Re[11]: Чем вам всем не угодил Delphi?

Автор: WolfHound
Дата: 15.07.08

Там во второй половине поста написано где огребешь по полной...

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Что касается "абстрактой" скорости, то в форумах я время от времени видел ругань на скорость WPF, и есть такая штука как тормознутый GUI в Squeak. Squeak — читстый интерпретатор. WPF — статически типизируемый JIT. А результат — один

Да, сравнение в текущем контексте скорости на примере абсолютно разнотипного гуя, это сильно.

Здравствуйте, AndrewVK, Вы писали:

AVK>Да, сравнение в текущем контексте скорости на примере абсолютно разнотипного гуя, это сильно.

Это конечно не сравнение, а "feel" вместо научно обоснованной цифири. Но, как по мне — вполне допустимое. Его я привёл только потому, что вот народ считает крутизной вращающийся текст с градиентом и видео

Автор: gandjustas
Дата: 30.04.08

— возможности существующие в Squeak изначально.

А если "научничать", то нельзя даже Awt & WinForms сравнивать.