C++ для эхотажных систем

Sat Oct 09 2004 11:50, Dmitry Ponyatov wrote to All:

DP> а насколько эхотажные системы обеспечены компиляторами С++ (не С) с DP> полноценной реализацией ООП ?

Пока что я реально имел дело только с одним - Хитачевким компилятором для H8S. Однако его ++ мне были на фиг не нужны.

DP> пишу байт-кодовый движок (я тут уже постил вопрос по этой теме), DP> кажется DP> мне слишком рискованным завязываться на С++, хотя и удобнее на нем писать DP> чем на std C.

Чем удобнее? Я писал на чистом це, и особых неудобств не ощутил.

Пока, Алексей

Привет Dmitry!

DP> а насколько эхотажные системы обеспечены компиляторами С++ (не С) с DP> полноценной реализацией ООП ?

Процессоры, которые поддерживает gcc (например arm, avr) обеспечены C++ хорошо.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Даже лошадь Пржевальского может быть собакой Павлова.

Для ЧЕГО в реализации такого проекта, да еще на эхотаге, может понадобиться С++ да еще и с полноценной ООП? Ты что, байткод для Смоллтолка хочеш туда засунуть?

DP> слишком рискованным завязываться на С++, хотя и удобнее на нем писать DP> чем на std C.

AK> Чем удобнее? Я писал на чистом це, и особых неудобств не ощутил.

код становится более удобным для понимания, удобнее пользоваться библиотеками (если они есть, на С++), но как только начинаешь пользоваться динамическим распределением памяти и созданием/удалением объектов в рантайме, резко увеличивается оверхед (код работы с хипом), что для эхотажных приложений слишком дорого (я не имею в виду системы на "тяжелых" 16/32-битных процессорах естественно)

On 09/Oct/04 at 15:32 you write:

AM> Процессоры, которые поддерживает gcc (например arm, avr) AM> обеспечены C++ хорошо.

а не подскажете, кого можно закидать вопросами или какие исходники скачать, чтобы выяснить как заставить полностью работать ++, если я хочу написать что-то типа библиотеки для системы на x86 (просто с ней мне проще всего разбираться -- есть хороший эмуль bochs) ?

дело в том что стандартный код работы с хипом использовать не могу, прихоится пускать gcc с кучей ключиков типа --no-builtin чтобы собрался бинарник "ядра" (программки без ОС), и например не запускаются конструкторы глобальных объектов (определенных вне main)

PS: запахло оффтопиком -- может мне с этим убраться в другую эху ?

Привет Dmitry!

AM>> Процессоры, которые поддерживает gcc (например arm, avr) AM>> обеспечены C++ хорошо.

DP> а не подскажете, кого можно закидать вопросами или какие исходники DP> скачать, чтобы выяснить как заставить полностью работать ++, если я DP> хочу написать что-то типа библиотеки для системы на x86 (просто с ней DP> мне проще всего разбираться -- есть хороший эмуль bochs) ?

? Hичего не понял. Что значит "заставить полностью работать"? gcc поддерживает и x86 процессоры тоже.

DP> дело в том что стандартный код работы с хипом использовать не могу,

Что ты подразумеваешь под стандартным кодом?

DP> и например не DP> запускаются конструкторы глобальных объектов (определенных вне main)

Что значит "не запускаются"? Покажи, как ты их запускаешь и подробнее опиши симптомы (что именно происходит вместо запуска конструкторов глобальных объектов).

DP> PS: запахло оффтопиком -- может мне с этим убраться в другую эху ?

(втянув носом воздух) я ничего не чувствую. :)

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Пирожок тушеный с тушенкой.

AM> Что ты подразумеваешь под стандартным кодом?

start-up, менеджер памяти, возможно всякие там RTTI и тп

AM> Что значит "не запускаются"? Покажи, как ты их запускаешь

их должен запускать тот самый startup, мне их достаточно описать как глобальные (а не внутри той же _main)

AM> (втянув носом воздух) я ничего не чувствую. :)

ну если только в плане эхотага и кросс-разработки

Привет Dmitry!

AM>> Что ты подразумеваешь под стандартным кодом?

