Какая разнится между гарвардской и фон неймовской архитектурой для С-программиста?
Если можно конкретный жизненный пример.
Заранее благодарен.

Никакой.
Исходники одинаково хорошо копилируются си-компиляторами в любую архитектуру, от PIC12 до ARM или BF. Лишь бы ресурса хватало. А любую закорюку, требующую индивидуального подхода (прагмы например) нужно очень серьезно обдумывать независимо от архитектуры.

Разницы нет, если он вирусы не пишет ))

Да, для Си-программиста разницы никакой.
Разница в скорости работы полученного кода.
Элементарная операция сложения операндов из внешней памяти в Неймановской архитектуре требует 3 последовательных обращений к памяти (загрузка команды, загрузка 1-го операнда, загрузка 2-го операнда/выполнение сложения).
При Гарвардской архитектуре эта же операция потребует уже 2 обращения: загрузка команды из памяти программ и одновременно загрузка 1-го операнда из памяти данных, затем загрузка второго операнда и выполнение инструкции.
Налицо выигрыш 33% в скорости.
Плюс гарвардская архитектура позволяет делать разные разрядности памяти программ и данных, благодаря чему все или подавляющее большинство кодов инструкций имеют длину всего в одно слово, что также ускоряет их загрузку.

Спасибо!
Получается стоит учитывать особенности архитектуры при расчёте алгоритмов и выборе процессора...



В чём плюсы фон неймовской архитектуры тогда? Нежто МСП430 зря работают по Фон неймовской архитектуре?

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

Несчастный фон Нейман в гробу ворочается.
Так фамилию переврать...

Зависит от реализации Гарвардской архитектуры. В DSP от Analog Devices возможна одновременная (в одном тактовом цикле) прогрузка данных (в РОН, условно говоря) из двух областей памяти и вычислительная операция. В обычных контроллерах (avr,pic) преимущества Гарвардской проявляются в коротких командах - очень мало двухсловных команд (в picaх вообще не помню, есть ли).

2Zelepuk
По Неймановской - общая память как для программ, так и для данных может быть как ее преимуществом, так и недостатком, в зависимости от ситуации. Но по скорости работы у нее преимуществ нет однозначно.

В МК с архитектурой Фон Неймана возможно поместить выполняемый код в ОЗУ и динамически изменят его. Ну например загружать в ОЗУ программы из карты памяти. В МК с гарвардской архитектурой подобные вещи сделать затруднительно.

Неймановская безусловно ЛУЧШЕ из за линейного адресного пространства.
Простейщий пример для пишущих на Си:
гарвардская у AVR требует иметь 3 разных printf - для строк из памяти данных и для строк из памяти программ, и для eeprom,удобно?)). Наличие многих адресных пространств памятей постоянно требует дублирования функций. Это существенно затрудняет портирование интересных и нужных наработок как IP/TCP стеков, графических оболочек (GUI) и проч.

Однако, наилучшая архитектура для микроконтроллеров - так наз. смешанная, когда ОЗУ и FLASH висят на разных шинах, но находятся в 1 адресном пространстве. Лучший пример - ARMы серии Cortex-M.

Ничуть не затруднительно, если в качестве программ выступает ОЗУ. Пример - процессор фирмы ADI Blackfin. В случае, если не ОЗУ, то потруднее, но это обусловлено не типом архитектуры, а типом памяти.

Из уникальных фишек, доступных для фон Неймана, можно отметить возможность писать position-independed code, когда код и данные линкуются в сопряжённые блоки и доступ к данным организуется по относительным (от кода) смещениям, что позволяет эти блоки размещать в любом месте адресного пространства без потери целостности функциональности.


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

Гарвардская архитектура тут просто даёт возможность подкачивать данные и код одновременно - каждое по своим шинам, но память при этом может быть одна и та же (ессно, одна должна быть побита на блоки, доступ к которым осуществляется со стороны шин данных и адресов неодновременно).


Это просто у AVR так организовано, что память данных ОЗУ, память данных EEPROM и память программ физически разделены, поэтому тут нужны всякие расширения вроде __flash и __eeprom. А можно ведь было сделать и по-другому. Правда, у AVR адресная шина неширокая, поэтому на нём сильно не разгонишься по пути унифицированного адресного пространства для всех видов памяти.


