Хотел узнать, реально ли оптимизировать конструкцию switch/case, а именно диапазоны значений?
Хотел узнать, реально ли оптимизировать конструкцию switch/case, а именно диапазоны значений?
Если вопрос адресован мне, то не совсем понимаю, о чём ты.
В switch/case диапазон значений - это просто синтаксический сахар, на самом же деле для каждого значения из диапазона генерируется отдельная пара <значение>:<адрес перехода>. Если же нужно сравнение с одним непрерывным диапазоном значений, во многих случаях выгоднее будет использовать if со сравнением входного значения с крайними элементами диапазона. Эту оптимизацию ты имел в виду?
Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).
Стол заказов:
Мои работы:
Последний раз редактировалось ziggi; 01.12.2017 в 15:40.
Обычно компилятор анализирует код и генерирует ассемблерный листинг "на лету", т.е. полную информацию обо всех значениях для таблицы переходов (case) он будет знать только когда найдёт закрывающую фигурную скобку от switch - к тому моменту он уже сгенерирует инструкции AMX для всего кода внутри switch и только после этих инструкций оставит таблицу переходов. В принципе перед записью таблицы можно сделать анализ всех её значений и на основе принятого решения либо записать эту таблицу в обычном порядке, либо вместо неё вывести в листинг инструкции сравнения с крайними значениями диапазона и перехода, как для оператора if, заодно заменив инструкцию 'switch' (она генерируется перед содержимым конструкции switch) на 'jump' (операнд оставить прежним).
Это самая простая реализация, которую у меня получилось придумать, но даже после этого я очень сомневаюсь, что что-то подобное примут, по одной простой причине:
https://github.com/Zeex/pawn/issues/112
В сообществе SA-MP грязные хаки типа сканирования кода - достаточное основание, чтобы отказаться от тех или иных оптимизаций. Sad but true.
Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).
Стол заказов:
Мои работы:
Outsider (02.12.2017)
Вышла новая версия 3.10.5.
Изменения с прошлой версии:
- Ещё больше ускорена компиляция однородных массивов (#201).
- Добавлен оператор конкатенации "##" (#205).
- Улучшена реализация оператора "emit" (#211).
В новой версии исправлено несколько багов и недочётов, а также значительно переработан синтаксис оператора.
Подробнее о новом синтаксисе и преимуществах перед директивой #emit можно прочесть здесь: http://pro-pawn.ru/showthread.php?15830.- Теперь компилятор выдаёт ошибку при повторном объявлении одной и той же метки (#215).
Тем не менее, оператор конкатенации оказался недоработанным (issue #224), из-за чего компилятор неправильно работает с псевдо-оператором "extract" из инклуда sscanf2.inc, инклудами из YSI и прочим кодом, в котором в макросах используется сочетание "##".
Как результат, новый релиз компилятора не работает со многими модами.
Для временного исправления проблемы я подготовил свой "неофициальный" релиз.
Отличия от стандартного релиза 3.10.5:
- Удалён оператор конкатенации "##", из-за которого компилятор работал неправильно.
- Исправлено необоснованное использование 128 Мб ОЗУ под хеш-таблицу для глобальных символов, кол-во слотов снижено с 16'777'216 до 16384.
В ближайшее время я попробую открыть issue с обсуждением размера хеш-таблицы, но пока что оставлю эту временную меру для неофициального билда.- Применён патч для сборки с помощью Visual Studio 2010 (runtime-библиотеки VC++ 2010 более распространены, чем из 2012-го выпуска ==> меньше проблем с запуском компилятора).
Скачать: RGhost, Dropbox.
Исходный код: https://github.com/Daniel-Cortez/paw...e/experimental
Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).
Стол заказов:
Мои работы:
Следует отметить, что оператор конкатенации работал бы правильно, если бы правильно работал оператор #.
P.s. как PR вообще приняли?!
Точно так же, как и расточительство с 128 Мб ОЗУ под хеш-таблицу, наверное. У Zeex'а просто нет ни времени, ни мотивации возиться с новыми issue/PR. Собственно, он сам это признал, оставив сообщение о том, что больше не собирается продолжать работу над компилятором. Остаётся надеяться, что найдётся кто-нибудь, кто сможет взять на себя лидерство над проектом.
И да, за сегодня успела выйти ещё одна новая версия, 3.10.6, в которой уже нет оператора конкатенации, вызывавшего проблемы со многими модами, однако на странице релиза ссылок на бинарники нет, только исходники. По сути он ничем не отличается от моего билда в посте выше, разве что зависит он от рантайма VC++ менее распространённого 2012-го выпуска и не исправлен недочёт с расходом 128 Мб ОЗУ, поэтому я рекомендую всё же пользоваться неофициальным билдом.
Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).
Стол заказов:
Мои работы:
Неумение работать с сервисами продолжительной интеграции (Travis CI, AppVeyor), плохое представление о "внутренностях" компилятора (едва удалось недавно переделать оператор emit и (надеюсь) исправить в нём все баги), да и знание английского далеко не на высоте (могу делать переводы статей для форума, но на составление текстов на инглише всё ещё уходит много времени).
Не знаю, с чего вы это решили, но более подходящих кандидатов в сообществе ещё много. Например, сейчас репозиторий передан к Southclaws.
Да, но только потому что на нём базируется мой собственный форк Pawn, нацеленный на упрощение задачи по встраиванию интерпретатора в пользовательские приложения, а также устранение багов и уязвимостей в оном.
Я уже давно ничего не делаю в SA-MP, а потому и компилятором конкретно из репозитория Zeex'а не пользуюсь (вместо него юзаю тот, который в моём репо, хоть он и основывается на первом). Собственно, на том же своём форке и тестировал все патчи, которые потом пересылал в репо Zeex'а, ибо не было смысла держать их только у себя.
Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).
Стол заказов:
Мои работы:
Обновил до 3.10.6 и после у меня появляется это при компиляций:
это дебаг или что? до этого использовал стандартный 3.2Код:Header size: 19392 bytes Code size: 3012404 bytes Data size: 2701860 bytes Stack/heap size: 4492 bytes; estimated max. usage=1090 cells (4360 bytes) Total requirements: 5738148 bytes
Pro-pawn.ru
Эту тему просматривают: 4 (пользователей: 0 , гостей: 4)