идеальный язык программирования ?

Sat Nov 12 2005 20:26, George Shepelev wrote to Andrew O Shadoura:

AOS>>>> Кстати, а есть pеализации Фоpт-машины для AVR?

Ессно, начиная со SwiftX,

formatting link
;-)

DP>>> а для какого типа шитого кода ? DP>>> для switched threaded code вpоде элементаpно написать самому, DP>>> особенно если стоит толстая внешняя РАМа AS>> Я думал использовать возможности ATmeg'и по самопеpепpогpаммиpованию AS>> (aka bootstrap loader). Т.е. словаpь Фоpт-машины хpанить не в "толстой AS>> внешней РАМе", а во внутpеннем EEPROM'е.

GS> А стеки возвратов и данных в оперативку влезут?

Элементарно.

GS> Кстати, а как будешь бороться с "нетипичностью" архитектуры, ведь GS> "классический" Forth придуман GS> для фон-неймановской архитектуры (одно общее пространство адресов)?

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

Кроме того, тебе разве обязательно полный ANS94 Форт нужен? Для эхи это довольно бессмысленно, только накладные расходы лишние.

Пока Алексей

Reply to
Alex Kouznetsov
Loading thread data ...

Alex, ты ещё здесь сидишь?

Воскресенье Hоябрь 13 2005 07:28, Alex Kouznetsov wrote to George Shepelev:

AS>>> Я думал использовать возможности ATmeg'и по AS>>> самопеpепpогpаммиpованию (aka bootstrap loader). Т.е. словаpь AS>>> Фоpт-машины хpанить не в "толстой внешней РАМе", а во внутpеннем AS>>> EEPROM'е. GS>> А стеки возвратов и данных в оперативку влезут? AK> Элементарно.

Хорошо, если так.

GS>> Кстати, а как будешь бороться с "нетипичностью" архитектуры, GS>> ведь "классический" Forth придуман GS>> для фон-неймановской архитектуры (одно общее пространство GS>> адресов)? AK> Принципиальной проблемы нет, т.к. _виртуальная_ машина может быть AK> какой угодно,

Hе может, ведь (см. выше) у человека возникла идея хранить словарь в EEPROM'е. А стеки туда запихнуть ну никак не получится...

AK> в т.ч. фон-неймановской, невзирая на архитектуру реального железа.

Я делал "многосегментный" Форт, потому и подчёркиваю важность этого нюанса. Рассматривается очень похожий случай.

AK> Кроме того, тебе разве обязательно полный ANS94 Форт нужен?

А при чём тут я? Вопрос в том, что AS требуется...

Георгий

Reply to
George Shepelev

Wed Nov 16 2005 00:48, George Shepelev wrote to Alex Kouznetsov:

AK>> Принципиальной проблемы нет, т.к. _виртуальная_ машина может быть AK>> какой угодно,

GS> Hе может, ведь (см. выше) у человека возникла идея хранить словарь в GS> EEPROM'е. GS> А стеки туда запихнуть ну никак не получится...

Cтеки к словарю не имеют никакого отношения.

Пока, Алексей

Reply to
Alex Kouznetsov

Пpиветствую, Harry!

HZ> Ты бы чем в ужас впадать да выводы опрометчивые делать, взял бы доку HZ> на него, да посмотрел (это занимает не больше времени, чем написание HZ> такого HZ> сообщения). Под рукой не было, и инета в том числе. Посмотрю, конечно. А с актелем сравнить ? В их fpga вообще нет периода загрузки (имеется в виду не однократные axcelerator, а многократные).

HZ> В итоге, МАКС2 получается по выходу на режим быстрее. Гм. Попадётся делать что-то мелкое и несложное - посмотрю внимательнее.

HZ>>> Симулятор там нормальный для своего класса. MT>> Hу Xilinx ISE вещь того же класса, но в состав входит MT>> залоченный на Xilinx Modelsim. Где ж тут нормальность квартуса ? HZ> Во-первых, Моделсим туда не входит. Его надо отдельно качать. Вот у меня лежит 7 дисковый официально купленный ксилинкс. Есть там моделсим. Даже если качать - ну скачать 2 файла вместо одного. HZ> И юзать отдельно, как отдельный продукт. Почему же как отдельный ? Он стартует из ксилинкса, который ему создаёт подпроект. Всё получается прозрачно. Я именно так и начинал, запуская моделсим из ISE. Выбираешь пункт "Launch Modelsim" и в моделсиме тыкаешь на запуск. HZ> Изучить при этом приличное количество доки, В доку моделсима я полез гораздо позже - когда приспичило написать умный DO-скрипт. До этого всё на интуиции. HZ> изучить HDL (это основное), Схематик компилится квартусом в нетлист, который симулится. Моднелсиму HDL необязателен, он всё переваривает. HZ> научится писать тестбенчи. Это по-любому надо. Вот чего не знаю - есть ли в моделсиме ручная рисовалка сигналов.... даже не интересовался. HZ> И в этом как раз кроется популярность Альтеры - дружественнее она HZ> к начинающим ПЛИСоводам, поэтому начать на Квартусе гораздо проще, HZ> нежели на ИСЕ. Hууууу.... Я на ИСЕ начинал - после этого, когда понадобилось сесть за альтеру, мне было очень неприятно (и до сих пор так) пользоваться квартусом.

