Вопросы по С/С++ (СИ)

[ПростоНуб]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3584051#p3584051"][uquote="ПростоНуб",url="/forum/viewtopic.php?p=3584046#p3584046"]Какой смысл писать отдельные продукты для разных архитектур,[/uquote]Ну это вообще не довод[/uquote]
Ядро Linux тоже поддерживает множество архитектур, но является единым продуктом.
Тоже самое можно сказать про LLVM, GCC, SDCC и т.п.
Кодогенераторы для разных архитектур, естественно разные, но ряд опций, имеющих смысл для одной архитектуры могут не иметь никакого смысла для другой. И это нормально.

P.S. Поймите, это не довод - это факт. Кроссплатформенный программный продукт всегда имеет общую кодовую базу и минимум различий, специфичных для разных платформ. Это в разы удешевляет поддержку такого продукта.

[ARV]

я, конечно, не специалист, но с моей профанской точки зрения использование отдельного стека для архитектуры типа AVR очень нерационально: там всего 3 регистровых пары, успользующихся для указателей, и резервирование одной под указатель стека данных - это -30% потенциальной эффективности, имхо.

[ПростоНуб]

Так Вас же никто не заставляет. Если у Вас в коде есть динамические стековые переменные, то разные указатели стека существенно упростят отладку. Например, на x86 в GCC есть такой интересный параметр, как -fomit-frame-pointer/-fno-omit-frame-pointer, который управляет тем, будут ли локальные переменные адресоваться через ESP или EBP. В первом случае получается код удобный для отладки, во втором - более компактный и оптимальный.

[ARV]

на x86 в GCC есть такой интересный параметр

какое это имеет отношение к моему вопросу?

вопрос в контексте микроконтроллеров, у которых нет "разных" ОЗУ и нет защиты блоков ОЗУ от доступа "чужих" процессов

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3584140#p3584140"]

на x86 в GCC есть такой интересный параметр

какое это имеет отношение к моему вопросу? [/uquote]

там всего 3 регистровых пары, успользующихся для указателей, и резервирование одной под указатель стека данных - это -30% потенциальной эффективности

В x86 тоже всего три регистра для указателей (EBP,ESI и EDI), но при этом потеря одного из них считается оправданной для упрощения отладки. Почему это не так для AVR?

[VladislavS]

Отладка на AVR? Нет, сынок, это фантастика!

[ARV]

Отладка на AVR? Нет, сынок, это фантастика!

ваша ирония неуместна. протеус для отладки AVR - самое оно вообще бесплатно

(EBP,ESI и EDI), но при этом потеря одного из них считается оправданной для упрощения отладки

вообще говоря, я уже точно не помню, но вроде EBP (BP) изначально предназначен для работе в сегменте стека с локальными переменными, и как раз отказ от его такого назначения делается (вероятно) в угоду какой-то оптимизации, а не наоборот.

что касается AVR, то вопрос был не об оптимизации или её отсутствии, а о выделение под данные отдельного стека. по тем картинкам, что я приводил, видно, что это никак не связано с уровнем оптимизации или отладкой.

я скорее соглашусь, что это сделано "по традиции", как было высказано ранее, чем ради улучшения отладки.

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3584226#p3584226"]

(EBP,ESI и EDI), но при этом потеря одного из них считается оправданной для упрощения отладки

EBP (BP) изначально предназначен для работе в сегменте стека[/uquote]
Где я писал про BP? И о каких сегментах Вы ведете речь применительно к 32/64 разрядному регистру EBP?

как раз отказ от его такого назначения делается (вероятно) в угоду какой-то оптимизации

Именно так, потому что при адресации через указатель стека, который гуляет произвольным образом во время работы отлаживаемой функции, только компилятор помнит, где же относительно него расположена та или иная переменная.

я скорее соглашусь, что это сделано "по традиции", как было высказано ранее, чем ради улучшения отладки.

А это уже Ваше дело. Но отлаживать код JTAGICE mkii с двумя стеками будет существенно проще.
Хотя свое мнение я уже высказал выше:

Если желательно иметь такое разделение стеков для того же CompactRISC (CR16C), то какой смысл ограничивать данный функционал только этой архитектурой?

[ARV]

о каких сегментах Вы ведете речь применительно к 32/64 разрядному регистру EBP?