Именно. И ещё пример - Blackfin. У всех этих процов шина адресов широкая - 32 бита, есть, где всё разместить.

Мне кажется, это несовершенство конкретного компилятора а не архитектуры. printf не применял, но sprintf на майкрочипе на любом из трех компиляторов работал прозрачно. Странно что компилятор (при корректном описании типов величин, конечно) не может разобраться сам.

Агащязпрям. Попробуйте в AVR создать массив констант в памяти программ и обратиться к нему - сразу поймете разницу.

С точки зрения языка Си: в какой памяти размещен массив - разницы не будет, обращение к элементам массива будет одинаково (что-то типа M[i]). Другое дело - указатели, но эту проблему должны решать компиляторописатели - решили же эту проблему в Keil...

ну а с макрочипом (PIC18 например) это делается просто, именно память программ используется:

Так что проблемы не в архитектуре, а в компиляторе.

Дык в ГЦЦ решено давным давно. Не надо было бы пеарить обертки типа PROGMEM - не появилось бы надстроек соответствующих. Бы.

В кейле это решили введением нестандартных ключевы слов.


Да ну? И как же это сделано? Неужели в стандарт языка ввели новое ключевое слово, означающее размещение переменной в памяти программ?

Я ничего не понял в этом предложении. Нельзя ли поподробнее и по-русски?


Кстати о кейле: вообще-то топикстартер поставил вопрос "Какая разнится между гарвардской и фон неймовской архитектурой для С-программиста?" И вы дружно начали кричать, что разницы никакой. Но во-первых даже при размещении массива программист должен не просто написать M[i], а еще и указать в какой именно памяти он хочет его разместить - а значит разница для программиста уже есть. И после этого он должен пользоваться указателями соответствующего типа чтобы не перепутать обращение к разным типам памятей - и как после этого можно утверждать что для программиста разницы никакой?

Вы считаете, что применение программистом слов "static" и "const" зависит от типа архитектуры ядра?


Давайте определимся. Вы говорите о проблемах и различии в си-программе не для гарвард-негарвард, а при написании программ на одном конкретном гарвардоподобном ядре при применении одного конкретного компилятора. И проецируете эти проблемы на все прцессоры и все компиляторы. Но это не так, есть гарвардоподобные ядра и компиляторы к ним, в которых описанных вами проблем нет.

Я больше скажу- желание разместить данные по какому-либо физическому адресу может прийти в голову и при пользовании фон-неймановским ядром

Если Вы ведете речь о размещении массива, то - да, нестандартные ключевые слова для этого ввели в большенство трансляторов. Я же говорил об указателе: в Keil - "Generic Pointers", транслятор сам "разбирается" с типами памяти.


Если программист хочет разместить массив именно в конкретной памяти - то некоторая разница есть (при описании массива). Но, можно, и - "по-умолчанию" (не всегда эффективно и возможно). Про указатели - см. выше (Generic Pointers).

А вы считаете, что они предназначены для размещения данных в той или иной памяти? Впрочем, это распространенная ошибка.

Объясняю: спецификатор const преднаначен лишь для того, чтобы сказать компиляторору, что эта переменная (или, если это указатель, то данные на которые он указывает) не должны меняться. И поэтому если компилятор встретит код, который меняет эти данные, он должен выдать не него ошибку. Но это не значит, что они могут размешаться в памяти программ! Поясню на конкретном примере: функция strcpy имеет такой прототип:

char* strcpy( char *strDestination, const char *strSource);

strSource здесь - константный указатель на char. Значит ли это, чо компилятор при трансляции этой функции должен при обращении к данным, адресуемым этим указателем, генерировать код для обращении к памяти программ? Разумеется нет, ведь я могу использовать эту функцию для пересылки строк из памяти данных! Поэтому const нельзя использовать для таких целей, для этого могут использоваться только нестандартные спецификаторы. Тем более, что типы памятей могут не ограничиваться только памятью команд и данных, в том же 8051 есть области DATA, IDATA, XDATA, и другие, о которых стандарт Си не обязан ничего знать.

Что же касается static, то он вообще не имеет отношения к размещению данных (за исключением некоторых мелочей, не относящихся к обсуждаемому вопросу).