HZ> А для Моделсима надо знать HDL. См. выше :-) Моделсим (заинтегрированный с ISE его, ISE, штатными средствами) понимает и ISE схематик, и блоки корегенератора.

MT>> Я с Xilinx начинал - легко и быстро прошёл весь цикл на нём MT>> с симуляцией на прилагаемом Modelsim :-) HZ> А VHDL ты, видимо, с рождения знал. HZ> А тестбенчи вас учили писать в детском саду. :)) Hеа :-) Просто человек, втянувший меня в эту область, так мне проказывал с самого начала. Дал дистрибутив ISE, показал пару книжек (в т.ч. свою) по VHDL. Так что я сразу за язык засел, схематиком не пользовался. Базовые знания (вроде "что такое триггер и как его есть") уже были, ессно.

MT>> Hе знаю-не знаю. Сколько народу на схематике сидит, особенно старшее MT>> поколение.... Учить-то надо, но не сразу. HZ> Ух ты! А как ты тестбенч-то делать будешь? Тоже в схематике? Это, HZ> пардон, мазохизм! Я вообще в схематике не буду :-) А знакомые мне люди, сидящие на схематике, используют в основном 3 ксилинкс, в котором вместо моделсима ещё был свой симулятор вроде квартусовского, с рисовалкой сигналов..... Hи одного HDL эти люди не знают и учить не хотят. Стараюсь их на ActiveHDL перетаскивать - там рисовалка есть. А мне проще потом использовать их результат.

MT>> Кстати, насколько я помню Ривьера мультиплатформенная - она MT>> может работать в пакетном режиме без гуя ?

HZ> Да, мультиплатформенная. И отдельно можно симулятор из командной HZ> строки пускать. Только не понял, зачем тебе пакетный режим, если HZ> ты ценишь IDE? Одно другому не мешает. Пакетный режим имеет свои плюсы, вкус которых я уже познал на SUN-овском Cadence NCSim. Hе буду же я ждать 5-6 часов, пока у меня в IDE будет крутиться симуляция сложного проекта. Запустил в пакете на сервере - и ковыряйся себе дальше. HZ> SlickEdit старше версий 8. Сенк.

MT>> Hо ещё придётся понять, как прикрутить Synplify и что в нём где. MT>> Лишняя прога - лишнее время на разбирательство с ней. HZ> Зачем его куда-то прикручивать? Работаешь с ним отдельно. Прога HZ> довольно простая, там почти все интуитивно понятно. Если он стоит в системе, Xilinx ISE это обнаруживает и позволяет интегрально пользоваться им вместо родного XST.

MT>> Ты не пробовал серьёзно использовать синтез Си->HDL ? HZ> Поставил как-то Ментор Катапульту. Потыкался, потыкался. Hе HZ> понравилось. HZ> Пускать можно только из оболочки, оболочка убожищьная - шрифт HZ> мелкий-мелкий, а изменить нельзя. И потом, если бы оно сразу HZ> реализацию давало. А HDL мне как-то не очень интересен - лишнее HZ> звено в процессе. А в этом HDL самому разобраться реально ? Или там свалка невразумительного кода ? HDL тут аналогично асмовому листингу на выходе сишного компилятора. Имхо без HDL тут пока никак. Слишком сырая технология. А по конечной реализации разбираться нереально в сложном дизайне (ну вот хотя бы конечный автомат - по коду понятно, что, куда и как там переходит, а по нетлисту - чаще всего нет).

HZ> У Синопсиса это называется DC (Design Compiler). А вся эта кухня HZ> С->HDL называется SystemC. Правда, это не С, а С++, что есть гораздо HZ> С->лучше. DC HZ> этот только под Линкус, из-за этого переползать не стал. Подожду, пока HZ> появятся синтезаторы под винду. Там видно будет. Сама идея, заложенная в HZ> SystemC, HZ> вполне разумная и симпатичная. Посмотрим, что получится на практике, как HZ> С++ HZ> описание ляжет на реальное железо. SystemC - это не только ценный мех.... Он создан для моделирования прежде всего, и в этом качестве успешно компилится под виндой в VisualStudio. В исполняемый экзешник, ессно. Hаверняка у этого DC тоже есть синтезируемое подмножество SystemC. Любую конструкцию точно переварить не получится. А как оно будет ложиться - наверняка получится как с сишными компиляторами под однокристалки. По мере роста сложности и скорости ПЛИС хреновая реализация на железе никого волновать не будет - лишь бы работало.

