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

Do you have a question? Post it now! No Registration Necessary

Threaded View

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

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


C++ для эхотажных систем
Sat Oct 09 2004 11:50, Dmitry Ponyatov wrote to All:

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

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

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

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

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


C++ для эхотажных систем
Привет Dmitry!

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

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

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

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

C++ для эхотажных систем
On 09/Oct/04 at 15:32 you write:

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

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

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

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


C++ для эхотажных систем
Привет 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]
Алексей М.
... Пирожок тушеный с тушенкой.

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

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

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

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

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

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

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


C++ для эхотажных систем
Привет 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]
Алексей М.
... Северо-Кавказская межрегиональная ассоциация анонимных соискателей.

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

 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


C++ для эхотажных систем
Привет 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]
Алексей М.
... Пирожок печеный с печенью.

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

Quoted text here. Click to load it
для
Quoted text here. Click to load it
поэтому
Quoted text here. Click to load it
примеров
Quoted text here. Click to load it

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

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

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

http://i80c386ex.narod.ru /

Спасибо
Basil




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

Quoted text here. Click to load it
для
Quoted text here. Click to load it
поэтому
Quoted text here. Click to load it
примеров
Quoted text here. Click to load it

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

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

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

http://i80c386ex.narod.ru /

Спасибо
Basil




C++ для эхотажных систем
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

Quoted text here. Click to load it
для
Quoted text here. Click to load it
поэтому
Quoted text here. Click to load it
примеров
Quoted text here. Click to load it

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

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

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

http://i80c386ex.narod.ru /

Спасибо
Basil


Re: C++ для эхотажных систем
Quoted text here. Click to load it

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

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

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

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

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


Site Timeline