=AK= 12 4 января, 2008 Опубликовано 4 января, 2008 · Жалоба Шведская компания IMSYS месяц назад выпустила новые процы IM3910 и IM3220. Архитектура IM3000 является дальнейшим развитием стекового проца Cjip, способного аппаратно исполнять Java байткоды. IM3910 работает на частоте 167 МГц, потребляя всего 42 мВт. Имеет два встроенных Эзернет МАК-а, и пр. IM3220 аппаратно поддерживает IEEE1588, поэтому будет использоваться в инструментах, подключаемых к LXI. В сопутствующих материалах шведы прошлись коваными сапогами по RISC-ам, популярно объяснив, что сама идея была гнилая и уже выдохлась. :) PS: ой, не в тот раздел запостил, здесь же DSP... :( Впрочем, INSYS хвалится, что со своим загружаемым микрокодом они и DSP могут. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 6 10 января, 2008 Опубликовано 10 января, 2008 · Жалоба также рулят lisp, forth, smalltalk, haskell и много других языков названия которых я даже и не знаю только "мужики об этом не знают" .... что меня удивляет, то даже для FPGA нет популярной реализации стекового проца, хотя учебных MISC процессорных HDL-сорцов дофига а все какие-то РИСК блейзы, ниосы или леоны. ------------------------------------- мир грязного кэша, светлые идеи не выживают :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 11 января, 2008 Опубликовано 11 января, 2008 · Жалоба также рулят lisp, forth, smalltalk, haskell и много других языков названия которых я даже и не знаю только "мужики об этом не знают" .... что меня удивляет, то даже для FPGA нет популярной реализации стекового проца, хотя учебных MISC процессорных HDL-сорцов дофига а все какие-то РИСК блейзы, ниосы или леоны. ------------------------------------- мир грязного кэша, светлые идеи не выживают :) насчет популярной не знаю, но проектов многоголовых форт монстров в сети много. причем народ рапортует о хорошей производительности систем. А вообще после выпуска линейки seaforth (24А чип например) проще не девелопить такого монстра а купить. ЗЫ. intellasys.net forth.org.ru Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kopa 0 18 марта, 2008 Опубликовано 18 марта, 2008 (изменено) · Жалоба что меня удивляет, то даже для FPGA нет популярной реализации стекового проца, хотя учебных MISC процессорных HDL-сорцов дофига а все какие-то РИСК блейзы, ниосы или леоны. Могу Вас обнадежить, для FPGA стековые процессоры есть ( 2-3 - точно можно и даже больше найти если не считать, что еще есть для Java ) Планирую сам этим вопросом озадачится. TF-16 в кристале у http://www.idm-plus.ru/ ( Российский форт процессор - перспектива использования в ЖКХ проектах ) Еще ждем книгу И. Тарасова где про их создание будет более подробно описано с главой вводящей в Форт язык, для требуемого уровня понимания излагаемых вопросов книги. P.S. Не все, конечно, мужики знают про Форт ( Forth), Lisp, Prolog ... :) но наверное им это и не нужно в их реалиях практической деятельности. Русский форум по форту http://fforum.winglion.ru/ ( 2-а года существования ) Изменено 18 марта, 2008 пользователем Kopa Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DRUID3 0 19 марта, 2008 Опубликовано 19 марта, 2008 · Жалоба Ой, объясните мне, малограмотному, благодаря каким это физическим принципам стековые процессоры могут работать быстрее чем процессоры с РОН или аккумулятором. Уж тем более быстрее DSP. А то, может и впрямь, повыбрасывать эти BlackFinы и на Shark забить ? Если верить классической литературе (и здравому смыслу) то стековая концепция выигрывает в компактности программ в размен на скорость работы, еще один ее немаловажный "+" - простота организации компиляторов, никаких тебе сверхсложных адесаций, никаких указателей, он только один - вершина стека - отсюда и выбор стековой машины для тех же Java и Forth. Кстати, рекурсия - в такой архитектуре практически основной инструмент, ибо как наиболее эффективна, кто с ней детально знаком на обычных процессорах поймет "цену" перехода только к стеку. А Java возник как очень удачный маркетинговый проект, эдакий Basiс будущего, высококвалифицированные узкоспециализированные программисты пишут такую стандартную машину для всех возможных типов и конфигураций процессоров, низкоквалифицированные "уличные"(это те кому у нас платят в полтора раза больше ЦОС разработчика :) ) пишут на универсальном языке, не заморачиваясь вопросами архитектуры. То что можно скачать Java-машину себе на комп забесплатно не свидетельство того, что Java это GNU, просто за x86 машину бабло отгребают у производителей x86 и все мы в той или иной мере за него заплатили. За остальные архитектуры надо платить напрямую, как например за Java для DSP TI. И никакой суперскорости, кроме суперскорости поиска персонала и работы над проектом тут нет. Стековая машина все время работает между объектным модулем и "живым процессором". Потому некоторые производители процессоров решили сделать "железную" java машину(например AVR32), т.е. разработчику не надо покупать сторонний софт, да и работает "оно" быстрее чем обычный процессор + софтовый. На ПЛИС мало проектов стековых ЭВМ именно потому, что к такой ЭВМ неплохо бы еще и язык, ибо классические неэффективны совсем, а с Java наверно возможны патентные трудности. Реально чем смогут похвастаться только стековые процессоры - низким энергопотреблением ввиду соей простоты. А свою нишу они конечно найдут, ведь не все же программисты пишут например на C/C++. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 12 5 июля, 2008 Опубликовано 5 июля, 2008 · Жалоба Ой, объясните мне, малограмотному, благодаря каким это физическим принципам стековые процессоры могут работать быстрее чем процессоры с РОН или аккумулятором. Уж тем более быстрее DSP. Вы "спорите" с тем, что сами напридумывали. Про "быстрее" никто, кроме вас, не говорил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 6 июля, 2008 Опубликовано 6 июля, 2008 · Жалоба Что-то темы такие пошли... Сначала DSP процессоры умирают! Теперь говорят, что ещё и RISC не катит! По-моему глупости всё это! Не более чем маркетинг...Нужно-же им свои процы продавать. Всё это было есть и будет ещё долго, я думаю... Java не люблю вообще! Ни разу не писал, не пишу и надеюсь, что не придётся писать на ней! Прикольно получается: сначала язык, а потом процы под него ))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 0 8 июля, 2008 Опубликовано 8 июля, 2008 · Жалоба Java не люблю вообще! Ни разу не писал, не пишу и надеюсь, что не придётся писать на ней! а Пастернака читали? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 9 июля, 2008 Опубликовано 9 июля, 2008 · Жалоба а Пастернака читали? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 6 16 июля, 2008 Опубликовано 16 июля, 2008 · Жалоба Вы "спорите" с тем, что сами напридумывали. Про "быстрее" никто, кроме вас, не говорил. я тоже слышал, что время исполненияОДНОЙ инструкции выше (логики меньше, цепи быстрее, тактовая выше) ну а арифметика и прочий datapath легко конвееризируется... НО есть подозрение, что на одну и ту же задачу для стекового компа потребуется больше операций, чем для CISC/RISC иначе бы никакие трудности форта/лиспа не помешали бы более-менее значительному использованию таких компов до 80-х существовало несколько моделей стековых компов, а потом почему-то их производство сошло на нет, вот собственно интересно бы причину узнать BTW: я в своих задачах вижу использование стекового компа в качестве видеоускорителя (векторная графика), но пока не могу убедить начальство в правильности такого подхода... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kopa 0 11 ноября, 2008 Опубликовано 11 ноября, 2008 (изменено) · Жалоба до 80-х существовало несколько моделей стековых компов, а потом почему-то их производство сошло на нет, вот собственно интересно бы причину узнать Неужели действительно были? :) Стековые процессоры изначально требовали накристального ОЗУ для размещения 2-ух стеков, + служебные регистры. ( поэтому сначала делались на россыпи ) Предположу, что делать накристальное ОЗУ было дорого для массовых компьютеров. Cкорее поэтому и основной потребитель стековых процессоров Nasa:) Поэтому прижились PDP-11, 580, Z80, X86 и др. с небольшим количеством операционных регистров. RISC появились при упрощении архитектуры и переноса проблем кодогенерации на компилятор. VLIW для более полного парралельного использования ресурсов процессора. MISC еще больше упрощает аппаратное ядро ( см. intellasys.net 40-ок MISC ядер!) P.S. http://82.138.13.156/rus.16bit.html ( продукция Форт контроллеров Российской IDM-PLUS ) Изменено 11 ноября, 2008 пользователем Kopa Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dch 0 12 ноября, 2008 Опубликовано 12 ноября, 2008 · Жалоба P.S. http://82.138.13.156/rus.16bit.html ( продукция Форт контроллеров Российской IDM-PLUS ) сайт в какомт разобранном состоянии и страничка контакты не вызывается Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kopa 0 12 ноября, 2008 Опубликовано 12 ноября, 2008 (изменено) · Жалоба сайт в какомт разобранном состоянии и страничка контакты не вызывается Да. Сайт, похоже, не доделан:) P.S. Если интересуют контакты, то на их страничке приведено. " Только наберите номер. Мы будем рады обсудить решение Вашего проекта. Европа: +33(0) 467 130 090 Россия: +7(499) 720-89-52 " Более правильные могу уточнить. ( были материалы их презентации ) Работают по контрактным темам. ( кто платит деньги ) Изменено 12 ноября, 2008 пользователем Kopa Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 6 27 ноября, 2008 Опубликовано 27 ноября, 2008 · Жалоба много спорных и необоснованных утверждений Стековые процессоры изначально требовали накристального ОЗУ для размещения 2-ух стеков, + служебные регистры. ( поэтому сначала делались на россыпи ) Предположу, что делать накристальное ОЗУ было дорого для массовых компьютеров. Cкорее поэтому и основной потребитель стековых процессоров Nasa:) на россыпи может делалось потому что не было микроконтроллеров массовых :) во вторых сделать микруху сильно дороже чем на россыпи собрать, даже сейчас с накристальным ОЗУ - тоже странно - я сразу могу предложить схемную реализацию бесконечного стека во внешнем ОЗУ, а в "накристальном" держать стек-кеши по 4-8 регистров. схемка с двумя указателями (счетчиками) и вполне реализуема на россыпи. за счет того, что стек елозит туда-сюда может быть вполне эффективная скорость с медленным внешним ЗУ. тогда не глупее были люди - например, тот же SPARC имеет подобную реализацию "псевдобесконечного" набора РОН и SPARC имеет предшественников (вполне может из ЛИСП компов) ну и применялись эти компы в университетских программах - насколько там NASA ANB DoD и прочие структуры замешаны неизвесно RISC появились при упрощении архитектуры и переноса проблем кодогенерации на компилятор. ради интереса посмотрите на кодогенератор х86 и какого-либо RISC-а в том же gcc - не верится, что гораздо больший объем кода понадобился там где проблем кодогенерации меньше Ж:) MISC еще больше упрощает аппаратное ядро ( см. intellasys.net 40-ок MISC ядер!) это точно. собственно это и интересно. но и на россыпи такое сделать было бы проще :) вопрос в том, что произойдет с С кодом интересный проект zpu (zylin) сам проц собственно ничего нового, но есть порт компилера и вроде бы код получается приличный. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kopa 0 28 ноября, 2008 Опубликовано 28 ноября, 2008 (изменено) · Жалоба много спорных и необоснованных утверждений Вам видней:) Осталось выяснить кто ещё так считает. на россыпи может делалось потому что не было микроконтроллеров массовых :) во вторых сделать микруху сильно дороже чем на россыпи собрать, даже сейчас Сейчас, делать на россыпи контроллеры, можно только из сильной любви к искусству. Обычно берётся плата с FPGA ( например c Xilinx) с накристальным ОЗУ - тоже странно - я сразу могу предложить схемную реализацию бесконечного стека во внешнем ОЗУ, а в "накристальном" держать стек-кеши по 4-8 регистров. Можно, только не будет ли это место "узким горлышком" в таком решении? тогда не глупее были люди - например, тот же SPARC имеет подобную реализацию "псевдобесконечного" набора РОН и SPARC имеет предшественников (вполне может из ЛИСП компов) Конечно не глупее и сделали достаточное количество разработок и реализаций Форт процессоров:) ( даже и в СССP - серия Дофин продолжение в Минске ) Один из примеров: RTX2000 - управляет аппаратурой на борту Cassini ( у Марса ) У Аtmel например, в продуктовой линейке, есть стековые контроллеры MARC4. ради интереса посмотрите на кодогенератор х86 и какого-либо RISC-а в том же gcc - не верится, что гораздо больший объем кода понадобился там где проблем кодогенерации меньше Ж:) А может ещё посмотреть на кодогенерацию PDP-11, Z80, 580 ? Одно не следует из другого :crying: Кодогенератор - это только попытка при большой семантической неопределённости программного кода решить проблемы эффективной кодогенерации для решаемой задачи. ( Тут мозги разработчика лучшая из возможных рекомендаций по использованию) это точно. собственно это и интересно. но и на россыпи такое сделать было бы проще :) Ничего не понял. вопрос в том, что произойдет с С кодом Вот это самое интересное. Брал LCC компилятор и с помощью разных front-end ( или back-end ) генерил стековый код и проверял его работоспособность и скорость работы на PC. Могу сказать, что код работал так как и ожидалось а эффективность при использовании на нестековом процессоре трудно сравнить с ожидаемым. Плюс необходимо решать задачу оптимизации промежуточного представления кода. В качестве дополнительной информации: на PC русские форт программисты используют Форт систему SPF и при peephole оптимизации на тестовых задачах она несильно проигрывает коммерческим Си компиляторам. ( при этом размер компилятора ~40...90Кб и половина исходных текстов ~150Кб занимает сам оптимизатор.) P.S. Выводы делать Вам, но можно повторить, что стековые процессоры выигрывают прежде всего, в отношении производительность/потребление. Но это можно оспаривать или нет, пока сам реально не попробуешь это:) интересный проект zpu (zylin) сам проц собственно ничего нового, но есть порт компилера и вроде бы код получается приличный. А в чём интересный? По каким критериям и с чем сравнивался? Эволюционное сравнение одних и тех же архитектурных решений может быть неправильным. что меня удивляет, то даже для FPGA нет популярной реализации стекового проца, хотя учебных MISC процессорных HDL-сорцов дофига а все какие-то РИСК блейзы, ниосы или леоны. FPGA реализаций стековых процессоров есть n-ое количество. А популярность - это что то из области пристрастий или привычек использования массовых изделий, как Вам нравится :beer: Изменено 28 ноября, 2008 пользователем Kopa Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
