GameHunter писал(а):
По этому я предлагаю инлайн процедуры помечать этими атрибутами: static inline __attribute__((always_inline))
Но это же нестандартный атрибут GCC? Мы не можем предполагать, что компилятор всегда GCC. Нам нужна поддержка разных Си-компиляторов.
Однако я могу обернуть inline в макрос __INLINE, и там уже прописывайте чего хотите. Сделать? Но это доп. возможности накуролесить, если прописать в этом макросе что-то криво. Опять же, а static тоже вынести в реализацию этого макроса или дописывать этот атрибут дополнительно? Потому что без static получится совсем другая логика inline, а inline в Си и так довольно уродский.
GameHunter писал(а):
А если раскомментировать строчку в операторе CASE, - то выдаётся ошибка case range too large.
Это не ошибка, а особенность реализации. CASE имеет свои накладные расходы. Я, впрочем, не уверен, что такой разброс скомпилируется на некоторых Оберонах.
IntConst = 0C00000FDH = -1073741571
Т.е. Вы пытаетесь задать диапазон -1073741571..1, и выигрыша здесь от CASE вообще никакого не будет. Смысл CASE — в оптимизации ветвлений при небольших диапазонах. А в данном случае лучше обойтись IF.
Вы знаете как скомпилируется в Ofront'е CASE ch OF 20X..7FX ? Проверьте, будете разочарованы. Если Вам это кажется уродливым, то вспомним сам смысл CASE — оптимизировать переходы в машинном коде при помощи небольшой таблички. А если сделать реализацию CASE через if вместо switch/case, то это будет просто синтаксический сахар и косметика над if, и мы потеряем смысл эффективного CASE.
GameHunter писал(а):
При компиляции для 64-битной windows, невозможно выделить больше 2 Гб памяти при помощи оператора NEW, и невозможно объявить переменную с размером больше 2 Гб. Это планируется как-нибудь исправить?
Не планируется. Так как:
1. При принудительном изменении типа для задания размера памяти (в NEW, а также в индексах массивов) на LONGINT мы потеряем совместимость, потеряем возможность собирать программу с одного исходника для 32 и 64 бит. А на это делается упор. Напоминаю, мы не сможем сочетать индексы INTEGER для малого размера массивов и LONGINT для большого. Нет. Нам вместо этого придётся все индексы перевести на LONGINT, потому что мало ли сколько выделит пользователь через NEW. И так мы серьёзно присадим эффективность работы с массивами, а в случае 32-битных ОС её вообще бессмысленно убьём.
А Вы видите способ увеличить вместимость переменной INTEGER до > MAX(INTEGER) [>2 Гб]?
2. Я делал некоторые зачатки 64-битных индексов, в SYSTEM и OPM даже есть параметр SYSTEM_ARRLEN (OPM.IndexSize), но пришлось здесь отказаться от 64-битности, иначе всё получается слишком уродливо. Много нужно ломать старого кода, понимаете? И не факт, что результат нас порадует.
3. В BlackBox также нет возможности выделить такой огромный объём памяти. А кто мешает работать с большими объёмами памяти по частям? Зачем такой огромный непрерывный кусок? Это малоэффективно, так как сильно нагружает память. Лучше работать с таким объёмом кусками, а не непрерывно. Например, через список, каждый элемент которого будет иметь указатель на кусок памяти и ссылку на следующий элемент. Так ОС хотя бы сможет размещать эту память не непрерывно одним куском, а произвольно. Впрочем, я не уверен, что сборщик мусора Ofront/Ofront+ вообще даст использовать такие большие объёмы даже по частям. Это надо кому-то проверить.
4. В Ofront'е+ есть возможность подключить библиотеку или вызвать кусок кода на Си (кодовую вставку), которые организуют работу с огромным массивом [> 2 Гб] в памяти. С учётом того, что задача работать с такими огромными объёмами узко специфична, это не самое плохое решение.
5. Наконец, Вы сами можете сделать свою правку в Ofront+, и если сделаете всё красиво и ничего не сломаете — мы её интегрируем. Очевидно, для 32-бит стоит оставить индексы INTEGER, а для 64-бит сделать их LONGINT.
Вход
FAQ
Поиск