DP> start-up, менеджер памяти, возможно всякие там RTTI и тп

Стандарт на интерфейс (например те же malloc()/free()) - это да, есть такое, стандарта на реализацию - ИМХО нет. Для менеджмента памяти ты можешь использовать один из множества готовых существующих реализаций или написать свой собственный код. Более того, тебе может потребоваться использовать сразу несколько разных реализаций - например переопределяя operator new каких-то классов. У стартапа же (применительно к эхотагу) вообще нет никакого интерфейса, как правило, он получает управление после аппаратного сброса. Поэтому стартап в принципе не может быть "стандартным кодом", ибо кто кроме разработчика конкретного эхотажного устройства знает, какие действия необходимо выполнить для подготовки аппаратной среды, где разместить какие части кода и т.п.? Да, в составе всякоразных библиотек и компиляторов бывают готовые "типовые" стартапы, но использование в своей программе этого готового типового стартап-кода должно быть осознанным решением разработчика, равно как написание своего. Поэтому говорить о каких-то стандартах в этом контексте не вижу смысла.

AM>> Что значит "не запускаются"? Покажи, как ты их запускаешь DP> их должен запускать тот самый startup, мне их достаточно описать как DP> глобальные (а не внутри той же _main)

Hу так я об этом и говорю. Покажи как ты в своем стартапе вызываешь конструкторы глобальных объектов.

AM>> (втянув носом воздух) я ничего не чувствую. :) DP> ну если только в плане эхотага и кросс-разработки

А не в эхотаге вообще не должно быть таких проблем - все работает "из коробки". Если у тебя на PC не вызываются конструкторы, 99% за то, что ты что-то не так делаешь. Для более предметного разговора наверное ты должен показать пример кода, где не работают конструкторы, и как ты его собираешь...

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Северо-Кавказская межрегиональная ассоциация анонимных соискателей.

AM> Да, в составе всякоразных библиотек и компиляторов бывают готовые AM> "типовые" стартапы,

именно типовые, слово "стандартные" я явно неправильно использовал

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

AM> Покажи как ты в своем стартапе вызываешь AM> конструкторы глобальных объектов.

class BZZ { void a(); int b(int x,int y); public: BZZ(); ~BZZ(); } bzz_item;

// тут идет код всех BZZ:: методов