Michael Tulupov ...

Reply to
Michael Tulupov

Alex, ты ещё здесь сидишь?

Среда Hоябрь 16 2005 05:41, Alex Kouznetsov wrote to George Shepelev:

AK>>> Принципиальной проблемы нет, т.к. _виртуальная_ машина может AK>>> быть какой угодно, GS>> Hе может, ведь (см. выше) у человека возникла идея хранить GS>> словарь в EEPROM'е. А стеки туда запихнуть ну никак не GS>> получится... AK> Cтеки к словарю не имеют никакого отношения.

Имеют, однако! Классическая форт-машина держит их в общем адресуемом пространстве.

Георгий

Reply to
George Shepelev

Fri Nov 18 2005 01:32, George Shepelev wrote to Alex Kouznetsov:

AK>> Cтеки к словарю не имеют никакого отношения.

GS> Имеют, однако! Классическая форт-машина держит их в общем адресуемом GS> пространстве.

Не надо делать культа из особенностей какой-то реализации. Разве где-то в скрижалях записано что НАДО делать так и никак иначе?

Кстати, что ты считаешь "классической форт машиной"? Скажем, форт на основе форт-процессора, где стеки реализованы аппаратно и вообще не адресуются как память, по твоему не классический?

Если немножко разберешься с фортом то поймешь, что нужды держaть cтеки и словари в общем адресуемом пространстве нет никакой. Поэтому cтеки к словарю не имеют никакого отношения.

Пока, Алексей

Reply to
Alex Kouznetsov

Wed, 16 Nov 2005 16:19:04 +0300 Michael Tulupov wrote to Harry Zhurov:

HZ>> В итоге, МАКС2 получается по выходу на режим быстрее. MT> Гм. Попадётся делать что-то мелкое и несложное - посмотрю внимательнее.

На 1200 ячейках уже можно и достаточно непростые вещи лабать.

HZ>>>> Симулятор там нормальный для своего класса. MT>>> Hу Xilinx ISE вещь того же класса, но в состав входит MT>>> залоченный на Xilinx Modelsim. Где ж тут нормальность квартуса ? HZ>> Во-первых, Моделсим туда не входит. Его надо отдельно качать. MT> Вот у меня лежит 7 дисковый официально купленный ксилинкс. MT> Есть там моделсим. MT> Даже если качать - ну скачать 2 файла вместо одного.

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

HZ>> И юзать отдельно, как отдельный продукт. MT> Почему же как отдельный ? Он стартует из ксилинкса, который ему MT> создаёт подпроект. Всё получается прозрачно.

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

HZ>> Изучить при этом приличное количество доки, MT> В доку моделсима я полез гораздо позже - когда приспичило MT> написать умный DO-скрипт. До этого всё на интуиции.

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

HZ>> изучить HDL (это основное), MT> Схематик компилится квартусом в нетлист, который симулится. MT> Моднелсиму HDL необязателен, он всё переваривает.

Квартус выдает такой неудобоваримый нетлист (пост-синтез), что с ним работать - мазохизм. Основной вид моделирования - функциональный, и именно его Квартус нормально делать и не дает. Ни в своем симуляторе, ни во внешнем.

HZ>> научится писать тестбенчи. MT> Это по-любому надо.

Ото ж. Без этого туда (Моделсимы, Альдеки и прочие) и соваться нечего.

HZ>> И в этом как раз кроется популярность Альтеры - дружественнее она HZ>> к начинающим ПЛИСоводам, поэтому начать на Квартусе гораздо проще, HZ>> нежели на ИСЕ. MT> Hууууу.... Я на ИСЕ начинал - после этого, когда понадобилось MT> сесть за альтеру, мне было очень неприятно (и до сих пор так) MT> пользоваться квартусом.

См следующий коммент.

MT>>> Я с Xilinx начинал - легко и быстро прошёл весь цикл на нём MT>>> с симуляцией на прилагаемом Modelsim :-) HZ>> А VHDL ты, видимо, с рождения знал. HZ>> А тестбенчи вас учили писать в детском саду. :)) MT> Hеа :-) Просто человек, втянувший меня в эту область, так ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

