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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: идеальный язык программирования ?
П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
...

идеальный язык программирования ?
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 описание,
которое, в свою очередь, вполне однозначно отмапится на указанную технологию.
Т.е. предсказуемость должна быть выше. Это основывается на том, что реально
элементарных строительных аппаратных блоков очень немного.

--
H.Z.

h.z<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: идеальный язык программирования ?

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


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

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

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


                                                   Георгий


идеальный язык программирования ?
Fri Nov 18 2005 01:32, George Shepelev wrote to Alex Kouznetsov:

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

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

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

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

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

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


Re: идеальный язык программирования ?
П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
...

идеальный язык программирования ?
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.

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

--
H.Z.

h.z<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: идеальный язык программирования ?

   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@ @ .





                                                   Георгий


идеальный язык программирования ?
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 -- )
.

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


идеальный язык программирования ?
Wed Nov 23 2005 04:30, Alex Kouznetsov wrote to George Shepelev:

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

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

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


идеальный язык программирования ?
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ли
использовать его по назначению.

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


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

   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> Правильно делается так

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


                                                   Георгий


идеальный язык программирования ?
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.

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


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

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


Воскресенье Hоябрь 27 2005 02:53, Alex Kouznetsov wrote to George Shepelev:

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

 Если судить по обычно используемой при изучении Форта литературе - имеет.
Погляди, к примеру, классическую книжку Баранова и Hоздрунова "Язык Форт
и его реализации". Значительно проще и нагляднее описывается реализация
с общим адресным пространством.

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

 Может, но это отступление от типичных реализаций, что приводит
к специфическим нюансам в работе. И эти нюансы нужно _очень_ хорошо
представлять. Именно об этом, а не о "невозможности" модификаций,
шла речь!..


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

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


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

 Так я и думал. В своё время стандарт Форта был изуродован "сишниками",
введшими свои любимые "неопределённости, зависящиее от реализации", так что
я предпочитаю пользоваться более старой и более _вменяемой_ документацией,
от Мура (автора языка Forth) и Броуди (признанного популяризатора Форта).


                                                   Георгий


идеальный язык программирования ?
Sun Nov 27 2005 10:24, George Shepelev wrote to Alex Kouznetsov:

 GS> Погляди, к примеру, классическую книжку Баранова и Hоздрунова "Язык Форт
 GS> и его реализации".

 GS> я предпочитаю пользоваться более старой и более _вменяемой_
 GS> документацией, от Мура (автора языка Forth) и Броуди (признанного
 GS> популяризатора Форта).

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

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


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

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


Вторник Hоябрь 29 2005 04:59, Alex Kouznetsov wrote to George Shepelev:

 AK>>> Цитату или точную ссылку, плз...
 GS>>  Баранова с Hоздруновым не читали-с? А Броуди? Книжки с
 GS>> картинками, в т.ч. есть и картинки распределения областей памяти
 GS>> форт-системы...
 AK> Очевидно, это надо понимать так, что цитату или точную ссылку ты
 AK> привести не можешь.

 Очевидно это следует понимать так, что книжки ты не видел и глядеть не хочешь.
Жаль.

 AK> Т.е. увиливаешь.

 Какой бред... Просто сейчас у меня слишком мало времени, чтобы картинки
перерисовывать. Гляди к примеру Л.Броуди, "Hачальный курс программирования
на языке Форт". Глава "Пользовательские переменные" - картинка с распределением
памяти форт-системы.

 AK> Примеры с картинками в тех или иных литературных источниках являются
 AK> именно и только примерами.

 Повторяю, специфика языка Форт - его описание и есть пример _реализации_
форт-системы.

 AK> При этом возможные ошибки и неточности лежат на совести авторов.

 Да, да, конечно, авторы ошибаются, а тебе известна сакральная истина ;)))

 AK> Смехотворно требовать, чтобы все форты точно соответствовали этим
 AK> примерам.

 Об _этом_ и речи не было. Просто есть классические реализации, а есть
специфические. И любая специфика накладывает свои нюансы, которые _следует_
учитывать.

 AK> Для этого есть стандарт.

 Радуйся. Я предпочитаю внятные стандарты, а не кашу из "всё возможно,
сами разбирайтесь..."


                                                   Георгий


идеальный язык программирования ?
Thu Dec 01 2005 00:44, George Shepelev wrote to Alex Kouznetsov:

 GS> Гляди к примеру Л.Броуди, "Hачальный курс программирования
 GS> на языке Форт". Глава "Пользовательские переменные" - картинка с
 GS> распределением памяти форт-системы.

Угу. Значит, по-твоему, если память распределена не как на этой картинке - это
уже и не форт? Какой бред...

Сам Броуди пишет так: "Вы видите на рисунке карту памяти типичной
Форт-системы" - добавлю, довольно типичной во времена написания книги. Но даже
тогда не единственно возможной!
По поводу использования SP@ - "но в большинстве случаев это не может считаться
хорошим стилем программирования"

Кстати, у него там стеки растут в одном направлении, и заведены в по
отдельности для каждой задачи. Tо есть, реализация _очень_ плохая,
"пионэрская". А ты на нее молишься :(

 AK>> Для этого есть стандарт.

 GS>  Радуйся. Я предпочитаю внятные стандарты

Да, к сожалению, картинок в ANS94 нет, и изложено сухо, для специалистов.
Сочувствую.

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


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

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


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

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


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

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

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


                                                   Георгий


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

Quoted text here. Click to load it
Очень советую - http://www.colorforth.com/HOPL.html
ессно на английском

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

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


Понедельник Hоябрь 28 2005 03:56, Alex Kouznetsov wrote to George Shepelev:

 GS>> Погляди, к примеру, классическую книжку Баранова и Hоздрунова
 GS>> "Язык Форт и его реализации".
 GS>> я предпочитаю пользоваться более старой и более _вменяемой_
 GS>> документацией, от Мура (автора языка Forth) и Броуди (признанного
 GS>> популяризатора Форта).
 AK> Где конкретно сказано, что стек должен быть в памяти данных?

 В многочисленных примерах реализации. Форт - это по сути подробно
документированное описание реализации Форт-машины.

 AK> Цитату или точную ссылку, плз...

 Баранова с Hоздруновым не читали-с? А Броуди? Книжки с картинками,
в т.ч. есть и картинки распределения областей памяти форт-системы...


                                                   Георгий


Site Timeline