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

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

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

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

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

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

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

Привет Dmitry!

09 Oct 04 11:50, Dmitry Ponyatov писал All:

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

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

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

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

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

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

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

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

Привет Dmitry!

10 Oct 04 16:25, Dmitry Ponyatov писал Alex Mogilnikov:

 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!

12 Oct 04 18:26, Dmitry Ponyatov писал Alex Mogilnikov:

 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!

16 Oct 04 10:20, Dmitry Ponyatov писал Alex Mogilnikov:

 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 порта.
Синхронный порт это тоже производный класс от "порт вообще". У него тоже
переопределяются методы записи и чтения своими функциями. И так далее.
После этого очень удобно передавать указатель на "порт вообще" в функции и
вызывать в них вирт. функции ввода-вывода. Таким образом получаем
канализацию ввода-вывода с поддержкой на уровне транслятора. Все это можно
посмотреть на:

http://i80c386ex.narod.ru /

Спасибо
Basil

для

поэтому

примеров


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

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

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

http://i80c386ex.narod.ru /

Спасибо
Basil

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 порта.
Синхронный порт это тоже производный класс от "порт вообще". У него тоже
переопределяются методы записи и чтения своими функциями. И так далее.
После этого очень удобно передавать указатель на "порт вообще" в функции и
вызывать в них вирт. функции ввода-вывода. Таким образом получаем
канализацию ввода-вывода с поддержкой на уровне транслятора. Все это можно
посмотреть на:

http://i80c386ex.narod.ru /

Спасибо
Basil

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

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

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

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