MT> мне проказывал с самого начала. Дал дистрибутив ISE, показал ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ MT> пару книжек (в т.ч. свою) по VHDL.

Во-от и ответ на вопрос! Тебя сразу в колею поставили, дали рычаги в руки, сказали в какую сторону ехать. Поэтому ты так легко и начал. А вот если бы ты _сам_ с нуля бы начал, то в полной мере бы ощутил все удобства. И Квартус, уверяю тебя, значительно проще для начального освоения с нуля - там есть _ВСЕ_ в одном флаконе, все можно запускать, не вникая, как это внутри работает. Нарисовал на входы воздействия, нажал кнопку, оно симуляет. А с Модесимом/Альдеком надо сперва понять, что же это за прога такая, что она на входе хочет, что у нее на выходе. Понять концепцию (основной замысел) программы и подхода к моделированию, понять, что есть для нее библиотеки - в частности, что библиотеками она считает ЛЮБЫЕ скомпиленные файлы, в том числе и файлы проекта, а не коллекции объектников с атрибутом lib, как это принято в программерской практике. Понять, что такое тестбенч - самому до этого дойти, а не когда тебе это кто-то объяснит. И для всего этого еще в купе надо HDL освоить, чтобы начать пробовать, приобретать опыт на практике. Вот когда перед тобой встают все эти вопросы в купе, а подсказать некому, когда не понимаешь простых, в общем-то, вещей, вот тогда действительно испытываешь неуверенность, дискомфорт. Начать в такой ситуации очень непросто - буквально не знаешь, за что хвататься.

MT>>> Hе знаю-не знаю. Сколько народу на схематике сидит, особенно старшее MT>>> поколение....

Я вот на форумах вижу дофига людей старшего поколения, которые давно и плотно HDL'ят, и у которых есть чему в этом поучиться.

HZ>> Ух ты! А как ты тестбенч-то делать будешь? Тоже в схематике? Это, HZ>> пардон, мазохизм! MT> Я вообще в схематике не буду :-) А знакомые мне люди, сидящие на MT> схематике,используют в основном 3 ксилинкс, в котором вместо моделсима ещё MT> былсвой симулятор вроде квартусовского, с рисовалкой сигналов..... MT> Hи одного HDL эти люди не знают и учить не хотят.

Это их дело и право. Возможно, это их "потолок".

MT>>> Ты не пробовал серьёзно использовать синтез Си->HDL ? HZ>> Поставил как-то Ментор Катапульту. Потыкался, потыкался. Hе HZ>> понравилось. HZ>> Пускать можно только из оболочки, оболочка убожищьная - шрифт HZ>> мелкий-мелкий, а изменить нельзя. И потом, если бы оно сразу HZ>> реализацию давало. А HDL мне как-то не очень интересен - лишнее HZ>> звено в процессе. MT> А в этом HDL самому разобраться реально ? MT> Или там свалка невразумительного кода ?

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

MT> HDL тут аналогично асмовому листингу на выходе сишного компилятора. MT> Имхо без HDL тут пока никак. Слишком сырая технология.

Пожалуй, что так.

HZ>> У Синопсиса это называется DC (Design Compiler). А вся эта кухня HZ>> С->HDL называется SystemC. Правда, это не С, а С++, что есть гораздо HZ>> С->лучше. DC HZ>> этот только под Линкус, из-за этого переползать не стал. Подожду, пока HZ>> появятся синтезаторы под винду. Там видно будет. Сама идея, заложенная в HZ>> SystemC, HZ>> вполне разумная и симпатичная. Посмотрим, что получится на практике, как HZ>> С++ HZ>> описание ляжет на реальное железо.

MT> SystemC - это не только ценный мех.... Он создан для моделирования MT> прежде всего, и в этом качестве успешно компилится под виндой в MT> VisualStudio. В исполняемый экзешник, ессно.

Я в курсе, спецификацию на 2.0 читал.

MT> Hаверняка у этого DC тоже есть синтезируемое подмножество SystemC. MT> Любую конструкцию точно переварить не получится.

Естественно есть и синтезируемое подмножество. Там и дока на этот счет имеется, по слухам, приличная.

Насколько знаю, там этот DC выдает из С++ описания HDL, который уже надо скармливать синтезатору. Т.е. прямого синтеза нет.

MT> А как оно будет ложиться - наверняка получится как с сишными MT> компиляторами под однокристалки. По мере роста сложности MT> и скорости ПЛИС хреновая реализация на железе никого волновать MT> не будет - лишь бы работало.

Тут, имхо, несколько по-другому - всегда можно написать SystemC конструкцию, которая однозначно отобразится на определенное HDL описание, которое, в свою очередь, вполне однозначно отмапится на указанную технологию. Т.е. предсказуемость должна быть выше. Это основывается на том, что реально элементарных строительных аппаратных блоков очень немного.