void main() { // инициализация и возьня с железом }

кажется понял в чем ошибка: main вызываю своим ассемблерным кодом, поэтому даже если компилер и создал вызов конструкторов, я их обхожу

по активному использованию ООП вопрос остается открытым -- нужны URLы примеров таких проектов

PS: для сборки использую gcc, примеры взял из фака os.development на megatokio

Привет Dmitry!

DP> про переопределение new и delete я уже где-то читал и меня это не DP> слишком беспокоит, но есть же еще всякие навороты типа таблиц DP> виртуальных методов, для руления которыми нужен свой код ?

Что ты понимаешь под рулением таблицами? Здесь компилятор все делает сам - и таблицы сооставляет, и нужные адреса из них выбирает когда надо. Я никогда "руками" (то есть из ассемблерных модулей) виртуальные методы объектов не звал.

AM>> Покажи как ты в своем стартапе вызываешь AM>> конструкторы глобальных объектов.

DP> class BZZ { [ skip ] DP> void main() DP> { DP> // инициализация и возьня с железом DP> }

Так это не стартап.

DP> кажется понял в чем ошибка: main вызываю своим ассемблерным кодом, DP> поэтому даже если компилер и создал вызов конструкторов, я их обхожу

Вот этот ассемблерный (как правило, но бывают исключения) модуль и есть стартап. Именно его я и хотел увидеть. Hу, раз выяснилось, что проблема именно в нем, расскажу, как должны вызываться конструкторы и деструкторы глобальных объектов (у меня в свое время тоже были с этим трудности, но почему-то никто не смог объяснить, пришлось разбираться самому). Сразу оговорюсь, нижеописанное справедливо для gcc3. Hе уверен, что это же справедливо для gcc2.

В каждом С++ модуле, где определяются глобальные объекты, имеющие конструкторы, компилятор генерит код вызова этих конструкторов и помещает указатель на точку входа в этот код инициализации в секцию .ctors. Аналогично генерится код вызова глобальных деструкторов и указатель на точку входа в него помещается в секцию .dtors. В стартапе ты должен вызвать код для всех этих модулей. Обычно это делается с помощью модулей crtbegin и crtend, например таких:

=========== crtbegin.c ========== typedef void (*fptr)(void);

static fptr ctor_list[1] __attribute__((section(".ctors"))) = { (fptr) -1 }; static fptr dtor_list[1] __attribute__((section(".dtors"))) = { (fptr) -1 };

void do_ctors(void) { fptr *fpp;

for(fpp = ctor_list + 1; *fpp != 0; ++fpp) ; while(--fpp > ctor_list) (**fpp)(); }

void do_dtors(void) { fptr *fpp;

for(fpp = dtor_list + 1; *fpp != 0; ++fpp) (**fpp)(); } ================================= ============ crtend.c =========== typedef void (*fptr)(void);

static fptr ctor_end[1] __attribute__((section(".ctors"), __unused__)) = { 0 }; static fptr dtor_end[1] __attribute__((section(".dtors"), __unused__)) = { 0 }; =================================

В линкерном скрипте секции .ctors и .dtors должны быть собраны таким образом, чтобы первым оказался crtbegin, последним crtend, а все остальное между ними, например так:

.ctors : { KEEP (*crtbegin.o(.ctors)) KEEP (*(EXCLUDE_FILE (*crtend.o ) .ctors)) /* все кроме crtend.o */ KEEP (*(.ctors)) /* оставшийся crtend.o */ } .dtors : { KEEP (*crtbegin.o(.dtors)) KEEP (*(EXCLUDE_FILE (*crtend.o ) .dtors)) KEEP (*(.dtors)) }

Дальше, надеюсь, объяснения излишни. Остается только в стартапе перед вызовом main() позвать do_ctors(), а после завершения main() - do_dtors(). Hаверняка в используемых тобой библиотеках вышеприведенное уже есть в том или ином виде, посмотри внимательно.

DP> по активному использованию ООП вопрос остается открытым -- нужны URLы DP> примеров таких проектов

Может лучше хорошую книжку с примерами почитать? Я литературу советовать не берусь, сам далеко не гуру... :) Хотя вот "С++ for Real Programmers" Элджера мне понравилась...

DP> PS: для сборки использую gcc, примеры взял из фака os.development на DP> megatokio

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Пирожок печеный с печенью.

для

поэтому

примеров

Здравствуйте.

Есть проект C++ для встроенной системы. Процессор Intel 386ex. Никакого БИОСа нет, не то что ДОСа. Транслятор BC5.02. Программа на C++ с активным использованием шаблонов. UCOS-II используется. Стартап свой, переделанный борландовский, инициализирует железо и умеет запускать конструкторы глобальных объектов. Деструкторы не умеет запускать, т.к. выхода в ДОС нет. Трансляция в несколько этапов: сначала в ассемблерный исходник, потом в объектник, потом линковка в ДОС-exe файл, потом обработка ДОС-exe файла самописным конвертором для превращения в загрузочный образ. Модель памяти huge. Куча не используется, все буфера распределены статически. Никакие стандартные библиотеки не используются, весь ввод-вывод переписан. От транслятора используется только кодогенерация. Наследование и виртуальные функции активно используются т.к. они не обращаются к ресурсам ОС.

Очень удобно работать на C++ с железом. Примеры: "порт вообще" это базовый класс. У него виртуальные методы "запись" и "чтение". COM порт это производный класс от "порт вообще". У него переопределяются методы записи и чтения. Два COM порта в процессоре это два экземпляра класса COM порта. Синхронный порт это тоже производный класс от "порт вообще". У него тоже переопределяются методы записи и чтения своими функциями. И так далее. После этого очень удобно передавать указатель на "порт вообще" в функции и вызывать в них вирт. функции ввода-вывода. Таким образом получаем канализацию ввода-вывода с поддержкой на уровне транслятора. Все это можно посмотреть на:

для

поэтому

примеров

Здравствуйте.

Есть проект C++ для встроенной системы. Процессор Intel 386ex. Никакого БИОСа нет, не то что ДОСа. Транслятор BC5.02. Программа на C++ с активным использованием шаблонов. UCOS-II используется. Стартап свой, переделанный борландовский, инициализирует железо и умеет запускать конструкторы глобальных объектов. Деструкторы не умеет запускать, т.к. выхода в ДОС нет. Трансляция в несколько этапов: сначала в ассемблерный исходник, потом в объектник, потом линковка в ДОС-exe файл, потом обработка ДОС-exe файла самописным конвертором для превращения в загрузочный образ. Модель памяти huge. Куча не используется, все буфера распределены статически. Никакие стандартные библиотеки не используются, весь ввод-вывод переписан. От транслятора используется только кодогенерация. Наследование и виртуальные функции активно используются т.к. они не обращаются к ресурсам ОС.

Очень удобно работать на C++ с железом. Примеры: "порт вообще" это базовый класс. У него виртуальные методы "запись" и "чтение". COM порт это производный класс от "порт вообще". У него переопределяются методы записи и чтения. Два COM порта в процессоре это два экземпляра класса COM порта. Синхронный порт это тоже производный класс от "порт вообще". У него тоже переопределяются методы записи и чтения своими функциями. И так далее. После этого очень удобно передавать указатель на "порт вообще" в функции и вызывать в них вирт. функции ввода-вывода. Таким образом получаем канализацию ввода-вывода с поддержкой на уровне транслятора. Все это можно посмотреть на:

Sat Oct 16 2004 10:20, Dmitry Ponyatov wrote to Alex Mogilnikov:

AM>> Да, в составе всякоразных библиотек и компиляторов бывают готовые AM>> "типовые" стартапы,

DP> именно типовые, слово "стандартные" я явно неправильно использовал

DP> про переопределение new и delete я уже где-то читал и меня это не DP> слишком беспокоит, но есть же еще всякие навороты типа таблиц виртуальных DP> методов, для руления которыми нужен свой код ?

AM>> Покажи как ты в своем стартапе вызываешь AM>> конструкторы глобальных объектов.

DP> DP> кажется понял в чем ошибка: main вызываю своим ассемблерным кодом, DP> поэтому даже если компилер и создал вызов конструкторов, я их обхожу

DP> по активному использованию ООП вопрос остается открытым -- нужны URLы DP> примеров таких проектов

DP> PS: для сборки использую gcc, примеры взял из фака os.development на DP> megatokio

для

поэтому

примеров

Здравствуйте.

Есть проект C++ для встроенной системы. Процессор Intel 386ex. Никакого БИОСа нет, не то что ДОСа. Транслятор BC5.02. Программа на C++ с активным использованием шаблонов. UCOS-II используется. Стартап свой, переделанный борландовский, инициализирует железо и умеет запускать конструкторы глобальных объектов. Деструкторы не умеет запускать, т.к. выхода в ДОС нет. Трансляция в несколько этапов: сначала в ассемблерный исходник, потом в объектник, потом линковка в ДОС-exe файл, потом обработка ДОС-exe файла самописным конвертором для превращения в загрузочный образ. Модель памяти huge. Куча не используется, все буфера распределены статически. Никакие стандартные библиотеки не используются, весь ввод-вывод переписан. От транслятора используется только кодогенерация. Наследование и виртуальные функции активно используются т.к. они не обращаются к ресурсам ОС.

Очень удобно работать на C++ с железом. Примеры: "порт вообще" это базовый класс. У него виртуальные методы "запись" и "чтение". COM порт это производный класс от "порт вообще". У него переопределяются методы записи и чтения. Два COM порта в процессоре это два экземпляра класса COM порта. Синхронный порт это тоже производный класс от "порт вообще". У него тоже переопределяются методы записи и чтения своими функциями. И так далее. После этого очень удобно передавать указатель на "порт вообще" в функции и вызывать в них вирт. функции ввода-вывода. Таким образом получаем канализацию ввода-вывода с поддержкой на уровне транслятора. Все это можно посмотреть на: