Форум разработчиков электроники ELECTRONIX.ru

-=Sergei=-

Mar 17 2008, 09:20

Имеем ARM Cortex-M3.

Ядро за командами лазит в флеш через шину Icode, за данными через system в ОЗУ. Конфликтов нет, работаем быстро.

я создаю некий объект обладающий свойствами и функциями. Он создается в ОЗУ. Т.е. теперь если я начну выполнять некую функцию объекта, то теперь и за командами и за данными ядро будет лазить в ОЗУ, возникают конфликты и их разрешение снижает производительность. Или я не праивльно понимаю создание объекта? Код функций объекта все так же будет распалагаться во Флеш а свойства в ОЗУ?

Kirill Frolov

Mar 17 2008, 09:47

Цитата(-=Sergei=- @ Mar 17 2008, 12:20)

Имеем ARM Cortex-M3.

Ядро за командами лазит в флеш через шину Icode, за данными через system в ОЗУ. Конфликтов нет, работаем быстро.

я создаю некий объект обладающий свойствами и функциями. Он создается в ОЗУ. Т.е. теперь если я начну выполнять некую функцию объекта, то теперь и за командами и за данными ядро будет лазить в ОЗУ, возникают конфликты и их разрешение снижает производительность. Или я не праивльно понимаю создание объекта? Код функций объекта все так же будет распалагаться во Флеш а свойства в ОЗУ?

Не знаю куда послать. Но советую почитать где-нибудь о процессе компоновки и загрузки программ. В частности при работе с мелкими MCU секции кода и константных данных попадают в ПЗУ (flash), секции изменяемых данных и неинициализированных данных -- в ОЗУ. В некоторых экзотических случаях (ЭВМ с раздельными адресными пространствамим для кода, данных и другими...) все данные попадают в ОЗУ (AVR) или же используются указатели специального типа (x51).

KRS

Mar 17 2008, 10:06

Цитата(-=Sergei=- @ Mar 17 2008, 12:20)

я создаю некий объект обладающий свойствами и функциями. Он создается в ОЗУ. Т.е. теперь если я начну выполнять некую функцию объекта, то теперь и за командами и за данными ядро будет лазить в ОЗУ, возникают конфликты и их разрешение снижает производительность. Или я не праивльно понимаю создание объекта? Код функций объекта все так же будет распалагаться во Флеш а свойства в ОЗУ?

объект создается не в ОЗУ, а в определенном сегменте/секции. Причем там располагаются исключительно данные и указатель на VMT, а все функции (они в одном экземпляре для каждого класса) остаются в сегменте/секции кода.

-=Sergei=-

Mar 17 2008, 10:43

Цитата(KRS @ Mar 17 2008, 13:06)

объект создается не в ОЗУ, а в определенном сегменте/секции. Причем там располагаются исключительно данные и указатель на VMT, а все функции (они в одном экземпляре для каждого класса) остаются в сегменте/секции кода.

Благадарю... все ясно.

IgorKossak

Mar 17 2008, 12:21

Цитата(KRS @ Mar 17 2008, 12:06)

объект создается не в ОЗУ, а в определенном сегменте/секции

, который/которая должны находиться таки в ОЗУ, т. к. в read-only памяти объект не может быть сконструирован

KRS

Mar 17 2008, 12:44

Цитата(IgorKossak @ Mar 17 2008, 15:21)

, который/которая должны находиться таки в ОЗУ, т. к. в read-only памяти объект не может быть сконструирован

который объявлен глобально и как const может.

IgorKossak

Mar 18 2008, 06:37

Цитата(KRS @ Mar 17 2008, 14:44)

который объявлен глобально и как const может.

Именно так и объявленный объект создаётся In section .bss, а также создаются конструкторы, пишущие в эту область памяти.

KRS

Mar 18 2008, 07:39

Цитата(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

IgorKossak

Mar 18 2008, 08:08

Точно, всё дело было в инициализации.
Я создавал класс с одним членом.
Если делать

Код

const cls a = 30;

то потребует конструктора, если сделать иначе

Код

const cls a = {30};

то всё работает.

dxp

Mar 18 2008, 08:36

Цитата(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 поле, все станет не так шоколадно.

IgorKossak

Mar 18 2008, 08:42

С объектами производных классов тоже не просто.
Даже если нет private членов как проинициализировать следующий объект?

Код

class cls
{
    public:
        virtual int foo(void) const = 0;
};

class boo : public cls
{
    public:
        int a;
        int b;
        int foo(void) const;
};

extern const boo b;

const boo b =????;

KRS

Mar 18 2008, 09:02

Цитата(dxp @ Mar 18 2008, 11:36)

Тут у вас объявлен POD тип. На самом деле это просто обычная С-структура. POD типы могут лежать в RO памяти без проблем, как и подобает обычным С-типам.

Так я и написал что реально просто структура с методами. Но я предпочитаю писать как class что бы отличать от просто структур, которые не имеют методов. К тому же это не совсем POD - потому что метод foo там есть и совместимости с С уже нет.

Цитата(IgorKossak @ Mar 18 2008, 11:42)

С объектами производных классов тоже не просто.

Это да, и к тому же если есть VMT, даже без производных классов, IAR почему то не может заранее положить указатель на VMT, обязательно вызывается функция, которая туда его кладет.
Но остается возможность использовать template.

dxp

Mar 18 2008, 12:58

Цитата(IgorKossak @ Mar 18 2008, 14:42)

С объектами производных классов тоже не просто.

Если класс производный, он уже не POD со всеми вытекающими - агрегатные инициализаторы к нему нельзя применять.

Цитата(KRS @ Mar 18 2008, 15:02)

Так я и написал что реально просто структура с методами. Но я предпочитаю писать как class что бы отличать от просто структур, которые не имеют методов. К тому же это не совсем POD - потому что метод foo там есть и совместимости с С уже нет.

POD - это не совместимость с С, это типы, которые попадают под ряд правил и их поведение и применимость наболее близки к С-типам. Например, объекты POD типов можно копировать с помощью memcpy, а не-POD типов - нельзя и т.д. Но совместимость тут не причем. Наличие функции-члена (не метода, кстати) не мешает типу оставаться POD. А вот наличе метода (виртуальной функции) как раз делает его (тип) не POD.