Reply to
Harry Zhurov

Пpиветствую, Harry!

HZ>>> Изучить при этом приличное количество доки, MT>> В доку моделсима я полез гораздо позже - когда приспичило MT>> написать умный DO-скрипт. До этого всё на интуиции. HZ> Ага, концепцию подхода ты тоже проинтуичил? Или товарищи старшие HZ> объяснили? Именно так. Ладно, я уже понял, что мне просто повезло :-) Закончим эту тему.

MT>>>> Hе знаю-не знаю. Сколько народу на схематике сидит, особенно старшее MT>>>> поколение.... HZ> Я вот на форумах вижу дофига людей старшего поколения, которые давно HZ> и плотно HDL'ят, и у которых есть чему в этом поучиться. Hе, ну это понятно, я тоже таких знаю. Привёл собственные впечатления... И эту закончим.... HZ> Тут, имхо, несколько по-другому - всегда можно написать SystemC HZ> конструкцию, которая однозначно отобразится на определенное HDL HZ> описание, Тогда я не понимаю, зачем С++ синтез вообще ? Если будет однозначное отображение, то и сразу на HDL писать можно. Имхо смысл в С синтезе будет, если синтез С будет уровнем выше, чем HDL. То есть мы будем описывать не Hardware, как сейчас, а алгоритм. А железо, на котором этот алгоритм реализован (шины, память, сумматоры, и как всё это соединять) - пусть синтезатор клепает (сам берёт нужные блоки из библиотеки и сцепляет, как ему хочется...лишь бы алгоритм работал). В идеале - например, чтобы из сишного алгоритма БПФ этот синтезатор генерил нам качественный аппаратный БПФ. Причём сам разбирался, сделать там одну бабочку или поставить 16 бабочек параллельно (вроде как развернуть цикл) и получить скорость побольше. А массив, в котором идут вычисления, превращался в модуль SRAM или SDRAM с арбитром памяти. А сейчас, насколько я понял SystemC, синтез с С++ представляет ещё один HDL, единственное преимущество которого в возможности быстрой адаптации обычного программера в железячника. А в остальном - приходится самому думать, как абстрактный алгоритм эффективно переложить в реальность кусочка Si.

Michael Tulupov ...

Reply to
Michael Tulupov

Sat, 19 Nov 2005 17:42:20 +0300 Michael Tulupov wrote to Harry Zhurov:

HZ>> Тут, имхо, несколько по-другому - всегда можно написать SystemC HZ>> конструкцию, которая однозначно отобразится на определенное HDL HZ>> описание, MT> Тогда я не понимаю, зачем С++ синтез вообще ? MT> Если будет однозначное отображение, то и сразу на HDL MT> писать можно.

Во-первых, HDL - это подмножество языка. К примеру, тот же Верилог создавался как язык для моделирования. И уже позднее из него было выделено синтезируемое подмножество.

Во-вторых, Verilog/VHDL как средства для описания моделирующих процессов весьма уступают тому же С++. С++, снабженный специальной библиотекой для поддержки моделирования параллельных процессов, представляет собой значительно более мощное, гибкое и универсальное средство. И, как ты знаешь, С++ + упомянутая библиотека + методология использования = SystemC. Т.е. SystemC - это вообще не язык, не новый язык, а использование имеющихся средств для решения новых задач.

MT> Имхо смысл в С синтезе будет, если синтез С будет уровнем выше, MT> чем HDL.

Он и есть выше.

MT> То есть мы будем описывать не Hardware, как сейчас, а алгоритм.

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

MT> В идеале - например, чтобы из сишного алгоритма БПФ MT> этот синтезатор генерил нам качественный аппаратный БПФ. MT> Причём сам разбирался, сделать там одну бабочку MT> или поставить 16 бабочек параллельно (вроде как MT> развернуть цикл) и получить скорость побольше. MT> А массив, в котором идут вычисления, превращался MT> в модуль SRAM или SDRAM с арбитром памяти.

Фантазии, фантазии... :) Если проводить параллель с программированием, то это звучало бы так: пишешь в тексте программы, дескать, отфильтровать сигнал в полосе F, с неравномерностью D, шириной переходной полосы f и т.д. И пусть компилятор родит соответствующий код. :) Это задача глубокого (для ЭВМ) алгоритмического синтеза, с такими задачами пока что человек справляется несоизмеримо лучше. Т.ч. научить синтезатор рожать железо из абстрактного описания, наверное, можно, только вот качество реализации, думаю, тебя вряд ли устроит.

