ыыыыыыыыыы (28.04.2015 23:23, просмотров: 1) ответил Evgeny_CD на Предел процессоростроения. Навеяно топиком про планы Imagination в части продвижения MIPS в головы студентов. ->-
- Вот еще eP32 - форт процессор в мелкой ПЛИСке -> Внутри интересные файлы --> Evgeny_CD(29.04.2015 21:50 - 21:56, ссылка, ссылка)
- Zylin CPU, ZPU, о который (ы) упоминал -> --> В целом, из файла описания архитектуры там хорошо видно, что это за зверь такой - стековые процессоры. - Evgeny_CD(29.04.2015 17:40, ссылка, ссылка)
- Репозиторий ZPU -> - Evgeny_CD(26.04.2018 22:49, ссылка)
- J1: a small Forth CPU Core for FPGAs -> --> компактность кода как проца, так и, скажем, IP стека для него, просто поражает. - Evgeny_CD(28.04.2015 23:35, ссылка, ссылка)
- по модному их MISC (minimal instruction set computer) называют - ыыыыыыыыыы(28.04.2015 23:26,
)
- Спасибо! - Evgeny_CD(28.04.2015 23:29)
- Я уже достаточно стар, чтобы исповедовать философию "спустимся в долину и отимеем все стадо". :) Спасибо, что напомнили - я давно на них не смотрел. - Evgeny_CD(28.04.2015 23:25)
- Со стековыми процессорами есть такая засада, как плотные зависимости в коде, в результате чего тяжко создавать суперскаляры с ОоОЕ и, тем более спекуляциями :-). Поэтому высокой производительности можно не ожидать. - =AlexD=(29.04.2015 08:19 - 10:41)
- Рассмотрим вопрос высокой производительности подробнее. С точки зрения embedded. Evgeny_CD(1305 знак., 29.04.2015 12:26)
- Суперскалярность - это единственный способ ускорить исполнение кода не повышая частоты. Именно для эмбеддед - самое то. И Cortex M7 - шаг именно в этом направлении. Что касается остального, то можно присмотреться к эволюции Мультиклета. =AlexD=(521 знак., 29.04.2015 13:14)
- (ы) постил тут про мегапроцик, который весь построен на этой идее. Опять же все восходит к идее асимметричной много ядерности, когда каждый процик иметь свой независимый поток команд. Я о том же писал. - Evgeny_CD(29.04.2015 14:26)
- Вопрос в том, нужно ли ускорять исполнение кода в embedded? Берем ядро типа Cortex-M4F, к нему десяток ядер типа AVR с ОЗУ вместо флеша, какое-нить минимальное средство общения между ЦП и ПП. И вуаля. На каждую кнопку - своя тинька, на каждый уарт LightElf(64 знак., 29.04.2015 13:46)
- Ну есть lpc43xx и lpc54xxx и чо? Геморрой как по мне. - =AlexD=(29.04.2015 13:58)
- 1) были 2) вибриды тоже гетерогенные 3) первый блин комом не означает неправильность идеи. - Evgeny_CD(29.04.2015 14:20)
- Вибрид достаточно логичный, но вот всякие кэши на CM4 нифига не радуют. Ну и общая шина тоже. - LightElf(29.04.2015 15:03)
- Кеши и hard RT не совместимы. Совсем. Посему и двигаются идею отдельного ядра для RT. - Evgeny_CD(29.04.2015 15:08)
- чегооо??? а в глаз за такие слова??? - Mahagam(29.04.2015 15:25)
- ? Точнее, транзакции по всем шинам проца должны всегда занимать одно и то же время. - Evgeny_CD(29.04.2015 15:29)
- никуа. они должны вкладываться в лимит времени. и всё. для остального есть DMA и аппаратные модули. - Mahagam(29.04.2015 15:31)
- ? Точнее, транзакции по всем шинам проца должны всегда занимать одно и то же время. - Evgeny_CD(29.04.2015 15:29)
- чегооо??? а в глаз за такие слова??? - Mahagam(29.04.2015 15:25)
- Кеши и hard RT не совместимы. Совсем. Посему и двигаются идею отдельного ядра для RT. - Evgeny_CD(29.04.2015 15:08)
- Вибрид достаточно логичный, но вот всякие кэши на CM4 нифига не радуют. Ну и общая шина тоже. - LightElf(29.04.2015 15:03)
- там ядра не те. Cortex-M0 - плохой выбор для периферийного проца. Нужно именно что-то простое, абсолютно детерминированное, с отдельными блоками оперативной памяти для кода и данных. У TI есть в ряде камней PRUSS, но он тоже какой-то убогий и LightElf(259 знак., 29.04.2015 14:20)
- Я не уверен, что ядро AVR меньше Cortex-M0, отдельные блоки код/данные можно сделать двумя банками, фоннейман однозначно лучше, __flash заё#$@ет. Не, ну правда, попробуйте покодить - никакого особого преимущества нет, только лишний гемор. - =AlexD=(29.04.2015 14:28)
- Этот ваш кортекс придумали ламиры не осилившие ассемблера x51! - fk0(30.04.2015 01:24)
- __flash мешает, когда у вас standalone AVR и вы пытаетесь всю логику программы реализовывать. А если у него вся затея - ножкой хитро подрыгать, то __flash и не потребуется. Гарвард дает детерминизм, чего кортексам явно не хватает. - LightElf(29.04.2015 14:38)
- Блин, О5-25, делаются раздельные банки ОЗУ для кода и данных с раздельными шинами - и здравствуй детерминизм. В AVR без __flash и таблицу констант не обработать, не дублируя в ОЗУ, чистый гарвард фтопку. - =AlexD=(29.04.2015 14:43)
- Что мешает ЦП положить таблицу констант сразу в ОЗУ данных этого AVR? - LightElf(29.04.2015 14:53)
- К примеру, таблица имеет размер с половину ПЗУ и 5 раз ОЗУ. Кто виноват? Что делать? - SciFi(29.04.2015 14:54)
- С чего вы взяли, что таблица не помещающаяся в ОЗУ данных поместится в ОЗУ команд? - LightElf(29.04.2015 14:57)
- Да ладно, не важно. Я просто ещё раз говорю, что нафиг они сделали проц, который не совместим со стандартным Си? Собственно, поэтому я его никогда и не трогал. - SciFi(29.04.2015 15:02)
- Коллеги, кто на примере кода пояснил эту несовместимость? Не дайте умереть неучем. - Evgeny_CD(29.04.2015 15:05)
- откуда тогда костыли с аттрибутом flash ? - Mahagam(29.04.2015 15:29)
- Буду благодарен, если поясните. - Evgeny_CD(29.04.2015 15:30)
- кратко, у авр указатель на рам и указатель на флеш не совсем равнозначны. доступ к _данным_ во флешке идёт через отдельную команду LPM, посему просто скормить функции указатель невозможно, функция должна знать это указатель на флеш или на раму. Mahagam(20 знак., 29.04.2015 15:38)
- Ну и чо? Полюбому, указатель и сегмент памяти определять, что она рид-онли, хотябы. Вон, расово-верный МИПС и то требует. - mse homjak(27.04.2018 18:38)
- Некропостинг, однако. Суть в том, что у фон Неймана достаточно передать в функцию указатель на объект. У гарварда нужно еще передать тип этого указателя (указывает он в пространство данных или в пространство кода, патамучта работа с этими LightElf(248 знак., 27.04.2018 22:44)
- Вам-то какая разница? Вы определили указатель на тип данных и не парьтесь, чо куда впиндюрит компилер. Бдь, я прям вспоминаю молодость и эпические срачи "Це вс АСМ". Да, в АСМ это имеет значение, какими инструкциями ковырять датые. А в Це, чего mse homjak(99 знак., 28.04.2018 09:27 - 09:44)
- Вы уже заипали с вашими гарвардами. Это отговорка для лохов. Есличо, CM3 тоже гарвард, в то же время всё там нормально с единым адресным пространством. Ящетаю, гарвард давно пора сжечь на костре. - SciFi(27.04.2018 22:47)
- В 32-х битах все сильно проще. Можно часть указателя использовать для выбора адресного пространства (что собственно и сделано в Cortex-m). 8-битнику сложнее. - LightElf(28.04.2018 00:36)
- Ага, поэтому засунули бит адреса в опкод. Гениально :-) - SciFi(28.04.2018 09:49)
- В 32-х битах все сильно проще. Можно часть указателя использовать для выбора адресного пространства (что собственно и сделано в Cortex-m). 8-битнику сложнее. - LightElf(28.04.2018 00:36)
- Некропостинг, однако. Суть в том, что у фон Неймана достаточно передать в функцию указатель на объект. У гарварда нужно еще передать тип этого указателя (указывает он в пространство данных или в пространство кода, патамучта работа с этими LightElf(248 знак., 27.04.2018 22:44)
- а IAR придумала костыль для костылей - __generic - Vit(30.04.2015 07:26)
- Не "не совсем равнозначны", а совсем не равнозначны. Чистый гарвард: есть адресное пространство команд и есть адресное пространство данных. Каковые между собой не пересекаются совсем. Адрес команды 0x1234 и адрес данных 0x1234 - абсолютно разные LightElf(228 знак., 29.04.2015 17:27)
- Спасибо! - Evgeny_CD(29.04.2015 17:37)
- Спасибо! - Evgeny_CD(29.04.2015 15:50)
- Ну и чо? Полюбому, указатель и сегмент памяти определять, что она рид-онли, хотябы. Вон, расово-верный МИПС и то требует. - mse homjak(27.04.2018 18:38)
- кратко, у авр указатель на рам и указатель на флеш не совсем равнозначны. доступ к _данным_ во флешке идёт через отдельную команду LPM, посему просто скормить функции указатель невозможно, функция должна знать это указатель на флеш или на раму. Mahagam(20 знак., 29.04.2015 15:38)
- Буду благодарен, если поясните. - Evgeny_CD(29.04.2015 15:30)
- откуда тогда костыли с аттрибутом flash ? - Mahagam(29.04.2015 15:29)
- Коллеги, кто на примере кода пояснил эту несовместимость? Не дайте умереть неучем. - Evgeny_CD(29.04.2015 15:05)
- Да ладно, не важно. Я просто ещё раз говорю, что нафиг они сделали проц, который не совместим со стандартным Си? Собственно, поэтому я его никогда и не трогал. - SciFi(29.04.2015 15:02)
- аха, смешно, и эти люди предлагают быстро шевелить лапками, цЫрк - =AlexD=(29.04.2015 14:55)
- С чего вы взяли, что таблица не помещающаяся в ОЗУ данных поместится в ОЗУ команд? - LightElf(29.04.2015 14:57)
- К примеру, таблица имеет размер с половину ПЗУ и 5 раз ОЗУ. Кто виноват? Что делать? - SciFi(29.04.2015 14:54)
- +100500. Эти фанаты атымеля каждый раз поднимают гарвард на флаг: мы тут самые правильные! Не хотят признать сами себе, что атымел их поимел. Такую подлянку подсунули - вредители, адназначна. SciFi(84 знак., 29.04.2015 14:47)
- С учётом того, что у них получилось очень походе на СМ-2М (ну или DEC) лучше бы писали, что специально для Паскаля. Или бейсик :) symbions(228 знак., 05.06.2015 11:37)
- Что мешает ЦП положить таблицу констант сразу в ОЗУ данных этого AVR? - LightElf(29.04.2015 14:53)
- М3 вполне себе гарвардский - шины раздельные. - Evgeny_CD(29.04.2015 14:42)
- Блин, О5-25, делаются раздельные банки ОЗУ для кода и данных с раздельными шинами - и здравствуй детерминизм. В AVR без __flash и таблицу констант не обработать, не дублируя в ОЗУ, чистый гарвард фтопку. - =AlexD=(29.04.2015 14:43)
- Отсутствие нормальных средств разработки для одновременной разработки независимого кода для нескольких ядер - это не проблема идеи многоядерности. - Evgeny_CD(29.04.2015 14:32)
- Блин, да тупо открой десяток IDE в которых по десяток точек останова и поотлаживайся /ща мы со всей этой х-нёй попытаемся взлететь/, не говоря уж за то, что ширпотребовские отладчики такое не очень поддерживают. - =AlexD=(29.04.2015 14:37)
- Отучись от пошаговой отладки. Во-первых. Во-вторых -- разделяй и властвуй. По другому большую систему не построишь. Каждый CPU решает свои задачи и может быть отлажен отдельно. Конечно, это ведёт за собой какую-то форму test driven development. - fk0(30.04.2015 01:26)
- 1) мы оба знаем, что 100500 окон не помогут, 2) у меня в этой части пока нет законченной идеи. - Evgeny_CD(29.04.2015 14:40)
- 2) скажем так, тут требуется гораздо больше работы над отладочной средой, чем для банальной двухмикроконтроллерной системы. Как минимум отладчик должен понимать, что загружает и запускает код не он, но он должен уметь автоматически подхватывать =AlexD=(66 знак., 30.04.2015 07:26)
- да я просто слегка похлебал lpc, и меня это заметно утомило, поэтому я злой, а на идею увеличить гимор в разы впадаю в эпилептический припадок - =AlexD=(29.04.2015 14:52)
- Но человечество невиновато в косяках тех, кого уже, можно сказать, нет больше с нами. - Evgeny_CD(29.04.2015 15:00)
- При современном состоянии эрратогенерации, нет надежды на лучший результат. - =AlexD=(29.04.2015 15:02)
- Но человечество невиновато в косяках тех, кого уже, можно сказать, нет больше с нами. - Evgeny_CD(29.04.2015 15:00)
- Блин, да тупо открой десяток IDE в которых по десяток точек останова и поотлаживайся /ща мы со всей этой х-нёй попытаемся взлететь/, не говоря уж за то, что ширпотребовские отладчики такое не очень поддерживают. - =AlexD=(29.04.2015 14:37)
- Блок нормальной CPLD в жирном CPU гораздо полезнее десятка сопроцессоров. - =AlexD=(29.04.2015 14:29)
- Процесс отладки заиграет новыми красками. - LightElf(29.04.2015 14:55)
- :) зато веселье будет качественным! - Evgeny_CD(29.04.2015 14:59)
- Да, но: 1) требования к скилам разработчика резко растут 2) нет GCC для большинства плисов одновременно, 3) в мире цплд все закопирайчено - умаешься платить лицензионные платежи. - Evgeny_CD(29.04.2015 14:36)
- Процесс отладки заиграет новыми красками. - LightElf(29.04.2015 14:55)
- Мне очень понравилась идея PRUSS в части коротких адресов для периферии в памяти. Кода можно съэкономить немало при интенсивном IO. - Evgeny_CD(29.04.2015 14:23)
- Возьмите AM5728, в нем до двух PRU-ICSS, в каждом два PRU. Работают на 200 МГц. Ruslan(246 знак., 29.04.2015 16:21 - 16:27)
- i8089? - teap0t(30.04.2015 15:52)
- i8089 вроде бы просто навороченный DMA контроллер? Я его не программил, потому представление очень поверхностное имею. - LightElf(30.04.2015 16:10)
- Сопроцессор ввода/вывода со своей системой команд. Дополнение к i8087. Но народ не поддержал, в отличие от. - teap0t(30.04.2015 21:31, ссылка, ссылка)
- Да, хорошая была штучка. Помянем. Evgeny_CD(01.05.2015 00:43)
- Сопроцессор ввода/вывода со своей системой команд. Дополнение к i8087. Но народ не поддержал, в отличие от. - teap0t(30.04.2015 21:31, ссылка, ссылка)
- i8089 вроде бы просто навороченный DMA контроллер? Я его не программил, потому представление очень поверхностное имею. - LightElf(30.04.2015 16:10)
- Ну вот типа того что-то. Можно побольше и
без хлебас компилятором Це? - LightElf(30.04.2015 13:23)- К PRU обещают компилятор Це. - Ruslan(30.04.2015 13:37)
- i8089? - teap0t(30.04.2015 15:52)
- Возьмите AM5728, в нем до двух PRU-ICSS, в каждом два PRU. Работают на 200 МГц. Ruslan(246 знак., 29.04.2015 16:21 - 16:27)
- Я не уверен, что ядро AVR меньше Cortex-M0, отдельные блоки код/данные можно сделать двумя банками, фоннейман однозначно лучше, __flash заё#$@ет. Не, ну правда, попробуйте покодить - никакого особого преимущества нет, только лишний гемор. - =AlexD=(29.04.2015 14:28)
- 1) были 2) вибриды тоже гетерогенные 3) первый блин комом не означает неправильность идеи. - Evgeny_CD(29.04.2015 14:20)
- Ну есть lpc43xx и lpc54xxx и чо? Геморрой как по мне. - =AlexD=(29.04.2015 13:58)
- Суперскалярность - это единственный способ ускорить исполнение кода не повышая частоты. Именно для эмбеддед - самое то. И Cortex M7 - шаг именно в этом направлении. Что касается остального, то можно присмотреться к эволюции Мультиклета. =AlexD=(521 знак., 29.04.2015 13:14)
- Рассмотрим вопрос высокой производительности подробнее. С точки зрения embedded. Evgeny_CD(1305 знак., 29.04.2015 12:26)
- Со стековыми процессорами есть такая засада, как плотные зависимости в коде, в результате чего тяжко создавать суперскаляры с ОоОЕ и, тем более спекуляциями :-). Поэтому высокой производительности можно не ожидать. - =AlexD=(29.04.2015 08:19 - 10:41)