Перейти к содержанию
    

Маленький процессор для Xilinx

1 минуту назад, aaarrr сказал:

При работе с RO-данными.

 

И какой код на С для AVR не будет работать? 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 minute ago, dxp said:

И какой код на С для AVR не будет работать?

Любой, требующий RO-данных больше, чем доступный объем ОЗУ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 minute ago, dxp said:

Модель памяти языка Си тут как мешает? 

Не позволяет использовать доступные ресурсы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 минуты назад, aaarrr сказал:

Любой, требующий RO-данных больше, чем доступный объем ОЗУ.

Кроме того, ровно то же самое можно сказать и про "ненастоящий" гарвард Blackfin. 

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

Не позволяет использовать доступные ресурсы.

Если вы про размещение данных во флеши, то это не ограничение языка С. Унифицированное адресное пространство тоже не гарантирует возможность доступа в сегмент флеши по шине данных. Это особенности реализации (микроархитектуры). 

 

Ну, а костыли-то мы увидим? Код на Си?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

47 minutes ago, dxp said:

Хотите сказать, что программная модель языка Си различается для разных процессоров?

Вообще-то ЯВУ придумали для того, чтобы сгладить различие архитектур разных процессоров (и тема не о том, насколько хорошо под эту роль подходит Си). Все, что необходимо знать для компиляции под целевой процессор, составляет программную модель процессора, это и есть архитектура в практическом смысле.  

 

У меня, например, подмножество Си, компилятор LCC, но программная модель памяти и близко не похожа на стандартную. Например, подпрограммы с локальными переменными могут иметь любую вложенность в пределах доступной памяти, но понятия стека нет ни в программном, ни в аппаратном смысле. 

Изменено пользователем Leka

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 минуты назад, Leka сказал:

Вообще-то ЯВУ придумали для того, чтобы сгладить различие архитектур разных процессоров (и тема не о том, насколько хорошо под эту роль подходит Си). Все, что необходимо знать для компиляции под целевой процессор, составляет программную модель процессора, это и есть архитектура в практическом смысле.   

Пардоньте, но что-то демагогия какая-то пошла. Были ведь конкретные заявления:

47 минут назад, Leka сказал:

Неважно, как конкретно делается компиляция, важно, что для компиляции нужна программная модель памяти (а не физическая организация), и это входит в понятие архитектуры.

На что был задан вполне конкретный вопрос:

44 минуты назад, dxp сказал:

Хотите сказать, что программная модель языка Си различается для разных процессоров?

Ну, так ответьте на этот простой и конкретный вопрос: отличается ли модель памяти языка программирования Си для разных процессоров? Если отличается, то чем? в чём?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

28 minutes ago, dxp said:

Ну, а костыли-то мы увидим? Код на Си?

- Язык C не предполагает наличия различных полей памяти. Возражения есть?

- Архитектура AVR подразумевает расположение RO-данных в поле памяти программ. Костыли в виде всяких const __flash xxx наличествуют.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

 
On 7/5/2021 at 6:18 PM, Tanya said:

Самый бессмысленный спор - терминологический.

 

С нетерпением ждем 100500 страниц по теме: Гарвард vs Нейман.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

13 minutes ago, dxp said:

отличается ли модель памяти языка программирования Си для разных процессоров?

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

8 часов назад, aaarrr сказал:

Архитектура AVR подразумевает расположение RO-данных в поле памяти программ. Костыли в виде всяких const __flash xxx наличествуют.

А ещё там есть EEPROM, третье отдельное адресное пространство, где можно размещать данные (снова костыли :)). И какая же тогда это архитектура? Super True Harvard? А у AT90S1200 нет памяти данных, совсем. Это что за вариант? Недо фон Нейман?

 