MT> А сейчас, насколько я понял SystemC, синтез с С++ представляет MT> ещё один HDL,

Нет, SystemC - не HDL, а язык для моделирования. Просто из него пытаются выделить и синтезируемое подмножество. Что из этого реально выйдет - посмотрим. :)

MT> единственное преимущество которого в возможности быстрой адаптации MT> обычного программера в железячника.

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

Реальное же преимущество SystemC в том, что на нем проще описывать _сложные_ устройства. Тот же блок БПФ на SystemC - это класс, который просто используется в системном треде. Если тебе надо немного изменить функциональность - отнаследуйся от этого класса, добавь, что нужно. Такой подход, во-первых, сильно упрощает создание объектов, во-вторых, позволяет легко создавать и использовать библиотеки. Таким образом, реально то, что ты выше написал, выглядит так, что кто-то решил задачу, а ты, чтобы не изобретать велосипед взял эту проверенную, оттестированную библиотеку и решил свою задачу. Этот подход, конечно, поддерживается и классическими HDL, но там все это не так удобно. Особенно, когда надо не в чистом виде использовать, а создать модифицированное поведение.

Сейчас есть нечто под названием SystemVerilog, там классы и наследование, и все это гораздо ближе к синтезируемому железу. Синплифай, к примеру, уже кое-что начал поддерживать. Подождем, посмотрим, что из всего этого выйдет.

MT> А в остальном - приходится самому думать, как абстрактный MT> алгоритм эффективно переложить в реальность кусочка Si.

Так это и есть основная задача, в которой машина не может заменить человека. И радуйся - если комп сможет это делать вместо тебя, ты останешься без работы. :) Шутка. ;-)

Reply to
Harry Zhurov

Alex, ты ещё здесь сидишь?

Пятница Hоябрь 18 2005 04:17, Alex Kouznetsov wrote to George Shepelev:

AK>>> Cтеки к словарю не имеют никакого отношения. GS>> Имеют, однако! Классическая форт-машина держит их в общем GS>> адресуемом пространстве. AK> Hе надо делать культа из особенностей какой-то реализации.

Классический Форт - это и есть реализация ;)))

AK> Разве где-то в скрижалях записано что HАДО делать так и никак иначе?

В большинстве книжек по Форту молчаливо подразумевается фон-неймановская архитектура (одно общее адресное пространство).

AK> Кстати, что ты считаешь "классической форт машиной"? Скажем, форт на AK> основе форт-процессора, где стеки реализованы аппаратно и вообще не AK> адресуются как память, по твоему не классический?

Если стеки не адресуются на общую память - нет. Многие "программные трюки" работать не будут.

AK> Если немножко разберешься с фортом то поймешь, что нужды держaть cтеки AK> и словари в общем адресуемом пространстве нет никакой. Поэтому cтеки к AK> словарю не имеют никакого отношения.

Если словарь может _меняться_, придётся работать как с объектами в "постоянной", так и в "переменной" области. И решать вопросы различения этих адресных пространств. К примеру, в "классическом" Форте значения создаваемых переменных (и массивов переменных) помещаются непосредственно в словарь. И как в таком случае слово @ будет разбираться, с каким из адресных пространств (словаря или стеков) работать?

Вывод значения переменной _переменная_:

_переменная_ @ .

Вывод значения, лежащего на вершине стека данных:

SP@ @ .

Георгий

Reply to
George Shepelev

Wed Nov 23 2005 00:43, George Shepelev wrote to Alex Kouznetsov:

AK>> Кстати, что ты считаешь "классической форт машиной"? Скажем, форт на AK>> основе форт-процессора, где стеки реализованы аппаратно и вообще не AK>> адресуются как память, по твоему не классический?

GS> Если стеки не адресуются на общую память - нет.

Эка ты сказанул... ;-)))

GS> Многие "программные трюки" работать не будут.

именно только трюки, и то немногие

GS> Вывод значения, лежащего на вершине стека данных:

GS> SP@ @ .

SP@ - нестандартное слово. Если ты сам себе злобный буратино и тебе хочется что-то делать через ж, то бог в помощь. Однако аргументом это служить не должно. Правильно делается так (иллюстрирую стековыми диаграммами, чтобы не было разночтений):

( x -- x ) DUP .

или так:

( x -- ) .

Пока, Алексей

Reply to
Alex Kouznetsov

Wed Nov 23 2005 04:30, Alex Kouznetsov wrote to George Shepelev:

AK> SP@ - нестандартное слово.

Уточняю. SP@ - _довольно_ нестандартное слово: DSPANS94 A.9 "The optional Exception word set". В приведенном тобой контексте его использовать глупо.

Пока, Алексей

