Гарвардская и фон неймовская, разница на практике? Опции

[Zelepuk]

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

[V_G]

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

[777777]

Да, для Си-программиста разницы никакой.

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

[Палыч]

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

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

[777777]

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

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

Дык в ГЦЦ решено давным давно.

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

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

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

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

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

[Ruslan1]

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

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

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

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

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

[777777]

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

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

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

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

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

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

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

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

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

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

Если Вы ведете речь о размещении массива, то - да, нестандартные ключевые слова для этого ввели в большенство трансляторов.

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

Я же говорил об указателе: в Keil - "Generic Pointers", транслятор сам "разбирается" с типами памяти.

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

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

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

Сообщение отредактировал 777777 - Nov 3 2011, 10:04

[Палыч]

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

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

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

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

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

[777777]

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

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

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

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

"Эффективность" - понятие очень ёмкое. Каков критерий эффективности?

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

Впрочем, я ещё не видел у новичков эффективно написанных программ (в любом смысле). Но это проходит (а, иногда, - нет) с накопленным опытом.

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