Наличие единого адресного пространства совершенно не гарантирует возможности размещать данные во флеши. Кроме того, доступ во флешь очень медленный. Современные МК способны работать на тактовых порядка 500 МГц, константа, размещённая во флеши и в ОЗУ будет иметь разницу в скорости доступа на полтора порядка. И если это не "костыли", так подводные грабли как минимум - программист, объявив объект константой, получает лютые тормоза на доступе к этому объекту.

 

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

 

8 часов назад, aaarrr сказал:

Язык C не предполагает наличия различных полей памяти. Возражения есть?

Хорошо, в этом сошлись: шинная архитектура не влияет на модель памяти C/C++.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

16 hours ago, dxp said:

Т.е. ARM для вас неавторитетный источник. А кто ж тогда авторитетный кроме вас самого?

Читайте внимательней, что я писал насчёт авторитетности.

16 hours ago, dxp said:

А что такое "просто "architecture""? ISA? А где в ISA упоминается способ доступа в адресное пространство?

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

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

16 hours ago, dxp said:

Да уж, совсем разные. Позволяет не только одновременный доступ в память инструкций и данных, но и использовать память инструкций как память данных - по сути использовать шину инструкций как ещё одну шину данных (и подкачивать больше операндов для обработки в единицу времени, что актуально для DSP особенно во время коротких аппаратных циклов, когда за инструкциями в память лазить не надо, и шина инструкций может использоваться для подкачки данных из памяти инструкций).

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

16 hours ago, dxp said:

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

Итак, вы утверждаете, цитирую: "важно то, как вы к этому осуществляете доступ - если вы к этой памяти за кодом и данными лезете по очереди по одной шине, это фон Нейман, если можете достать очередную инструкцию и данные одновременно по разным шинам - это Гарвард". Исходя из этого Вашего утверждения, получается, что, если моя программа, выполняющаяся ядром Cortex-M3, расположена в ITCM (одна шина), а данные -- в DTCM (другая шина), то Cortex-M3 -- гарвард. Но, исходя из этого же Вашего утверждения, если я для того же самого Cortex-M3 расположу и программу, и данные в ITCM (это сделать можно) или во внешней памяти, доступ к которую осуществляется через AHB, то Cortex-M3 превращается в фон-неймана. Я Вас правильно понимаю?

 

 

15 hours ago, dxp said:

Возьмём "настоящую" - AVR. Какие костыли?

Конкретно с AVR8 пару лет назад я натолкнулся однажды на проблему. Использовалась самая что ни на есть обычная printf, но первый параметр (строка формата) был представлен не константой, как это обычно бывает, а строкой в ОЗУ (формирующейся динамически). Сей код не работал -- как раз потому, что архитектура у проца гарвардская, а реализация printf предполагала, что первый параметр будет лежать в ПЗУ. Проблема сия вытекает именно из принципиального различия гарварда и фон-неймана (разные адресные пространства), а отнюдь не из числа шин и физических способов доступа к памяти (на АРМах printf работает без проблем независимо от того, размещается строка формата в памяти кода или памяти данных).

15 hours ago, dxp said:

Если вы про размещение данных во флеши, то это не ограничение языка С. Унифицированное адресное пространство тоже не гарантирует возможность доступа в сегмент флеши по шине данных. Это особенности реализации (микроархитектуры).

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

А вот будет ли конкретная область адресов доступна в конкретной реализации, архитектура не гарантирует и не должна гарантировать -- это уже уровень реализации.

14 hours ago, aaarrr said:

Костыли в виде всяких const __flash xxx наличествуют.

И это -- именно что костыли, которых в стандартном Си/Си++ нет. А всё из-за костыльности гарвардской архитектуры :) (И, замечу, в фон-неймановских процах такие костыли не нужны -- даже если некоторые записывают эти процы в гарвардские).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 10/1/2021 at 12:55 PM, des00 said:

но вообще под него делали си комплиятор, даже работал

Он работал так, что лучше бы вообще его не существовало, практически ничего в нем не работало, даже простейший код...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...