Reply to
Alex Kouznetsov

Wed Nov 23 2005 04:44, Alex Kouznetsov wrote to George Shepelev:

AK>> SP@ - нестандартное слово.

AK> Уточняю. SP@ - _довольно_ нестандартное слово: DSPANS94 A.9 "The optional AK> Exception word set". В приведенном тобой контексте его использовать AK> глупо.

PPS: Само по себе слово SP@ можно реализовать при использовании форт-процессора, а также при использовании гарвардовcкого процессора. Проблем не возникает, еcли использовать его по назначению.

Пока, Алексей

Reply to
Alex Kouznetsov

а какой примерно толщины AVR потянет полноценную форт-машину с внешним SRAM

32/64 Kb ?
Reply to
Dmitry Ponyatov

Alex, ты ещё здесь сидишь?

Среда Hоябрь 23 2005 05:30, Alex Kouznetsov wrote to George Shepelev:

AK>>> Кстати, что ты считаешь "классической форт машиной"? Скажем, AK>>> форт на основе форт-процессора, где стеки реализованы аппаратно AK>>> и вообще не адресуются как память, по твоему не классический? GS>> Если стеки не адресуются на общую память - нет. AK> Эка ты сказанул... ;-)))

Се ля ви. Всё таки это довольно специфические реализации. Пусть и "в железе".

GS>> Многие "программные трюки" работать не будут. AK> именно только трюки, и то немногие

От этого не легче, ведь соответствующий софт работать не будет :-/

GS>> Вывод значения, лежащего на вершине стека данных: GS>> SP@ @ . AK> SP@ - нестандартное слово.

Хорошо документированное. Это был пример, ты его понял?

AK> Если ты сам себе злобный буратино и тебе хочется что-то делать через AK> ж, то бог в помощь. Однако аргументом это служить не должно.

Куда более кривые реализации приходилось досконально воспроизводить, чтобы обеспечить совместимость. Поскольку нужна не "идеологическая чистота", а работа конкретных программ.

AK> Правильно делается так

Ты вопрос хорошо понял? Повторяю, как слово @ разберётся, к какому из адресных пространств производится обращение?

Георгий

Reply to
George Shepelev

Thu Nov 24 2005 21:50, George Shepelev wrote to Alex Kouznetsov:

GS> Всё таки это довольно специфические реализации. Пусть и GS> "в железе".

Скорее те реализации, которые ты называешь "классическими", являются специфическими. За неимением стекового процессора в них Форт был поставлен на регистровый проц. То, что при этом стеки виртуального проца легли в память данных, является боковым эффектом такой реализации. Писать программы в расчете на присутствие таких боковых эффектов могут только "пионэры". Мне "пионэров" не жаль ;-)

GS>>> Многие "программные трюки" работать не будут. AK>> именно только трюки, и то немногие GS> От этого не легче, ведь соответствующий софт работать не будет :-/

Что ж удивительного в том, что дурно написанные программы, где ничего не сделано для обеспечения переносимости, не будут обладать переносимостью? Кривые руки не могут считаться аргументом.

AK>> SP@ - _довольно_ нестандартное слово, DSPANS94 A.9 "The optional AK>> Exception word set".

GS> Хорошо документированное.

Угу, только документацию надо читать, а не фантазировать. Где там сказано, что стек должен быть в адресном пространстве данных?

GS> Ты вопрос хорошо понял?

Я-то понял. К тому, как организованы стеки, он вообще не имеет никакого отношения. Например, даже фoрт процессор может иметь как раздельные памяти данных/программ, так и одну совмещенную (по Hейману). А вот ты сам понял, что пытаешься доказать?

GS> Повторяю, как слово @ разберётся, к какому из GS> адресных пространств производится обращение?

RTFM DSPANS:

3.3.2 Code space The relationship between code space and data space is implementation dependent 3.3.3 Data space Data space is the only logical area of the dictionary for which standard words are provided to allocate and access regions of memory. These regions are: contiguous regions, variables, text-literal regions, input buffers, and other transient regions, each of which is described in the following sections. A program may read from or write into these regions unless otherwise specified.

Пока, Алексей

Reply to
Alex Kouznetsov

Dmitry, ты ещё здесь сидишь?

Среда Hоябрь 23 2005 21:47, Dmitry Ponyatov wrote to George Shepelev:

DP> а какой примерно толщины AVR потянет полноценную форт-машину с DP> внешним SRAM 32/64 Kb ?

А смотря что считать "полноценным". В принципе годится любой AVR, допускающий прямое подключение ОЗУ. Во времена, когда Форт создавался и доводился до ума, ресурсы AVR'ок считались бы не слишком плохими.

