Я понимаю, что возможно у меня фраза «сквозные процедуры» прижилась ещё с детства, я их тогда так назвал. Допустим, чисто как пример, у нас есть что-то откуда мы берём стрим данных, например это модем по UART'у, допустим что у нам надо принять байт и его обработать, например разобрать АТ команды. Вызов такой процедуры будет в цикле:
LOOP ...что-то
CALL PARS_MODEM
...что-то
JP LOOP
Вот процедура PARS_MODEM будет всегда однопроходная. В ней будет хранится текущая позиция исполнимого кода, и там никогда не будет циклов. Да же не текущая позиция кода, а текущее полодение в наборе мелких участков кода. Пришёл байт, проверили закончил ли он строку, нет, вышли, если да, проверили строку, вышли. Вошли снова, проверили что надо сделать со строкой, если ответить, ответили, вышли, переключили снова в ожидание окончания строки. Таким образом если у меня будет 10 модемов, то процедура PARS_MODEM, будет вызвана 10 раз, но со ссылкой на описание нужного UARTа, или другого интерфейса. то есть в таких процедурах допускается выполнение чего-то ёмкого, но крайне редко, или эти ёмкие части кода будут исполняться поэтапно, что бы вылетать из процедуры и давать работать соседней процедуре.
Спасибо, я примерно так и думал, но опасался что-то упустить из вида.
У меня только одно ограничение, которое я как-нибудь обязательно разрешу: сейчас у меня в скрипте блокирующие команды перемешаны с неблокирующими. Это не очень существенное ограничение, но оно означает, что во время распаковки (блокирующая команда) я не могу фиксить эффекты (там команды короткие, по сути, не блокирующие). Скорее всего, я решу эту проблему выносом неблокирующих команд, или даже целиком интерпретатора скрипта, в обработчик прерываний, что можно интерпретировать, с небольшой натяжкой, как третий поток. Но пока что не было ещё ситуации, чтобы мне РЕАЛЬНО захотелось это сделать.
А что ты называешь сквозными процедурами? Я не слышал раньше такой термин.
Лёша, но это честные потоки. В данном примере количество потоков ограничено до четырёх. В этих потоках только нет MUX'ов, а остальное всё по классике жанра.
Примеры привести очень сложно, по скольку у меня львиная доля работ это демка. А тут за всю историю я не нуждался в более чем двух потоков, просто это не нужно. Что для демки надо? На заднем плане что-то считать и контролировать логику на переднем плане, ну а на прерываниях показывать эффекты. Вообще я давно не использовал потоки, по скольку мне приятнее сквозные процедуры, и если бы не SYNCHRONIZATION и gift WAYHACK, я бы не вспомнил о них.
Вот в WAYHACK на первом потоке происходит расчёт эффекта, а на втором потоке печатается текст, рассчитываются координаты букв, создаётся предварительная анимация.
В SYNCHR'е потоки пускаются в части с иконками и летающем кубике. Пока все смотрят на выпадающего Бина, в соседнем потоке подготавливается куб.
Ещё эти потоки, и это было впервые со страницами, были сделаны в игре WonderLust, там пока кто-то смотрит интро, выбирает какими клавишами играть, — на втором потоке генерируется лабиринт.
Прости, но в тематике Speccy, сложно применять более серьёзно потоки, ведь мы все привыкли писать код так, что бы он по сути не требовал потоков. Лёша, просто ты это прошёл, поэтому тебе проще использовать то, что у тебя наработано. И ты прав, я начиная с игры WonderLust не усложнял потоки, просто не нужно больше. Вообще когда я впервые встретился с потоками, увидел, что в большинстве случаев люди(PC) их пихают в местах где это ну совсем не надо.
Поэтому, да более чем два потока я не вижу применений.
Довольно прикольно, но настолько актуальна именно «честная» многопоточность на спектруме? Все мои ядра начиная с Down по сути двухпоточные, в том смысле, что ядро может исполнять код (запирающий) в как бы основном процессе, а практически вся риалтаймовая визуализация сделана у меня обычно вызовом из прерывания, т.е. неким независимым тредом. То есть у меня совершенно обычное дело показывать эффект (в прерывании) и распаковывать что-то используя остатки времени во фреймах.
Наверное, это какой-то вышел мутный вопрос. Вот чёткий вопрос: приведи, пожалуйста, 2-3 (можно больше!) примера, желательно из своих дем, где ты реально совмещаешь несколько потоков (т.е. больше двух), чтобы нам лучше понять, какого рода удобства это предоставляет в работе. Пойми правильно, я тебя не критикую; процессы переключения контекстов у тебя выглядят очень знакомо, довольно похоже на то, что пришлось закодить в ядре мне. Но хочется чётко понять возможную мотивацию дальнейшего усложнения ядра.
Ура, Хедж! Добро пожаловать сюда)
Получилось у вас рассказать очень хорошо, вот например мы с Интроспеком поняли по-разному, но в ключевых моментах сошлись.
И я совсем не против того, чтобы кто-то был против текста) Я наоборот за, и я ещё недавно выше по тексту это же Натсу доказывал! Замечательно, когда в демах нет текста — я обожаю это! Я очень люблю, когда история рассказывается образами и атмосферой. Единственное, что я не очень люблю — сопоставление этих двух подходов и выявление лучшего из них. Всё достигается комбинацией, волшебной таблетки не существует.
В общем, больше дем хороших и разных! Давайте делать демы так хотим и умеем, а потом смотреть их, любить их, и дружить друг с другом!
Schafft очень много вложился, он был режиссером демы. По поводу текста — я тоже был против, но потому что это такой challenge — рассказать сюжет без текста. Не могу судить насколько хорошо это получилось (для меня она почти черный экран, столько раз прокручивал :), поэтому отзывы очень полезны.
Без него просто бы ничего не было. Ни самого сюжета, ни 3Д, ни анимации, ни самой демо. Он сердце группы. То что я слишком много «якаю», так это от того, что не могу говорить от лица всех участников. Но каждый из них очень много вложил. Я рассказал, то что именно я хотел реализовать в деме. Что хотели сделать Хедж, Н-кю и Дайвер — только им известно. Надеюсь они сами захотят поделиться своими мыслями от проекта.
Ну, не надо так реагировать на мои слова о текстах) За моими плечами несколько десятков стихов-песен и пара незаконченных никогда романов, плюс пара-тройка рассказов. Текст я не хотел использовать именно в своем визуальном искусстве, лично мне он кажется лишним. Я хотел сделать дему интернациональной в полной мере, не имеющую границ языкового барьера для восприятия. А искать легкие пути — это не наш метод) Иначе мы бы не обсуждали демо на Спектруме, именно в трудностях, преградах и в сорняках может появиться самый красивый цветок.
И нет, я не обижен, что мало кто понял происходящее на экране, я бы сам ничего не понял, ели бы не делал ее)
Вот процедура PARS_MODEM будет всегда однопроходная. В ней будет хранится текущая позиция исполнимого кода, и там никогда не будет циклов. Да же не текущая позиция кода, а текущее полодение в наборе мелких участков кода. Пришёл байт, проверили закончил ли он строку, нет, вышли, если да, проверили строку, вышли. Вошли снова, проверили что надо сделать со строкой, если ответить, ответили, вышли, переключили снова в ожидание окончания строки. Таким образом если у меня будет 10 модемов, то процедура PARS_MODEM, будет вызвана 10 раз, но со ссылкой на описание нужного UARTа, или другого интерфейса. то есть в таких процедурах допускается выполнение чего-то ёмкого, но крайне редко, или эти ёмкие части кода будут исполняться поэтапно, что бы вылетать из процедуры и давать работать соседней процедуре.
У меня только одно ограничение, которое я как-нибудь обязательно разрешу: сейчас у меня в скрипте блокирующие команды перемешаны с неблокирующими. Это не очень существенное ограничение, но оно означает, что во время распаковки (блокирующая команда) я не могу фиксить эффекты (там команды короткие, по сути, не блокирующие). Скорее всего, я решу эту проблему выносом неблокирующих команд, или даже целиком интерпретатора скрипта, в обработчик прерываний, что можно интерпретировать, с небольшой натяжкой, как третий поток. Но пока что не было ещё ситуации, чтобы мне РЕАЛЬНО захотелось это сделать.
А что ты называешь сквозными процедурами? Я не слышал раньше такой термин.
Примеры привести очень сложно, по скольку у меня львиная доля работ это демка. А тут за всю историю я не нуждался в более чем двух потоков, просто это не нужно. Что для демки надо? На заднем плане что-то считать и контролировать логику на переднем плане, ну а на прерываниях показывать эффекты. Вообще я давно не использовал потоки, по скольку мне приятнее сквозные процедуры, и если бы не SYNCHRONIZATION и gift WAYHACK, я бы не вспомнил о них.
Вот в WAYHACK на первом потоке происходит расчёт эффекта, а на втором потоке печатается текст, рассчитываются координаты букв, создаётся предварительная анимация.
В SYNCHR'е потоки пускаются в части с иконками и летающем кубике. Пока все смотрят на выпадающего Бина, в соседнем потоке подготавливается куб.
Ещё эти потоки, и это было впервые со страницами, были сделаны в игре WonderLust, там пока кто-то смотрит интро, выбирает какими клавишами играть, — на втором потоке генерируется лабиринт.
Прости, но в тематике Speccy, сложно применять более серьёзно потоки, ведь мы все привыкли писать код так, что бы он по сути не требовал потоков. Лёша, просто ты это прошёл, поэтому тебе проще использовать то, что у тебя наработано. И ты прав, я начиная с игры WonderLust не усложнял потоки, просто не нужно больше. Вообще когда я впервые встретился с потоками, увидел, что в большинстве случаев люди(PC) их пихают в местах где это ну совсем не надо.
Поэтому, да более чем два потока я не вижу применений.
Наверное, это какой-то вышел мутный вопрос. Вот чёткий вопрос: приведи, пожалуйста, 2-3 (можно больше!) примера, желательно из своих дем, где ты реально совмещаешь несколько потоков (т.е. больше двух), чтобы нам лучше понять, какого рода удобства это предоставляет в работе. Пойми правильно, я тебя не критикую; процессы переключения контекстов у тебя выглядят очень знакомо, довольно похоже на то, что пришлось закодить в ядре мне. Но хочется чётко понять возможную мотивацию дальнейшего усложнения ядра.
и не пришлось мучать random :)
Получилось у вас рассказать очень хорошо, вот например мы с Интроспеком поняли по-разному, но в ключевых моментах сошлись.
И я совсем не против того, чтобы кто-то был против текста) Я наоборот за, и я ещё недавно выше по тексту это же Натсу доказывал! Замечательно, когда в демах нет текста — я обожаю это! Я очень люблю, когда история рассказывается образами и атмосферой. Единственное, что я не очень люблю — сопоставление этих двух подходов и выявление лучшего из них. Всё достигается комбинацией, волшебной таблетки не существует.
В общем, больше дем хороших и разных! Давайте делать демы так хотим и умеем, а потом смотреть их, любить их, и дружить друг с другом!
Ура!)
Саня, мы тебя ждём!!!
И нет, я не обижен, что мало кто понял происходящее на экране, я бы сам ничего не понял, ели бы не делал ее)