Мудреное предложение которое трудно понять. Я говорю о том, о чем спрашивал топикстартер, а именно: "Какая разнится между гарвардской и фон неймовской архитектурой для С-программиста?" Заметте, речь идет не о проблемах, а о разнице. А она безусловно есть и программист обязательно должен эту разницу учитывать.


Я ничего не говорил о размещении по физическому адресу. Я говорю о размещении данных в памяти разных типов.




Разумеется о размещении, перед тем как пользоваться переменными, их нужно создать, а для этого подумать где им место. И в 8081 этот вопрос программист должен продумывать очень тщательно - какие переменные лучше поместить в DATA, а какие в IDATA - ошибки в выборе могут кардинально поменяь производительность.


А, вы об этом уродстве? Вот уж не думал, что ими кто-то реально пользуется. Нужно быть идиотом, чтобы тщательно продумав о размещении переменных (DATA, IDATA или XDATA) после этого обращаться ко всем ним через generic указатели.


Вот именно! Вы прекрасно понимаете, что это сильно влияет на эффективность, но при этом заявляете новичкам, что дла программиста нет никакой разницы какая архитектура у процессора! Может не стоит разбрасываться такими вредными советами, тем более понимая их вредность?

Поскольку язык Си был ориентирован на архитектуру фон Неймана, то в стандарте отсутствуют спецификаторы типа памяти, зачастую необходимые для программ, написанных для гарвардской архитектуры. Эти спецификаторы - расширения языка. Они - плод фантазии компиляторописателей, и в разных компиляторах - свои. Впрочем, и различные компиляторы для традиционной (фон Неймановской) архитектуры, обычно, имеют расширения языка (читай: нестандартные конструкции). Так что, программист волей-неволей должен их знать при использовании конкретного компилятора (и это - вне зависимости от архитектуры). В этом смысле можно говорить, что различий в собственно языке СИ в зависимости от архитектуры - нет.

Вы, возможно, будите удивлены, но некоторые компиляторы для МК "const" именно для этого используют. Хотя, согласно стандарту, предназначены они не для размещения данных...

"Эффективность" - понятие очень ёмкое. Каков критерий эффективности? Впрочем, я ещё не видел у новичков эффективно написанных программ (в любом смысле). Но это проходит (а, иногда, - нет) с накопленным опытом. Что же касается знания программистом архитектуры применяемого МК, то тут - ну никак без этого. И это знание, зачастую, обязательно для написания программ на любом языке...

Вам не кажется что три выделенных фрагмента противоречат друг другу?
Если "программист волей-неволей должен знать нестандартные расширения языка", то это не "вне зависимости от архитектуры", а как раз наоборот, ведь в каждой архитектуре свои собственные расширения. Тем более смешно говорить, что "различий в собственно языке СИ в зависимости от архитектуры - нет". Если для обращения к разным областям памяти нужно применять некие конструкции языка, хоть и нестандартные - значит различия есть.


Получается, что там функцией strcpy нельзя скопировать строку из памяти данных? Значит выкидывать надо такие компиляторы.


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


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

Перевожу.
А вам не кажется, что вы говорите не об архитектуре (гарвард) а о микроконтроллере AVR?
Потому что есть например майкрочип (тоже гарвард), у которого всех описанных вами заморочек нет вообще?

Я говорю об архитектуре.

То есть как это нет? Как считать байт в W из ОЗУ? А как из памяти команд?

res = W * 5;

независимо от того, что такое W - переменная или константа.

или я не понял вопроса.

Скорее всего. Речь идет о размещении в памяти программ больших константных массивов. Или, вообще - о различиях в обращении к памяти программ и памяти данных (а именно наличием двух, как минимум, видов памяти и отличается гарвардская архитектура от фон-неймановской).

И даже не обязательно речь идет о константах - в некоторых сигнальных процессорах ADSP и память данных, и память программ находятся в ОЗУ, благодаря чему запись разрешена и в память программ тоже. Неужели и здесь для программиста архитектура не играет роли?

Вы невнимательно читаете. Я ответил на ваш вопрос в своем сообщении http://electronix.ru/forum/index.php?showt...st&p=988815 я привел кусочек массива 4-байтовых константных величин и пример обращения к этому массиву.