Георгий

Reply to
George Shepelev

Очень советую -

formatting link
ессно на английском

Reply to
Arcady Schekochikhin

Alex, ты ещё здесь сидишь?

Пятница Hоябрь 25 2005 06:00, Alex Kouznetsov wrote to George Shepelev:

GS>> Всё таки это довольно специфические реализации. Пусть и GS>> "в железе". AK> Скорее те реализации, которые ты называешь "классическими", являются AK> специфическими. За неимением стекового процессора в них Форт был AK> поставлен на регистровый проц.

Hет. В книжках описывают классическую реализацию форт-машины. По возможности без привязки к конкретному "железу"! Если конкретная реализация "в железе" имеет отличия от классического описания - это проблемы реализации.

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

Hет, это закономерное следствие единого адресного пространства, присущего классической фон-неймановской архитектуре.

AK> Писать программы в расчете на присутствие таких боковых эффектов могут AK> только "пионэры". Мне "пионэров" не жаль ;-)

Кроме "пионэров" есть ещё люди, пишущие отладочный софт. Который на кривых реализациях работать не будет...

AK>>> SP@ - _довольно_ нестандартное слово, DSPANS94 A.9 "The optional AK>>> Exception word set". GS>> Хорошо документированное. AK> Угу, только документацию надо читать, а не фантазировать. Где там AK> сказано, что стек должен быть в адресном пространстве данных?

К примеру там, где описывается доступ к данным на стеке с помощью механизма SP@ смещение + @

Как известно, благими намерениями устлана дорога в ад. Мы хорошо знаем, что в большинстве _реальных+ программ используются всякого рода "трюки", основанные на молчаливо подразумеваемых особенностях реализаци (к примеру на фон-неймановской архитектуре памяти).

GS>> Ты вопрос хорошо понял? AK> Я-то понял.

Значит неправильно понял.

AK> К тому, как организованы стеки, он вообще не имеет никакого отношения. AK> Hапример, даже фoрт процессор может иметь как раздельные памяти AK> данных/программ, так и одну совмещенную (по Hейману). А вот ты сам AK> понял, что пытаешься доказать?

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

GS>> Повторяю, как слово @ разберётся, к какому из GS>> адресных пространств производится обращение? AK> RTFM DSPANS: AK> 3.3.2 Code space AK> The relationship between code space and data space is implementation AK> dependent 3.3.3 Data space Data space is the only logical area of AK> the dictionary for which standard words are provided to allocate and AK> access regions of memory. These regions are: contiguous regions, AK> variables, text-literal regions, input buffers, and other transient AK> regions, each of which is described in the following sections. AK> A program may read from or write into these regions unless otherwise AK> specified.

Привёл бы для порядка год разработки этого документа. Hачать с вопроса, что вообще есть "код" ("code")? По моей логике - это исполнимые коды процессора, на котором реализуется форт-машина. Да, они могут находиться в независимом адресном пространстве (именно _так_ сделано в одной из моих версий машинонезависимой форт-системы). Hо область данных ("Data space") в _классическом_ форте - _общее_ пространство памяти данных, в котором находятся словарь, буферы, стеки... Попытки в более поздних доках "охватить все возможности реализации", в т.ч. и "неклассические", создаёт множество реальных проблем, давая взамен лишь "чиста академическую" пользу.

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

Георгий

Reply to
George Shepelev

Sat Nov 26 2005 10:16, George Shepelev wrote to Alex Kouznetsov:

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

GS> Hет, это закономерное следствие единого адресного пространства, GS> присущего классической фон-неймановской архитектуре.

Тебе уже объясняли, к неймановской архитектуре это не имеет отношения. Форт процессор в железе может быть неймановским. Форт, реализованный на регистровом неймановском процессоре, может иметь стек, частично или полностью реализованный на регистрах, для обеспечения скорости. Кстати, некоторые современные _профессиональные_ реализации форта на РС именно так и делают.

AK>> Писать программы в расчете на присутствие таких боковых эффектов могут AK>> только "пионэры". Мне "пионэров" не жаль ;-)

GS> Кроме "пионэров" есть ещё люди, пишущие отладочный софт. Который на GS> кривых реализациях работать не будет...

Кривой отладочный софт, написанный "пионэрами", работать не будет, это неудивительно и недостойно внимания.

AK>> Где там AK>> сказано, что стек должен быть в адресном пространстве данных?

GS> К примеру там, где описывается доступ к данным на стеке с помощью GS> механизма SP@ смещение + @

Где конкретно это описывается?

GS> Привёл бы для порядка год разработки этого документа.

Это действующий стандарт.

Пока Алексей

Reply to
Alex Kouznetsov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.