| |
|
  |
 C++ в микроконтроллерах, посветите безграмотного. |
|
|
|
|
 Mar 17 2008, 09:47
|
Частый гость
Группа: Новичок
Сообщений: 111
Регистрация: 10-02-07
Из: St.Petersburg, Russia
Пользователь №: 25 241
|
Цитата(-=Sergei=- @ Mar 17 2008, 12:20)  Имеем ARM Cortex-M3.
Ядро за командами лазит в флеш через шину Icode, за данными через system в ОЗУ. Конфликтов нет, работаем быстро.
я создаю некий объект обладающий свойствами и функциями. Он создается в ОЗУ. Т.е. теперь если я начну выполнять некую функцию объекта, то теперь и за командами и за данными ядро будет лазить в ОЗУ, возникают конфликты и их разрешение снижает производительность. Или я не праивльно понимаю создание объекта? Код функций объекта все так же будет распалагаться во Флеш а свойства в ОЗУ? Не знаю куда послать. Но советую почитать где-нибудь о процессе компоновки и загрузки программ. В частности при работе с мелкими MCU секции кода и константных данных попадают в ПЗУ (flash), секции изменяемых данных и неинициализированных данных -- в ОЗУ. В некоторых экзотических случаях (ЭВМ с раздельными адресными пространствамим для кода, данных и другими...) все данные попадают в ОЗУ (AVR) или же используются указатели специального типа (x51).
--------------------
[ZX]
|
|
|
|
|
|
|
|
Mar 17 2008, 10:43
|
Местный
Группа: Свой
Сообщений: 339
Регистрация: 26-10-04
Пользователь №: 985
|
Цитата(KRS @ Mar 17 2008, 13:06) объект создается не в ОЗУ, а в определенном сегменте/секции. Причем там располагаются исключительно данные и указатель на VMT, а все функции (они в одном экземпляре для каждого класса) остаются в сегменте/секции кода. Благадарю... все ясно.
|
|
|
|
|
|
|
|
Mar 18 2008, 07:39
|
Профессионал
Группа: Модераторы
Сообщений: 1 951
Регистрация: 27-08-04
Из: Санкт-Петербург
Пользователь №: 555
|
Цитата(IgorKossak @ Mar 18 2008, 09:37) Именно так и объявленный объект создаётся In section .bss, а также создаются конструкторы, пишущие в эту область памяти. Объект может не иметь конструктора. и все методы могут быть конст. Вот пример который кидает данные в скецию .rodata Это конечно простой объект без VMT - реально просто структура с методами. Но такой подход может быть полезен никакого оверхида Код class cls {
public:
int a;
int b;
int foo(void) const;
};
extern const cls a;
extern const cls b;
const cls a = {4,5};
const cls b = {6,7};
int cls::foo(void) const
{
return a + b;
} а вот листинг Код \ In section .rodata, align 4
11 const cls a = {4,5};
\ a:
\ 00000000 040000000500 DC32 4, 5
\ 0000
\ In section .rodata, align 4
12 const cls b = {6,7};
\ `b`:
\ 00000000 060000000700 DC32 6, 7
\ 0000
13
\ In section .text, align 4, keep-with-next
14 int cls::foo(void) const
15 {
16 return a + b;
\ _ZNK3cls3fooEv:
\ 00000000 0168 LDR R1,[R0, #+0]
\ 00000002 4068 LDR R0,[R0, #+4]
\ 00000004 0818 ADDS R0,R1,R0
\ 00000006 7047 BX LR ;; return
17 }
18
|
|
|
|
|
|
|
|
Mar 18 2008, 08:08
|
Шаман
Группа: Модераторы
Сообщений: 3 064
Регистрация: 30-06-04
Из: Киев, Украина
Пользователь №: 221
|
Точно, всё дело было в инициализации. Я создавал класс с одним членом. Если делать Код const cls a = 30; то потребует конструктора, если сделать иначе Код const cls a = {30}; то всё работает.
|
|
|
|
|
|
|
|
Mar 18 2008, 08:36
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(KRS @ Mar 18 2008, 13:39) Объект может не иметь конструктора. и все методы могут быть конст. Вот пример который кидает данные в скецию .rodata Это конечно простой объект без VMT - реально просто структура с методами. Но такой подход может быть полезен никакого оверхида Код class cls {
public:
int a;
int b;
int foo(void) const;
}; Тут у вас объявлен POD тип. На самом деле это просто обычная С-структура. POD типы могут лежать в RO памяти без проблем, как и подобает обычным С-типам. Правильнее было бы просто написать: struct cls { ... }; Заведите хотя бы одно не public поле, все станет не так шоколадно. 
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
Mar 18 2008, 09:02
|
Профессионал
Группа: Модераторы
Сообщений: 1 951
Регистрация: 27-08-04
Из: Санкт-Петербург
Пользователь №: 555
|
Цитата(dxp @ Mar 18 2008, 11:36) Тут у вас объявлен POD тип. На самом деле это просто обычная С-структура. POD типы могут лежать в RO памяти без проблем, как и подобает обычным С-типам. Так я и написал что реально просто структура с методами. Но я предпочитаю писать как class что бы отличать от просто структур, которые не имеют методов. К тому же это не совсем POD - потому что метод foo там есть и совместимости с С уже нет. Цитата(IgorKossak @ Mar 18 2008, 11:42) С объектами производных классов тоже не просто. Это да, и к тому же если есть VMT, даже без производных классов, IAR почему то не может заранее положить указатель на VMT, обязательно вызывается функция, которая туда его кладет. Но остается возможность использовать template.
Сообщение отредактировал KRS - Mar 18 2008, 09:09
|
|
|
|
|
|
|
|
Mar 18 2008, 12:58
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(IgorKossak @ Mar 18 2008, 14:42) С объектами производных классов тоже не просто. Если класс производный, он уже не POD со всеми вытекающими - агрегатные инициализаторы к нему нельзя применять. Цитата(KRS @ Mar 18 2008, 15:02) Так я и написал что реально просто структура с методами. Но я предпочитаю писать как class что бы отличать от просто структур, которые не имеют методов. К тому же это не совсем POD - потому что метод foo там есть и совместимости с С уже нет. POD - это не совместимость с С, это типы, которые попадают под ряд правил и их поведение и применимость наболее близки к С-типам. Например, объекты POD типов можно копировать с помощью memcpy, а не-POD типов - нельзя и т.д. Но совместимость тут не причем. Наличие функции-члена (не метода, кстати) не мешает типу оставаться POD. А вот наличе метода (виртуальной функции) как раз делает его (тип) не POD.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|
