[Grizzly 0]

5 часов назад, AlexandrY сказал:

Вот тут бы ссылочку на такой ридми, и я бы поверил всем остальным вашим словам.

https://github.com/gentoo-mirror/gentoo/blob/24b0173ca0a3c7c97302415b7e23f2cd104b58b7/net-print/lprng/lprng-3.8.35-r3.ebuild#L37

https://github.com/gentoo-mirror/gentoo/blob/cb972b93a4a6e399829bd70719d5fbfc4eb1f659/app-doc/doxygen/doxygen-9999.ebuild#L88

https://github.com/gentoo-mirror/gentoo/blob/718e514351921e316be5e7aa9c4ba643ab04e37f/dev-db/vsqlite%2B%2B/vsqlite%2B%2B-0.3.13-r1.ebuild#L32

https://github.com/gentoo-mirror/gentoo/blob/718e514351921e316be5e7aa9c4ba643ab04e37f/dev-php/ming-php/ming-php-0.4.7.ebuild#L41

https://github.com/gentoo-mirror/gentoo/blob/718e514351921e316be5e7aa9c4ba643ab04e37f/sys-libs/libsmbios/libsmbios-2.3.3.ebuild#L50

https://github.com/gentoo-mirror/gentoo/blob/718e514351921e316be5e7aa9c4ba643ab04e37f/sci-biology/ncbi-tools/ncbi-tools-2.2.26-r2.ebuild#L40

https://github.com/gentoo-mirror/gentoo/blob/718e514351921e316be5e7aa9c4ba643ab04e37f/app-editors/vim-core/vim-core-8.0.1699.ebuild#L105

[AlexandrY 3]

16 minutes ago, Grizzly said:

https://github.com/gentoo-mirror/gentoo/blob/718e514351921e316be5e7aa9c4ba643ab04e37f/dev-db/vsqlite%2B%2B/vsqlite%2B%2B-0.3.13-r1.ebuild#L32

Из всего этого сомнительного для embedded добра меня заинтересовал только SQLite.
Проверил. В Visual Studio он собирается с любыми опциями.
Так что ссылки говорят только о лени сборщиков gentoo.   

[aaarrr 63]

14 minutes ago, AlexandrY said:

Проверил. В Visual Studio он собирается с любыми опциями.

А там где-то говорится, что не собирается?

 

Другое дело, что информации по тем ссылкам ноль: отключили, ибо глючит. Что именно глючит, под каким тулчейном, на каких тестах - загадка.

Так -O2 может годами висеть, потому что когда-то поставлено, а сейчас уже и не вспомнит никто причину.

[Grizzly 0]

Здесь, например, говорится о баге в GCC4 при сборке Doxygen (к нашей тематике генерация документации подойдет) с флагом -O3, а не -O2: https://github.com/doxygen/doxygen/issues/2234

Так что бывают ошибки как компиляторов, так и конкретных пакетов. В данном случае более редкая вещь.

[jcxz 184]

1 час назад, haker_fox сказал:

Есть ли в таких случаях переходить на другой компилятор, например Keil? Про GCC молчу, ибо они все такие разные...

Зачем? Просто использовать старую версию, где бага нет. И ждать исправления.

В Кейле думаете багов нет?  

[inventor 0]

это не бага. Это фича

[haker_fox 60]

8 hours ago, jcxz said:

В Кейле думаете багов нет

Думаю, что есть. но может быть меньше, всё-таки там "родной" армовский компилятор.

[jcxz 184]

7 часов назад, haker_fox сказал:

Думаю, что есть. но может быть меньше, всё-таки там "родной" армовский компилятор.

Степень баговости чего-то в первую очередь зависит от сложности этого ПО: чем сложнее - тем больше вероятность багов. А не от того - сами придумали систему команд или реализуем чужую (она ведь подробно описана, а значит - все писатели компиляторов находятся в равных условиях). А значит, если говорить, что что-то имеет потенциально меньше багов, значит это что-то заведомо проще -> т.е. - компилятор имеет меньше возможностей, хуже компилит/оптимизирует.

Хотим лучше код - смиряемся с неизбежностью большей вероятности багов, выбираем дубовый компилятор - получаем заведомо худший код. Такой выбор.

Имха.

[haker_fox 60]

5 minutes ago, jcxz said:

меньше багов, значит это что-то заведомо проще

Я кейловский компилятор давно не использовал, поэтому абсолютно не в курсе их дел сейчас. Но я допустил возможность, что "они там" лучше могут знать особенность архитектуры, и ненароком или намеренно сделать более качественный продукт.

[aaarrr 63]

6 minutes ago, haker_fox said:

...абсолютно не в курсе их дел сейчас

Бросили они его, заменили clang'ом :( Неплохой был компилятор.

[jcxz 184]

11 минут назад, haker_fox сказал:

Я кейловский компилятор давно не использовал, поэтому абсолютно не в курсе их дел сейчас. Но я допустил возможность, что "они там" лучше могут знать особенность архитектуры, и ненароком или намеренно сделать более качественный продукт.

Ну так (если говорить о том баге, который я приводил в первой ссылке), то в IAR-е предыдущих версий его не было. Появился он только в какой-то из версий 8.xx. Тогда (если следовать Вашей логике), в версиях 7.80.x IAR-овцы хорошо знали "особенности архитектуры", а в 8.xx - их забыли?  

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

[inventor 0]

возвращаясь к моему первому посту

где определена задержка, по моему мнению это не правильное поведение компилятора

со включенной оптимизацией

где без volatile работать не будет

[Grizzly 0]

15 минут назад, inventor сказал:

это не правильное поведение компилятора

 

Правильное. Посмотрите внимательнее, где и как у вас в коде изменяется LocalTime.

[Arlleex 131]

Только что, inventor сказал:

со включенной оптимизацией

где без volatile работать не будет

Правильно все.

Еще раз смотрите:

void Delay(int timer)
{
   u32 Time = LocalTime;  
   while(LocalTime - Time < timer);
}

 

Поскольку LocalTime - обычная переменная, компилятор вправе предположить, что она не изменяется извне, таким образом, ее содержимое он может кэшировать в регистре и не обращаться за ее значением между точками следования.

Соответственно, он вправе сделать примерно такой код:

void Delay(int timer)
{
   u32 Time = LocalTime;  
   while(LocalTime - LocalTime < timer);
}

или

void Delay(int timer)
{
   u32 Time = LocalTime;  
   while(Time - Time < timer);
}

что не приведет к нужному результату.

 

А оптимизирующий компилятор подставит вместо вычитания 0 и сгенерирует лишь проверку timer <= 0, что не соответствует логике программиста, как видите.

Поэтому нужно явно дать команду компилятору не оптимизировать доступ к переменной LocalTime, чтобы при каждом доступе процессор лез за ней в память, а не кэшировал в регистрах. И команда эта - volatile.

Изменено 5 декабря, 2018 пользователем Arlleex

[inventor 0]

3 minutes ago, Grizzly said:

Правильное. Посмотрите внимательнее, где и как у вас в коде изменяется LocalTime.

в чем правильное?

 

u32 local_time;


void Delay(int timer)
{
   s32 t = local_time;
   
   while(local_time - t < timer){
    asm("nop");
   }
}

 

работает с оптимизацией без volatile

если asm Закоментить не работает