Конечно не играет. У меня один и тот же код (ну скажем нормировочные функции и кусочно-линейные кривые с коэффициентами и аппроксимациями- много таблиц и вычислений и массивов) крутился и на bf533 и на adsp2181 и на at91rm9200(arm9) и на pic18. Напомню, речь идет не о написании си-компиляторов, а об использовании готовых .

Глубоко копаете! Если имеется в виду ответ для начинающего, то не играет роли в большинстве случаев.
А когда дело дойдет до тонкостей, нюансы и проявятся. И если все-таки компилятор хорошо написан, нюансы обращений к разным типам памяти будут предельно тонкими.
И уж в любом случае архитектура для C-программиста играет куда меньшую роль, чем для asm-программиста.

Меня всегда удивляло высокомерие здешней публики. Сам факт наличия раздела "для начинающих" чего стоит! Я такого не видел ни на одном форуме! Неудивительно что мои предложения ликвидировать этот раздел не нашли понимания. Действительно, если не будет такого раздела, то как великие гуру будут удовлетворять свое ЧСВ? Да и тонкости в отличиях архитектур начинающему объяснять не следует, а то еще выучит и станет умнее вас, это же непорядок!

Как же он дойдет до тонкостей, если вы их от него тщательно скрываете?!

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

1. Разницы для си-программиста нет никакой.
2. Есть нюансы при использовании кривых компиляторов, 777777 любезно упомянул об одном из них применительно к гарварду. Уверен, можно найти также кривой компилятор и для фон-неймана. Под "кривым" подразумевается компилятор, оставляющий программисту самому организовывать доступ к разным типам данных, расположенным в разной памяти. Хороший компилятор делает это сам, при его использовании программист не должен заниматься архитектурозависимыми вопросами вообще. Собственно в этом и смысл хорошего компилятора- взять на себя рутинную работу.
3. Мне неизвестны нюансы архитектуры, о которых должен знать си-программист. Если речь идет о том чтобы выжать максимальную эффективность, то программисту нужно знать не нюансы архитектуры, а нюансы конкретного компилятора и конкретного микроконтроллера вплоть до последней ревизии ерраты. Подчеркну, к архитектуре это не имеет никакого отношения.

Нас выручают макросы.

Смелое заявление!


Фигасе заявочки! Да если компилятор решает за программиста где разместить те или иные данные, то его надо выкидывать нахрен! Даже const массивы нельзя располагать во флэш без ведома программиста - мало ли как мне захочется их проинициализировать, может это будет делать бутлоадер загружая их при включении по USART. А про const-указатели я уже писал. Забота компилятора лишь в том, чтобы следить за тем, чтобы программист не написал код, пишущий в эту область.


Еще более смелое заявление. Странно видеть программиста, исследующего отличия в ревизиях конкретного микроконтроллера, но полностью игнорирующего его архитектуру.

А вот для того, чтобы программист мог реализовать все свои хотелки, и существуют нестандартные (и компиляторозависимые) расширения языка.
Но, повторю уже неоднократно прозвучавшую мысль, к архитектуре МК это не имеет ни малейшего отношения

Нестандартное компиляторозависимое расширение кейла для размещения данных в памяти DATA, IDATA и т.д., а также нестандартное расширение gcc PROGMEM для размещения данных в памяти программ - не имеют, оказывается, отношения к архитектурам этих МК!

Всё, это конец, пора эту дискуссию завязывать.

Давно пора...
Попытаюсь обобщить все мнения, высказанные выше.
Программисту, пишущиму на любом языке программирования, необходимо знание архитектуры ЭВМ/МК, на котором будет работать программа. Причем это касается не только того гарвардская или неймоновская/принстонская архитектура. Нужно знание и системы команд, и разрядности шин, и системы прерываний (кстати, в стандарте языка Си - нет соответствующий средств для работы с ними), и устройств ввода-вывода...
Для МК, зачастую, характерна нехватка ресурсов (в первую очередь - ОЗУ, вероятно это - результат "большого" объема ОЗУ в ПЭВМ). При проектировании программы ресурсы нужно распределить. При написании программы компилятору, обычно, нужно указать это распределение. Делается это - нестандартными расширениями языка Си (коль вопрос изначально был о Си).
В остальном - "Си - он и в Африке...". Большенство компиляторов для МК поддерживают стандарт ISO9899 языка Си.