мда... архитектура x86, если вы вдруг не в курсе, начинается с времен 16-разрядных регистров BP/SP/EI/DI/AX и т.п. и вкупе с сегментными регистрами CS,DS и т.п. а буковку E к ним прилепили позже, "забыв" про сегменты. но термин "сегмент стека", по-моему, еще не умер, хотя теперь подразумевает просто область памяти...

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3584516#p3584516"]

о каких сегментах Вы ведете речь применительно к 32/64 разрядному регистру EBP?

мда... архитектура x86, если вы вдруг не в курсе, начинается с времен 16-разрядных регистров[/uquote]
ARV, не тупите и перечитайте тему. Речь шла о параметре -fomit-frame-pointer, который к 16-ти разрядным архитектурам не имеет вообще никакого отношения и влияет только на стратегию использования регистра EBP компилятором.

[ARV]

я вообще спрашивал о микроконтроллерах... и к чему вы перескочили на какие-то абсолютно НЕ ТЕ платформы, и что этим хотите доказать - для меня остается загадкой. с архитектурой x86 я знаком, и вопросы про целесообразность стека данных для этой архитектуры не задаю.

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3584607#p3584607"]я вообще спрашивал о микроконтроллерах... и к чему вы перескочили на какие-то абсолютно НЕ ТЕ платформы, и что этим хотите доказать[/uquote]
Я уже писал это выше дважды! Раз на "не тех" платформах оправдано резервирование одного регистра из трех под нужнды отладки, то почему это не может быть оправдано на МК?

[ARV]

[Пока_без_кота]

Доброго времени суток.
Жил не тужил у меня вот такой кусок кода:

Спойлер

Код: Выделить всё

	for (uint32_t i = 0; i < count; ++i)
	{		
		uint32_t k = 50;

		table[i].coeff = k;
		printf("\nKoef_%d=%d\n", i, table[i].coeff);
		k += 1;	
	}

который в цикле выводил отладочные значения неких коэффициентов.
Потом, в один прекрасный момент, он начал выводить для всех коэффициентов значение 50.
Это вылечилось добавлением квалификатора static для переменной k.
Но если честно, то мне не совсем понято, зачем он здесь нужен. Ведь он дает сохранятся переменной МЕЖДУ ВЫЗОВАМИ функции/цикла. Неужели каждый раз при проверке условия цикла осуществляется "выход" из него ? Я почему-то всегда думал, что осуществляется начальная проверка условия, вход, после каждого прохода - проверка условия, и только если условие не удовлетворено - выход.

[WiseLord]

Лучше не static сделать, а просто вынести выше тела цикла. Внутри фигурных скобок, естественно, переменная равна 50 - она, как и задумано в этом коде, инициализируется на каждой итерации.

Данная переменная вообще никакого отношения к условию цикла не имеет, непонятно, чему тут можно удивляться.

[pokk]

Добрый день подскажите , как соединить две библиотеки .С .H
1) Первая библиотека содержит функции для работы с кольцевым буфером, buf.H файл соответственно содержит структуры для работы с ними.
2) Вторая библиотека Config.h, это запись системных настроек в ПЗУ. Она глобальная так как настройки могут меняться хоть где(в любом файле) по этому её header добавляю во все хедеры остальных библиотек (добавлю в app.h -> его содержат абсолютно все библиотеки )

Так вот мне понадобилось в Config.h добавить работу с буфером. Т.е некий тип который описан в buf.H после чего компилятор начал ругаться что мне может скомпилировать файл buf.C
и указывает ошибку на Config.h на тип структуры говорит что неизвестна. После чего я начал разбираться почему он её выдает. Оказалось что при компиляции файла buf.с первоначально инклудиться header app.h (где находится Config.h а в самом файле) он вставляется в верхнюю часть файла buf.h а само описание типа находится в buf.h но ниже. По этому он и выдает ошибку.

Примерно так выглядит config.h и buf.h

Код: Выделить всё

#ifndef Config_H_
#define Config_H_


#include "Aplication.h"	   << тут содержиться Buf.h и др.
......
TstackLow Test; 			<<<<<!!!!!Ошибка!!!!!!!!

#endif 

//==============
//==============
//==============
#ifndef Buf_H_
#define Buf_H_
#include "Aplication.h"	 
......
typedef struct {
	unsigned short int Count;
	unsigned short int Tail;
	unsigned short int Head;
	unsigned char Buf[SIZE_STACK_LOW][SIZE_NAME];
}TstackLow;

