caxapa.ru :: Почему это в Гарвардской системе программа не может выполняться из ОЗУ? В чем загвоздка-то?

reZident (25.02.2025 02:01, просмотров: 363) ответил Adept на вот кстати, размышляя по поводу архитектур "самодельных ПК" применительно к имеющимся под рукой микроконтроллерам, производительность которых уже на уровне 386-486-х :) , - "гарвард" супротив "фон-Неймана" имеет существенный минус - программы не могут исполняться в ОЗУ :( на крайняк, во флеши м.б. интерпретатор (или даже компилятор), а в ОЗУ/внешней памяти исполняемый скрипт на "ЯВУ". Иначе, - только перепрограммирование флеши "на лету" :( или есть ещё какой способ?

Почему это в Гарвардской системе программа не может выполняться из ОЗУ? В чем загвоздка-то?

Ответить

- "гарвард" это раздельная память программ и данных. Если и сделать исполнение программ из внешней памяти (что теоретически возможно, если это внешняя память исключительно для программ, но на практике я такого не встречал). то, вероятно, будут ещё и крайне ограничены способы адресации, т.к. зачастую даже разрядность командного слова не кратна байту. - Adept(25.02.2025 02:14)
  - Ну дык это и есть основная разница гарвардской и фон-неймановской архитектур - способ адресации программы и данных. Поэтому я и удивился вашему заявлению, что из ОЗУ нельзя программу выполнять. Даже на классическом 8051 можно было размещать программу во внешней памяти (более того выпускались 80С31 вообще без встроенной ПЗУ). А что там снаружи - ПЗУ или ОЗУ или их комбинация, не один ли хрен? - reZident(25.02.2025 11:22)
    - Попробуйте-ка поисполнять программу из ОЗУ в процессоре AVR например mega8. Там это физически невозможно: CPU физически не может извлечь опкоды из RAM. Это пример классической Гарвардской архитектуры место которой в топке! - 3m(27.02.2025 17:43)
      - так и хоцца спросить, а нахрена АВРу это нужно? Я на АВР сижу с +/-2000года и ни разу не сталкивался с потребностью исполнить код из ОЗУ. Чо я неправильно делаю? - mse homjak(28.02.2025 10:50)
        
        исполнение подгружаемых процедур и самомодификация программ, в рамках более широких, чем прелагает возможность самопрограммирования флеши (поддерживаемая толькор мегами/икспегами, кстати) - Adept(28.02.2025 13:33)
        
        Т.е. предлагаете в функцыанально-законченном устройстве, за каким-то хреном, подгружать непойми что? Зачем? Вот стоит на столе прибор, чо мне в него подгружать? И чего ему подгружать? В ембеддед, весь смысл в том, что устройство написано "раз и навсегда". До апгрейда или ремонта. Не, ну я могу придумать ситуаццыю, когда условной М128 , помимо 128к набортного флэша, понадобилось сделать библиотеку функцый на мегабайт и грузить их в работе. Ну дык, поставьте проц с мегабайтом mse homjak(47 знак., 28.02.2025 14:36)
        
        ну дык говорю, - чисто теоретические измышления. Понятно, что под такую задачу легче просто какой-нить одноплатник поставить с линухом :)) - Adept(28.02.2025 15:11)
        
        ИМХО это означает лишь, что для таких задач неправильно выбран класс устройств. Вместо AVR берите АМУР32 ;-) - reZident(28.02.2025 13:38)
        
        эт понятно конечно, был вопрос, я ответил :) а вообще, теоретически, возможно такое вкупе с требуемым микропотреблением и микрогабаритами .... (фантазирую немного, но почему нет?, - тогда только какойнить МК) а прикольно было бы видеть умение мк исполнять код из SPI фдеши :)) да медленно, но зато нет ограничения по размеру программы :) - Adept(28.02.2025 13:55)
        
        Кстати, у АМУР32 ядро тоже "гарвардское". reZident(1 знак., 28.02.2025 14:03, ссылка)
        
        Так же как Cortex-M3 и многие другие. Я пытался втолковать авроводам, что слово Гарвард не является оправданием кривизны, но они не хотели слушать :-) - SciFi(28.02.2025 14:08 - 14:19)
        
        Тама просто регистры маленькие, вот и не получается в одно адресное пространство впихнуть разные шины. У армов есть целых 32 бита извращаться как угодно, назначая диапазоны "тут выполняем, там не выполняем, а здесь не кэшируем". - LightElf(28.02.2025 17:39)
        
        Ну, большинство ДСП, имеет шину кодов, и, минимум, две шины данных. Разделение шын позволяет сократить конвейер и, соотвецтвенно, дать больше команд на клок. - mse homjak(28.02.2025 17:08)
        
        Разные шины для команд и для данных и разные способы адресации команд и данных это не тождественные понятия вообще-то. - reZident(28.02.2025 14:17)
        
        Пофиг. Очевидно, логика такая: раз Гарвард, значит, надо брать :-) - SciFi(28.02.2025 14:19)
        
        Лучше брать Гринвич - там расположена точка отсчета и он банально ближе :-P - reZident(28.02.2025 14:21)
        
        Этого добра сейчас навалом. Гуглить SPIFI. АМУР 32 это тоже умеет, кстати. - SciFi(28.02.2025 13:58)
      - Еще раз. Принципиальное отличие двух архитектур в способе адресации. Для 80С51, AVR и т.п. эти адресные пространства разделены унутри кристалла, но при подключении внешней памяти их (адресное пространство программ и адресное пространство данных) можно объединить. - reZident(27.02.2025 20:12)
        
        тогда это не будет уже тем же кристаллом :)) это примерно как попытаться вытащить кеш из процессора наружу :) теоретически можно (и даже практически делали, - вспомним слотовые пентиумы :)) но применительно к МК, - то чисто теоретические измышления. Реально взять, скажем АВР и заставить его исполнять опкоды из внешней памяти - вот "фигвам" :) - Adept(27.02.2025 21:43)
        
        FPSLIC, скока угодно. Но, ИМХО, там ИДЕ кривое, наскока можно. Кажись, ТочкаОпоры жаловался. - mse homjak(28.02.2025 10:53)
    - Ну там было не всё таг просто. Для ОЗУ nRD, nWR, а для программы, nPSEN. Логикой можно было куролесить, но, формально, адресные пространства разные. - mse homjak(25.02.2025 12:17)

Программируемая логика и ЦОС