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

C++ для эхотажных систем
Sat Oct 09 2004 11:50, Dmitry Ponyatov wrote to All:
DP> а насколько эхотажные системы обеспечены компиляторами С++ (не С) с
DP> полноценной реализацией ООП ?
Пока что я реально имел дело только с одним - Хитачевким компилятором для H8S.
Однако его ++ мне были на фиг не нужны.
DP> пишу байт-кодовый движок (я тут уже постил вопрос по этой теме),
DP> кажется
DP> мне слишком рискованным завязываться на С++, хотя и удобнее на нем писать
DP> чем на std C.
Чем удобнее? Я писал на чистом це, и особых неудобств не ощутил.
Пока, Алексей
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]
Алексей М.
... Даже лошадь Пржевальского может быть собакой Павлова.
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: запахло оффтопиком -- может мне с этим убраться в другую эху ?
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]
Алексей М.
... Пирожок тушеный с тушенкой.
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]
Алексей М.
... Северо-Кавказская межрегиональная ассоциация анонимных соискателей.
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]
Алексей М.
... Пирожок печеный с печенью.
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++ для эхотажных систем

для

поэтому

примеров

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

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

для

поэтому

примеров

Здравствуйте.
Есть проект 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

для

поэтому

примеров

Здравствуйте.
Есть проект C++ для встроенной системы. Процессор Intel 386ex. Никакого
БИОСа нет, не то что ДОСа. Транслятор BC5.02. Программа на C++ с активным
использованием шаблонов. UCOS-II используется. Стартап свой, переделанный
борландовский, инициализирует железо и умеет запускать конструкторы
глобальных объектов. Деструкторы не умеет запускать, т.к. выхода в ДОС нет.
Трансляция в несколько этапов: сначала в ассемблерный исходник, потом в
объектник, потом линковка в ДОС-exe файл, потом обработка ДОС-exe файла
самописным конвертором для превращения в загрузочный образ. Модель памяти
huge. Куча не используется, все буфера распределены статически. Никакие
стандартные библиотеки не используются, весь ввод-вывод переписан. От
транслятора используется только кодогенерация. Наследование и виртуальные
функции активно используются т.к. они не обращаются к ресурсам ОС.
Очень удобно работать на C++ с железом. Примеры: "порт вообще" это базовый
класс. У него виртуальные методы "запись" и "чтение". COM порт это
производный класс от "порт вообще". У него переопределяются методы записи и
чтения. Два COM порта в процессоре это два экземпляра класса COM порта.
Синхронный порт это тоже производный класс от "порт вообще". У него тоже
переопределяются методы записи и чтения своими функциями. И так далее.
После этого очень удобно передавать указатель на "порт вообще" в функции и
вызывать в них вирт. функции ввода-вывода. Таким образом получаем
канализацию ввода-вывода с поддержкой на уровне транслятора. Все это можно
посмотреть на:
http://i80c386ex.narod.ru /
Спасибо
Basil
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

Re: C++ для эхотажных систем
DP> слишком рискованным завязываться на С++, хотя и удобнее на нем писать
DP> чем на std C.
AK> Чем удобнее? Я писал на чистом це, и особых неудобств не ощутил.
код становится более удобным для понимания, удобнее пользоваться библиотеками
(если они есть, на С++), но как только начинаешь пользоваться динамическим
распределением памяти и созданием/удалением объектов в рантайме, резко
увеличивается оверхед (код работы с хипом), что для эхотажных приложений
слишком дорого (я не имею в виду системы на "тяжелых" 16/32-битных процессорах
естественно)
Site Timeline
- » Работа с USB без USB контроллера?
- — Next thread in » Microcontrollers (Russian)
-
- » uC & 3.5"
- — Previous thread in » Microcontrollers (Russian)
-
- » По моему это гениально
- — Newest thread in » Microcontrollers (Russian)
-
- » TLYp vs lgy
- — The site's Newest Thread. Posted in » Electronics (Polish)
-
- » Regulator ładowania aku 12V-12V / ogranicznik pr ądu
- — The site's Last Updated Thread. Posted in » Electronics (Polish)
-