#endif 

на выходе buf.c это все разворачивается в

Код: Выделить всё

TstackLow Test; 			
......
typedef struct {
	unsigned short int Count;
	unsigned short int Tail;
	unsigned short int Head;
	unsigned char Buf[SIZE_STACK_LOW][SIZE_NAME];
}TstackLow;

Естественно он не может понять. Как это сделать правильнее? Можно конечно перенести typedef struct {...}TstackLow; в Config.h и тогда проблема исчезнет, но не хочу плодить разные сущности в одном файле, если у них есть свой(buf.h)

Возможно это из моей неправильно концепции, где я создаю app.h и его инклужу ко все библиотекам, а внутрь его уже добавляю то что может использоваться во всех модулях (тип процессора(stm32f1,stm32f4,..), таймеры, светодиоды, и тд..)

[WiseLord]

Вы пытаетесь внутри config.h обратиться к неизвестному типу TstackLow, не включив файл buf.h, где он определён. Естественно, это приведёт к ошибке.

То, что в config.h включен app.h, в котором уже включен buf.h, может не сработать, если получается циклическая зависимость. Убедитесь, что у Вас нет такой ситуации, когда какой-нибудь .h файл через цепочку других include-ов может включить сам себя. Скорее всего, именно в этом проблема и заключается. В неправильной концепции, то есть.

[pokk]

Благодарю!
Решил пора перейти с С на С++, но тут столько проблем возникает. (в с++ знания нулевые)
До это писал на IAR все на С при переходе на с++ там надо сишный вариант startup, на IAR его фиг найдешь, какой то нашел но там компилятор ругается на using ...., то ли из за версии то ли не поддерживает ...
В каком компиляторе лучше начинать ? Пытался настроить как-то eclips, но времени было мало, проект не завелся, вот думаю продолжить, но приодеться разбираться в компиляторе + с++ ....

[VladislavS]

[uquote="pokk",url="/forum/viewtopic.php?p=3594246#p3594246"]До это писал на IAR все на С при переходе на с++ там надо сишный вариант startup[/uquote]Зачем? Стартап любой рабочий можно использовать.
[uquote="pokk",url="/forum/viewtopic.php?p=3594246#p3594246"]на IAR его фиг найдешь, .[/uquote]О каком процессоре речь? Вообще, можно и самому написать, у IAR стартапы простые - таблица векторов да переход на clib.[uquote="pokk",url="/forum/viewtopic.php?p=3594246#p3594246"]В каком компиляторе лучше начинать ?[/uquote]В том на который лучше документация и возможность получить помощь на форуме. IAR в этом плане хороший выбор. Но если озвучишь тип процессора можно и ещё что-то подобрать.

[pokk]

Процессор stm32f103xx
Да startap я уже переписал(воткнул таблицу прерываний из серии 103,остальное все так оставил), взял за основу f412RE (см файл)
Правда на

Код: Выделить всё

using tIntFunct = void(*)();
//cstat !MISRAC++2008-9-5-1
using tIntVectItem = union {tIntFunct __fun; void * __ptr;};

IAR 7.5 ругается, пришлось переделать на typedef
После этого проект заработал, и в прерывание по таймеру входил.
Дальнейшие изучение продолжил с классом портов GPIO
Первое что нашел https://github.com/ThatEmbeddedGuy/Stm3 ... ter/Gpio.h
хоть и не под 103 серию, но главное смысл, а подправить проблем не составит.
но тут IAR начал выдавать ошибки на enum class, и на constexpr я так понял в версии 7.5 он ни то ни то не поддерживает.
Прочитал статью http://easyelectronics.ru/rabota-s-port ... na-si.html
теперь двоякое чувство, как правильно писать на С++ на основе шаблонов, или же с наследованием.
В общем от С++ хочу добиться, хорошей инкапсуляции, что бы написанный модуль можно было дальше пихать во все проекты, и дальше его только дописывать... на С, получаеться, но .. количество исходников только растет и растет и в библиотеку они не особо оформляются. Особо это касается типа каких нибудь журналов, кольцевых буферов и тд.., один создал а второй только копипастом создается

Добавлено after 10 minutes 46 seconds:

Код: Выделить всё

В том на который лучше документация и возможность получить помощь на форуме. IAR в этом плане хороший выбор.

Где-то видал обсуждение что gcc по С++ на голову всех остальных компиляторов превосходит.