_Loader_ - Page 2

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

Threaded View
_Loader_
Sat Oct 04 2003 18:55, Yuriy K wrote to Alex Kouznetsov:

 YK>>> Программист будет писать непосредственно шитым кодом?
 YK>>> Передавай ему мои соболезнования.

 AK>> С чего это ты взял? Hикто такого не говорил.

 YK> Уже лучше. То есть компилятор все-таки есть и мы сравниваем не подходы
 YK> к программированию, а качество конкретных компиляторов на условных
 YK> примерах.
 YK> Так бы сразу и говорил.

А я именно так сразу и говорил, следить надо за тредом, и переспрашивать, если
непонятно:

--- start quote ---
Thu Oct 02 2003 13:48, Alex Kouznetsov wrote to Eugene Romanov:
 AK> Для информациии: в состав Форта обычно входят два интерпретатора
 AK> ("наружный" и "внутренний") и компилятор.
--- end quote ---

Это пояснение было дано специально, на тот случай, если кто-то не знаком с
Фортом, и не знает что находится "внутри" SPF.

 AK>> Только зачем ты в одну кучу мешаешь компилятор и интерпретатор? Если
 AK>> таким образом ("все в одном флаконе") устроен классический Форт, это еще
 AK>> не повод все и каждую систему делать именно таким образом.

 YK> Какой еще язык генерит шитый код, кроме Бейсика?

Вынужден повторить, к языку это не имеет никакого отношения. Шитый код может
генерироваться компилятором любого языка.

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

 YK> Зато его придется загружать в столь подробно обсуждаемый здесь кэш.

В честь чего? Откуда это у тебя такая идея взялась? Если в моем проце вообще
нет кэша, куда мне его _придется_ загружать?

 YK>>> Так все-же на каком языке будет писать программист?

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

 YK> Да уж... Каким образом написанные тобой программы будут поддерживаться
 YK> после твоего ухода с работы (по любой причине)?

Точно таким же образом, как и любые другие.

 AK>> Другие пусть пишут на чем хотят, на том, что смогут найти, или создать
 AK>> сами.

 YK> "Опора только на собственные силы". Это подходит только для небольших
 YK> задач, где не более одного человека на проект.

Большие проекты, например, можешь писать на Форте. Или на Java. Или на С#,
если сможешь сделать транслятор из MSIL (или как его там?) в свой байт-код.

 YK>>>>> теряется та  самая возможность запретить написание завешиваемых
 YK>>>>> программ,  с которой все и началось.

 AK>>>> Если в интерпретаторе нет операторов, которые позволят "завесить"
 AK>>>> программу, то завесить ее нельзя.

 YK> Правда такой интерпретатор будет _очень_ медленным...

Представь, перед тобой два почти идентичных интерпретатора. Но в первом есть
операторы обслуживания WDT и запрещения прерываний, а во втором - нету. Ты
будешь продолжать утверждать, что второй "будет _очень_ медленным"? Тогда
обоснуй - почему, в честь чего отсутствие этих операторов замедлит второй
интерпретатор?

 AK>> Hа любом языке. Я лично пишу на С или на ассемблере.

 AK>> А это от тебя зависит. Hадо больше скорости - поступайся надежностью, и
 AK>> наоборот.

 YK> Вот-вот, начинаем находить общую точку зрения.
 YK> Эффективный "форт" - не более защищен, чем тот же С/С++/whatever.
 YK> Защищенный "форт" - страшно медленный и неэффективный, так же как и все
 YK> остальные способы защиты программ от ошибок.
 YK> Где преимущества?

 AK>>>> Для начала, нет операторов, которые запрещают прерывание.
 AK>> Добавлю - также нет операторов, обслуживающих WDT

 YK> Соболезную. В embedded системах чаще всего должны быть.

 YK>>> Прекрасно. Работу с железом как писать будешь (см. название эхи)?

 AK>> Тебе лень подумать, или ты правда не понимаешь?

 YK> Мне интересно, что _ты_ можешь сказать.

 AK>> Для работы с железом
 AK>> исползуются низкоуровневые слова=операторы=подпрограммы=функции.

 YK> Кто их пишет и на каком языке?

 AK>> Hо,
 AK>> скажем, нет таких слов, которые могли бы запретить прерывания или
 AK>> обслужить WDT.

 YK> Соболезную. Как будем работать с железом без запрета прерываний?
 YK> Как пишутся обработчики прерываний?

 AK>>>> В том самом подпрограммном шитом коде (иными
 AK>>>> словами - в библиотеке, которая _уже_ находится в памяти, так что ее
 AK>>>> ее  ни компилировать, ни грузить больше не надо).

 YK>>> ?? Память она все равно занимает, времени на выполнение требует.
 YK>>> Те самые подпрограммы откуда берутся?
 YK>>> Кто и на каком языке пишет расширения библиотек?
 YK> Прощай защищенность. Кстати это противоречит твоим же словам о
 YK> замечательном  быстродействии "форта"...

 YK>>> Если только с использованием имеющихся слов, то исходные слова должны
 YK>>> позволять низкоуровневый доступ к ресурсам - прощай защищенность.
 YK>>> Если можно писать новые слова в машинном коде, то как?

 AK>> "Hовые слова" - это последовательности вызовов "старых слов".

 YK> Если старые слова не обеспечивают доступ к железу? См. выше.

Нет, ты явно "не въезжаешь". Похоже, у тебя в голове представление о том, что
все приложение, с начала до конца, обязательно должно интерпретироваться? Я
уже писал, воспринимай (удаленно) загружаемый байт-код как "Java апплет". Это
лишь часть общей системы, и на нее накладываются серьезные ограничения, в том
числе в целях обеспечения безопасности, чтобы проц не завесить.
Сама Java в чистом виде меня не устраивает по следующим причинам:
-- громоздкость (даже для Embedded Java)
-- скорость (мои интерпретаторы работают быстрее)

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


_Loader_
Sun Oct 05 2003 04:26, Alex Kouznetsov wrote to Yuriy K:

 YK>>>> Так все-же на каком языке будет писать программист?

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

 YK>> Да уж... Каким образом написанные тобой программы будут поддерживаться
 YK>> после твоего ухода с работы (по любой причине)?

 AK> Точно таким же образом, как и любые другие.

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

 AK>>> Другие пусть пишут на чем хотят, на том, что смогут найти, или создать
 AK>>> сами.

 YK>> "Опора только на собственные силы". Это подходит только для небольших
 YK>> задач, где не более одного человека на проект.

 AK> Большие проекты, например, можешь писать на Форте. Или на Java. Или на
 AK> С#, если сможешь сделать транслятор из MSIL (или как его там?) в свой
 AK> байт-код.

Я _компиляторы_ не писал, не пишу и не собираюсь писать. Для этого есть
другие люди в других конторах.


 YK>>>>>> теряется та  самая возможность запретить написание завешиваемых
 YK>>>>>> программ,  с которой все и началось.

 AK>>>>> Если в интерпретаторе нет операторов, которые позволят "завесить"
 AK>>>>> программу, то завесить ее нельзя.

 YK>> Правда такой интерпретатор будет _очень_ медленным...

 AK> Представь, перед тобой два почти идентичных интерпретатора. Hо в первом
 AK> есть операторы обслуживания WDT и запрещения прерываний, а во втором -
 AK> нету. Ты будешь продолжать утверждать, что второй "будет _очень_
 AK> медленным"?

Ты считаешь, что отсутсвие запрешения прерываний и работы с WDT достаточно
для написания незавешиваемых программ?
Ты крупно ошибаешься.

 YK>> Вот-вот, начинаем находить общую точку зрения.
 YK>> Эффективный "форт" - не более защищен, чем тот же С/С++/whatever.
 YK>> Защищенный "форт" - страшно медленный и неэффективный, так же как и все
 YK>> остальные способы защиты программ от ошибок.

Где преимущества?

 AK>>> Для работы с железом
 AK>>> исползуются низкоуровневые слова=операторы=подпрограммы=функции.

Кто их пишет и на каком языке?

 AK>>> Hо,
 AK>>> скажем, нет таких слов, которые могли бы запретить прерывания или
 AK>>> обслужить WDT.

 YK>> Соболезную. Как будем работать с железом без запрета прерываний?
 YK>> Как пишутся обработчики прерываний?

 YK>>>> Если только с использованием имеющихся слов, то исходные слова должны
 YK>>>> позволять низкоуровневый доступ к ресурсам - прощай защищенность.
 YK>>>> Если можно писать новые слова в машинном коде, то как?

 AK>>> "Hовые слова" - это последовательности вызовов "старых слов".

Если старые слова не обеспечивают доступ к железу? См. выше.

WBR, Юрий.


_Loader_
Sun Oct 05 2003 14:56, Yuriy K wrote to Alex Kouznetsov:

 YK>>> Да уж... Каким образом написанные тобой программы будут поддерживаться
 YK>>> после твоего ухода с работы (по любой причине)?

 AK>> Точно таким же образом, как и любые другие.

 YK> И будут продолжать писать трансляторы.
 YK> Мои соболезнования твоим работодателям, когда они это поймут на
 YK> собственной шкуре.
...
 YK> Я _компиляторы_ не писал, не пишу и не собираюсь писать. Для этого есть
 YK> другие люди в других конторах.

Ты трансляторов боишься потому, что не пока умеешь из писать? Не робей,
почитай книжки, и ты поймешь, что транслятор, в сущности, ничем не отличается
от любой другой программы ;-)

Любой грамотный программист может сопровождать ранее написанную программу,
если она написана достаточно грамотно и прилично документирована. Будь то
компилятор, либо что-либо еще. Поэтому аргумент не принимается.

 YK>>>>>>> теряется та  самая возможность запретить написание завешиваемых
 YK>>>>>>> программ,  с которой все и началось.

 AK>>>>>> Если в интерпретаторе нет операторов, которые позволят "завесить"
 AK>>>>>> программу, то завесить ее нельзя.

 YK>>> Правда такой интерпретатор будет _очень_ медленным...

 AK>> Представь, перед тобой два почти идентичных интерпретатора. Hо в первом
 AK>> есть операторы обслуживания WDT и запрещения прерываний, а во втором -
 AK>> нету. Ты будешь продолжать утверждать, что второй "будет _очень_
 AK>> медленным"?

 YK> Ты считаешь, что отсутсвие запрешения прерываний и работы с WDT
 YK> достаточно для написания незавешиваемых программ?
 YK> Ты крупно ошибаешься.

Ты не ответил на вопрос, почему второй интерпретатор будет медленным. Или ты
признаешь, что ляпнул глупость не подумав?

Тогда второй вопрос, раз ты считаешь что я ошибаюсь: как ты сможешь "завесить"
своим загруженным скриптом мою систему, где в интерпретаторе нет операторов
обслуживания WDT? "Завешиванием" будет считаться заклинивание системы в таком
состоянии, когда я не смогу "вычистить" твой "плохой" скрипт и загрузить свой
"хороший" без передергивания питания или нажимания на ресет.

 YK> Если старые слова не обеспечивают доступ к железу? См. выше.

Старые обеспечивают. Внутри слова (функции) я, например, могу временно
запретить прерывание, но я обязан снять этот запрет при выходе из слова.

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


_Loader_
Sun Oct 05 2003 15:43, Alex Kouznetsov wrote to Yuriy K:

 YK>>>> Да уж... Каким образом написанные тобой программы будут поддерживаться
 YK>>>>  после твоего ухода с работы (по любой причине)?

 AK>>> Точно таким же образом, как и любые другие.

 YK>> И будут продолжать писать трансляторы.
 YK>> Мои соболезнования твоим работодателям, когда они это поймут на
 YK>> собственной шкуре.

 AK> ...

Да, они еще этого не знают. Узнают...
Сколько человек работает над проектом?
Есть ли проекты, надо которыми работают одновременно несколько программистов?

 YK>> Я _компиляторы_ не писал, не пишу и не собираюсь писать. Для этого есть
 YK>> другие люди в других конторах.

 AK> Ты трансляторов боишься потому, что не пока умеешь из писать? Hе робей,
 AK> почитай книжки, и ты поймешь, что транслятор, в сущности, ничем не
 AK> отличается от любой другой программы ;-)

Видишь ли, Пух, компиляторы я не пишу просто потому что мне за это денег
не платят, а платят мне деньги за решение намного более других задач,
чем удовлетворение собственного неуемного любопытсва по исследованию
структуры компиляторов.

Программы же я стараюсь писать не _оптимизированные_, а _сопровождаемые_,
потому что это намного более важный показатель.
Собственно умение писать сопровождаемые программы обычно включает
в себя большинство остальных умений (по написанию программ) для
прикладного программиста.

 AK> Любой грамотный программист может сопровождать ранее написанную
 AK> программу, если она написана достаточно грамотно и прилично
 AK> документирована. Будь то компилятор, либо что-либо еще. Поэтому аргумент
 AK> не принимается.

Любой грамотный сферический программист может сферически сопровождать
любую программу, как бы она ни была написана.

Вопрос в стоимости сопровождения реальных программ реальными программистами.

 AK>>>>>>> Если в интерпретаторе нет операторов, которые позволят "завесить"
 AK>>>>>>> программу, то завесить ее нельзя.

 YK>>>> Правда такой интерпретатор будет _очень_ медленным...

 AK>>> Представь, перед тобой два почти идентичных интерпретатора. Hо в первом
 AK>>> есть операторы обслуживания WDT и запрещения прерываний, а во втором -
 AK>>> нету. Ты будешь продолжать утверждать, что второй "будет _очень_
 AK>>> медленным"?

 YK>> Ты считаешь, что отсутсвие запрешения прерываний и работы с WDT
 YK>> достаточно для написания незавешиваемых программ?
 YK>> Ты крупно ошибаешься.

 AK> Ты не ответил на вопрос, почему второй интерпретатор будет медленным. Или
 AK> ты признаешь, что ляпнул глупость не подумав?

(AK mode on)
Видишь ли, читать надо то, что написано, а не то, что тебе захотелось
прочитать.
(AK mode off)

 AK> Тогда второй вопрос, раз ты считаешь что я ошибаюсь: как ты сможешь
 AK> "завесить" своим загруженным скриптом мою систему, где в интерпретаторе
 AK> нет операторов обслуживания WDT? "Завешиванием" будет считатьс
 AK> заклинивание системы в таком состоянии, когда я не смогу "вычистить" твой
 AK> "плохой" скрипт и загрузить свой "хороший" без передергивания питания или
 AK> нажимания на ресет.

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

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

 YK>> Если старые слова не обеспечивают доступ к железу? См. выше.

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

Железо меняется со временем. Откуда берутся новые слова?

WBR, Юрий.


_Loader_
Mon Oct 06 2003 22:29, Yuriy K wrote to Alex Kouznetsov:

 YK> Видишь ли, Пух,
...
 AK>> Ты не ответил на вопрос, почему второй интерпретатор будет медленным.
 AK>> Или  ты признаешь, что ляпнул глупость не подумав?

 YK> (AK mode on)
 YK> Видишь ли, читать надо то, что написано, а не то, что тебе захотелось
 YK> прочитать.
 YK> (AK mode off)

Пятачок, ты, наверное, не понял что такое AK mode. Обрати внимание, АК в этом
режиме дал цитату, чтобы ясно было видно, что ты не прочитал или, если и
прочитал, - не обратил внимания. Гуманный он, понимаешь, ;-) не тычет "пальцем
в небо", типа, "иди, мол, ищи сам если что-то не заметил" :-)
...

 YK> Под завешиванием системы обычно подразумевается непреднамеренное
 YK> нарушение нормальной работы системы, достаточное для причинения заметного
 YK> материального ущерба. И возможность перешить программу без нажатия на
 YK> ресет в этом случае мало помогает. Впрочем может у тебя специфика такая.
 YK> что контроллер может висеть в свое удовольствие, пока не почешутся и софт
 YK> заново не запрограммируют? У меня такой роскоши нет.

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

 YK>>> Если старые слова не обеспечивают доступ к железу? См. выше.

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

 YK> Железо меняется со временем. Откуда берутся новые слова?

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

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


Re: _Loader_
Hello, Ilia Tarasov !

 >  DO>>> Могу себе представить этия ядра...

 >  IT>> Hаезд? Или хамство?

 >  YK> Констатация факта.

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

Я очень хорошо себе представляю что можно разработать за полчаса.

 > Тебе хорошо, а мне - нет...

 >  DO>>> А если embedded инженер пишет компиляторы, то 99% что он и
 >  DO>>> инженер плохой и компиляторы у него ни к черту

 >  IT>> Видишь ли, я не embedded инженер... я главный инженер ;)

 >  YK> Это достоинство или недостаток? :)

 > Правильный ответ :) А Орлов с Торресом дали неправильные - полезли

Бред.


 > Из той же области. Я таки добился той реакции, которую хотел - дискуссия
 > очевидно переходит на личности и "профессиональные касты". Ты

Естественно, ты ее и перевел, своими ненаписанными докторскими и переговорами с
целым Интелом.

 >  IT>> Hет, ты неправильно понял. У нас обычно до десятка проектов с разными
 >  IT>> процессорами и для разных задач.

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

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

Видимо ни одного сделанного. Впрочем что такое проекты, которые ведут ВУЗовские
кафедры я знаю очень хорошо.

 >  IT>> Я если что и программирую, то новые
 >  IT>> разработки, в которых проверяю новую математику. Для Си есть
 >  IT>> соответствующие сотрудники, которые пока ничего больше не знают. В SH4
 >  IT>> используется кросс-ассемблер, а не Форт.

 >  YK> SH-4 на ассемблере???? Мама роднАя...

 > От всего SH-4 нужен интерфейс к DRAM и вычислительный блок. Я
 > сомневаюсь, что в готовом виде там все займет больше килобайта.

Hа С он бы занял полтора и в 10 раз меньше времени.

 > Заметь, что твои охи и ахи ни в малейшей степени не способствуют освоению
 > чего-либо другого. Равно как и Орлов с Торресом вылезли только для

Hапример форта, от которого больше вреда чем пользы. И хоро что не
способствуют.

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

Их что, с зарплаты что ли покупают?

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

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


 > Он тебе скажет большое человеческое
 > спасибо за ценный, но неприменимый к российской действительности совет.

В российской действительности компиляторы бесплатны любые.

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


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

С уважением, Дима Орлов.


Re: _Loader_
Hello, Artem Kamburov !

 >> Именно. Ты эмуляторов (не только для PIC'ов) в глаза не видел, в лучшем
 > случае на картинке.

 > Хм... Попробуй тут не увидеть, когда почти каждая фирма торгующая
 > МК пытается тебе его всунуть ;).

Прям так и всунуть... А если видел, так откуда свеления про только DIP?

С уважением, Дима Орлов.


Re: _Loader_
5-Oct-03 13:56 Yuriy K wrote to Alex Kouznetsov:

YK>>>>>>> теряется та  самая возможность запретить написание завешиваемых
YK>>>>>>> программ,  с которой все и началось.

AK>>>>>> Если в интерпретаторе нет операторов, которые позволят "завесить"
AK>>>>>> программу, то завесить ее нельзя.

YK>>> Правда такой интерпретатор будет _очень_ медленным...

AK>> Представь, перед тобой два почти идентичных интерпретатора. Hо в первом
AK>> есть операторы обслуживания WDT и запрещения прерываний, а во втором -
AK>> нету. Ты будешь продолжать утверждать, что второй "будет _очень_
AK>> медленным"?

YK> Ты считаешь, что отсутсвие запрешения прерываний и работы с WDT достаточно
YK> для написания незавешиваемых программ?
YK> Ты крупно ошибаешься.
 Если я правильно понял -- речь не об этом. Да, если есть хоть
какие-то возможности управления ходом выполнения -- можно
написать нечто, сводимое к for(;;). Но если в выделенном для
{"плугинов"|user code} наборе команд нет команды сброса WDT -- то
такой бесконечный цикл сбросится и это будет повод для "системной"
части ПО заняться вопросом "а что произошло". Если в пользовательском
наборе команд отсутствует команда запрета прерываний, то этот код
не сможет прерывания запретить. Если внешние пакеты обрабатываются (в
прерываниях/системных потоках) и пользовательскому коду отдаются только
"его" пакеты, то "альлё! перешиваем код пользовательской части"
всегда дойдёт до системного кода.
 В процессорах с kernel/user состояниями для user code аппаратно
недоступны некоторые команды.
 В форте можно "системные" солва вынести в отдельный словарь, который
вырубать из списка словарей перед передачей управления на
"пользовательский" код.
 На скорость выполнения это не повлияет.

 Впрочем, без защиты памяти всегда можно обратиться "не туда"
и сильно попортить жизнь системной части. И вот чтобы отсечь это,
в "пользовательском" словаре для обращения к переменным должны быть
такие слова, которые проверяют все адреса и т.п.

И тут уже будет:
YK>>> Эффективный "форт" - не более защищен, чем тот же С/С++/whatever.
YK>>> Защищенный "форт" - страшно медленный и неэффективный, так же как и все
YK>>> остальные способы защиты программ от ошибок.

[...]
AK>>>> скажем, нет таких слов, которые могли бы запретить прерывания или
AK>>>> обслужить WDT.

YK>>> Соболезную. Как будем работать с железом без запрета прерываний?
 Через "системные" вызовы.
YK>>> Как пишутся обработчики прерываний?
 Драйвера - часть системы, выписаны и отлажены отдельно и предполагается,
что они надёжнее "пользовательского" кода. Это не зависит от языка.

wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: _Loader_

Quoted text here. Click to load it

Любой, компилятор которого сделан, чтобы генерить шитый код. Шитый код не
самоцель -
это просто способ добиться какого то результата - например уменьшить объем
объектной
программы.

Аркадий

_Loader_
Hello Yuriy!

04 Oct 31 13:15, Yuriy K wrote to Alex Kouznetsov:

 YK> Программист будет писать непосредственно шитым кодом?
 YK> Передавай ему мои соболезнования.

Hу, я писал непосpедственно шитым кодом, когда делал библиотечные п/п для
фоpтpана 4 Unix v7. Hичего сложного.

Anatoly


_Loader_
Sun Oct 05 2003 13:35, Anatoly Mashanov wrote to Yuriy K:

 YK>> Программист будет писать непосредственно шитым кодом?
 YK>> Передавай ему мои соболезнования.

 AM> Hу, я писал непосpедственно шитым кодом, когда делал библиотечные п/п для
 AM> фоpтpана 4 Unix v7. Hичего сложного.

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

Пороговый уровень - более одного программиста на проект.

WBR, Юрий.


Re: _Loader_
Hello Ilia.

09 Oct 03 00:02, you wrote to me:

 RK>> Просто переходы параллелить смысла нет - вся эта кухня расчитана
 RK>> на преимущественно вычислительные задачи.

 IT> Ээээ, я про переходы между узлами графа состояний... :) Переход к
 IT> новому адресу - это несколько не то. Hапример, если есть текст

 IT> A = 2  (1)
 IT> B = 1  (2)
 IT> A = 3  (3)

 IT> то можно поставить в соответствия строкам состояния S1, S2, S3
 IT> соответственно. Получаем граф S1 -> S2 -> S3. Выполнение первой строки
 IT> программы осуществляет переход от состояния S1 к состоянию S2, и т.д.
 IT> Я здесь пытаюсь говорить о таких графах, в которых переход от
 IT> состояния Si к состоянию Si+1 является "атомарным", т.е. не может быть
 IT> улучшен внутри.

Hичего не понял. Ты под 'переходом' понимаешь вычисления, которые принадлежат
этому состоянию? Если да - то это все вырождается в утверждение, что в
программе все вычисления зависимы. Hа таких программах суперскаляр выигрыша не
даст, хорошо только, что таких программ почти нет.

 RK>> Это неправильный пример, суперскаляр с одним исполнительным
 RK>> устройством не делают - это уже будет не суперскаляр.

 IT> Я согласен, что он неправильный, но в правильном нетрудно закопаться
 IT> :) Я пытаюсь сначала придти к общему мнению по простым примерам, а
 IT> потом потихоньку наращивать сложность.

Это не простой пример, это в корне неверный пример. Суперскаляров с одним
вычислителем _не бывает_, иначе это _не суперскаляр_.

 RK>> Ассемблеры (к каковым и относится целевой Форт компилятор) обычно
 RK>> оптимизирующими не бывают :) Оптимизирующими бывают ЯВУ (например
 RK>> с С в Форт)

 IT> Компилятор с Форта может
 IT> а) проводить оптимизацию "атомарных" узлов графа, в том случае, если
 IT> они все же реализуются несколькими ассемблерными командами. Hапример,
 IT> при разворачивании кода встречаются пары push pop, причем push - из
 IT> хвоста
 IT> предыдущей команды, а pop стоит в начале следующей и забирает только
 IT> что помещенный на стек результат в тот же регистр. Очевидно, что эта
 IT> пара может быть безболезненно убрана.

Это peephole оптимизация - она самая простая и вполне уляжется в 100 строк на
любом языке.

 IT> б) проводить алгоритмическую оптимизацию

В объемах, в которых ее производят современные компиляторы С, и все в 100
словах целевого компилятора Форта?

 IT>>> По поводу читаемости - очень спорный вопрос. Читаемость для
 IT>>> кого?
 RK>> Для того, кто это быдет сопровождать.

 IT> Hу у него же должно быть хотя бы минимальное понимание того, что он
 IT> сопровождает? Hаконец, он же не будет сопровождать кашу вида VAR @ DUP
 IT> - ROT SWAP [ HEX ] 2 ROT ! -

Hа Форте писать нечитаемые программы гораздо проще, чем на С. А читаемые,
соотвественно гораздо сложней :)

 IT>>> Для специалиста в cs, которому по большому счету все равно какой
 IT>>> язык?
 RK>> 'Сферический специалист в ваккуме' ?

 IT> А как ты считаешь, Си и Паскаль - разные языки?

Если сравнивать с Фортом - то они вообще одно и то же. Кстати, даже если не
сравнивать с Фортом, они весьма похожи, так как строятся приблизительно на
одних и тех же принципах, основные различия в синтаксисе и немного в семантике.

 RK>> Сколько Atmel и Microchip 'тщательно тестировали' свои кристаллы
 RK>> на моделях? Интересно, почему же у них новые версии кристаллов
 RK>> идут с _офигительным_ количеством errat?

 IT> И мне интересно! Я про топ-модели Intel-а в основном...

Intel'овские процессора _гораздо_ сложнее, чем все вместе взятые процессора
Atmel'а и Microchip'а. Кстати, и у них ошибок в кристалах хватает (не зря они
сделали загружаемый микрокод :)

 IT>>> Форт - это ведь не свалившаяся с неба фиговина, стековая машина
 IT>>> имеет под собой четкое и ясное математическое описание.
 RK>> От математики до железа довольно большой путь :)
 IT> В среднем - один транслятор HDL :)

HDL - это не чистая математика, он к железу все же ближе.

 IT>>> Я одно время сравнивал алгоритмы, реализуемые для пентиума на
 IT>>> Си++ и для своего форт-процессора. Численные, с вложенными
 IT>>> циклами, с обработкой массивов, с вызовом функций и т.п. В
 IT>>> среднем получалось, что для достижения паритета пентиум должен
 IT>>> иметь от 1,5 до 4 раз большую частоту!

 RK>> Мне так до сих пор никто не сказал - _почему_ Форт процессор
 RK>> производительнее обычного RISC'а?

 IT> У меня получалось так, что экономились прологовые и эпиолговые части
 IT> при вызове функций. Два-три уровня вложения - и Си начинает
 IT> генерировать пары push/pop, которые для Форт-процессора попросту не
 IT> нужны.

Это вопросы кодогенерации, к эффективности процессорной архитектуры это
отношения не имеет. Hапример на SPARC'е операции со стеком при вызове функций
не нужны (пока этот стек умещается в регистровых окнах на кристале) -
получается, что SPARC должен быть быстрее Форта?

 RK>>>> А если у Форт процессора кончится стек? Это проблема того же
 RK>>>> плана.
 IT>>> Во-первых, он больше на тех же ресурсах, и наращивается
 IT>>> прозрачнее.
 RK>> Одинаковый, а РОH'ы наращиваются почти так же прозрачно.
 IT> Hет, в ПЛИС не одинаковый, а ровно в 16 раз больше.

Одинаковый, на той же распределенной памяти.

 IT>>> Во-вторых, глубина стека хорошо прогнозируется и определяется по
 IT>>> максимальной вложенности подпрограмм.

 RK>> Хм, а если есть рекурсия?

 IT> По иерархии - распределенная память (блоки по 16 бит), блочная память
 IT> (4 или 18 кбит на блок в зависимости от серии), внешняя память.
 IT> Собственно, так и сейчас эти проблемы решаются, и стеки у программ
 IT> далеко не резиновые.

Это, конечно, хорошо, но в вопросах прогнозирования необходимой глубины стека
это не поможет :)

 IT>>> Для несложного эмбеддеда 16 - это много.

 RK>> 'Для несложного эмбеддеда' возможно.

 RK>> Отнюдь. Скорее меньше. Они внутри обычно строятся на основе шин,
 RK>> а шине все равно, сколько к ней подключено регистров - 4 или 5.

 IT> Далеко не все равно! А как они будут соединяться?

Hикак - используется выход одного блока памяти.

 IT>>>>> a = b + c + d  (1)
 IT>>>>> b = a + d - с  (2)
 IT>>>>> c = a + b + 3  (3)
 IT>>>>> d = a + b + c  (4)

 RK>> (1)

 IT>>> b = (b + c + d ) + d - c
 IT>>> с = (b + c + d ) + d - c
 IT>>> d = (b + c + d ) + b - c

 RK>> (2)

 IT>>> Видимо, от количества регистров все же зависит?

 RK>> Hет. Во первых - это не эквивалентно (1). А если имеется в виду
 RK>> параллельное исполнение всех 3х строк, то куда делся 'a=b+c+d'?
 RK>> Если же собственно a после вычислений не используется, то (2)
 RK>> эквивалентно b = c = b + 2*d d = 2*b+d

 IT> (Подожди, а почему не эквивалентно? Может быть, я не заметил чего-то?
 IT> Я-то как раз писал имея в виду, что они эквивалентны по получаемому
 IT> результату)

Подставим все выражения в (1), получим (все 4 выражения исполняются
одновременно):
a=b+c+d
b=2*d
c=b+c+3*d-3
d=2*b+2*c+6*d-3
(3)

Из (2) (при одновременном исполнении) получим:
a=?
b=b+2*d
c=b+2*d
d=2*b+d
(4)

Мне кажется что (3) и (4) весьма и весьма разные

 IT> Здесь важно не столько параллельное исполнение, а то, что при
 IT> назначении "теневых" регистров разрешаются некоторые зависимости по
 IT> данным.

Hет, изначально это зависимости нет, она может появится из за нехватки
регистров (регистры начнут переиспользоваться).

 RK>> А если говорить в общем, то зависимости по данным (сами по себе)
 RK>> не зависят от количества доступных регистров. Соответственно
 RK>> простои конвеера (которые зависят от зависимостям по данным) не
 RK>> зависят (напрямую) от количества регистров. От количества
 RK>> регистров зависит появятся ли spill/fill'ы, а уже они могут
 RK>> привести и к дополнительным зависимостям и к простою конвеера и к
 RK>> дополнительным обращениям в память.

 IT> Да, именно так.

Консенсус :)

 RK>>>> Увеличение числа РОHов - тоже.
 IT>>> Hу как же не сопровождается? Ассемблер-то меняется...

 RK>> Смотря как там были представленны эти РОH'ы, если в виде R<nn>
 RK>> (где <nn> - число), то просто надо изменить константы в
 RK>> ассемблере.

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

Все компиляторы, ориентированные на архитектуру с РОHами допускают переменное
число этих РОHов.

 IT> Hо даже для фиксированной архитектуры выписать все
 IT> зависимости - очень и очень сложное дело.

Все не надо. Так как регистры (в РОHах) равноправны, то и зависимости будут
одинаковые, компилятор будет использовать РОH как пул регистров и аппаратные
зависимости по их использованию будут относится к пулу в целом.

 IT> Тут эмпирики тоже достаточно много, не говоря уже о строгой матмодели
 IT> (напоминаю, назначение регистров считается NP-полной задачей).

Строго ее никто и не пытается решать.

 IT> Что касается терминологии, то тут трудно говорить... от недостатка
 IT> конструктивного обсуждения Форта в том числе

К сожалению, есть некоторые темы, любая дискуссия в рамках которой очень быстро
перерастает в выяснение отношений между участниками :(

 IT> Мне кажется, что с теоретической точки зрения над стеком может быть
 IT> надстроена система команд, не включающая в себя базовые операции,
 IT> предусмотренные в Форте. В этом случае стековый процессор не будет
 IT> являться Форт-процессором.

Мне кажется, что такой вещи, как Форт-процессор вообще не существует. Форт это
не язык програмирования и не тип архитектуры, а _система_ програмирования. И
если из этой системы убрать любую часть - она перестанет быть Форт системой. То
есть процессор для Форта нельзя рассматривать в отрыве от того, что будет на
нем крутиться.

 IT> Если же возможности стековой машины позволяют реализовать транслятор
 IT> Форта, то это Форт-процессор.

Практически на любой стековый процессор можно поставить Форт. Hа любой не
стековый процессор можно поставить Форт.

Java VM - это Форт процессор или нет?
А Эльбрус - это Форт процессор или нет? (машина сама по себе стековая, но его
ассемблер - Эль76, больше напоминает Algol)
А UDP Pascal VM (была такая стековая машина, на которую компилировала одна из
разновидностей Pascal'я) - Форт процессор или нет?

 IT> Возможно, так...

Вряд ли.

Roman


_Loader_
Thu Oct 09 2003 21:33, Roman Khvatov wrote to Ilia Tarasov:

 RK> Hello Ilia.

 RK> Hичего не понял. Ты под 'переходом' понимаешь вычисления, которые
 RK> принадлежат этому состоянию? Если да - то это все вырождается в

Вычисления принадлежат не самому состоянию, а вектору, соединяющему отдельные
узлы. Иными словами, чтобы перейти из S1 в S2, надо выполнить A=2

 RK> утверждение, что в программе все вычисления зависимы. Hа таких программах
 RK> суперскаляр выигрыша не даст, хорошо только, что таких программ почти
 RK> нет.

А дальше надо смотреть, можно ли представленный граф свести к эквивалентному.
Если да, то это и есть распараллеливание вычислений.

 RK>>> Это неправильный пример, суперскаляр с одним исполнительным
 RK>>> устройством не делают - это уже будет не суперскаляр.

 IT>> Я согласен, что он неправильный, но в правильном нетрудно закопаться
 IT>> :) Я пытаюсь сначала придти к общему мнению по простым примерам, а
 IT>> потом потихоньку наращивать сложность.

 RK> Это не простой пример, это в корне неверный пример. Суперскаляров с одним
 RK> вычислителем _не бывает_, иначе это _не суперскаляр_.

Хорошо, давай так: два параллельных вычислительных устройства при трех и более
наборах операндов для них.

 RK>>> Ассемблеры (к каковым и относится целевой Форт компилятор) обычно
 RK>>> оптимизирующими не бывают :) Оптимизирующими бывают ЯВУ (например
 RK>>> с С в Форт)

 IT>> Компилятор с Форта может
 IT>> а) проводить оптимизацию "атомарных" узлов графа, в том случае, если
 IT>> они все же реализуются несколькими ассемблерными командами. Hапример,
 IT>> при разворачивании кода встречаются пары push pop, причем push - из
 IT>> хвоста
 IT>> предыдущей команды, а pop стоит в начале следующей и забирает только
 IT>> что помещенный на стек результат в тот же регистр. Очевидно, что эта
 IT>> пара может быть безболезненно убрана.

 RK> Это peephole оптимизация - она самая простая и вполне уляжется в 100
 RK> строк на любом языке.

Fixed, с учетом сказанного выше:
 RK>>> Ассемблеры (к каковым и относится целевой Форт компилятор) обычно
 RK>>> оптимизирующими не бывают :) Оптимизирующими бывают ЯВУ (например

 IT>> б) проводить алгоритмическую оптимизацию

 RK> В объемах, в которых ее производят современные компиляторы С, и все в 100
 RK> словах целевого компилятора Форта?

Вообще-то чем меньше базовый набор операций, тем проще оптимизировать?

 IT>> Hу у него же должно быть хотя бы минимальное понимание того, что он
 IT>> сопровождает? Hаконец, он же не будет сопровождать кашу вида VAR @ DUP
 IT>> - ROT SWAP [ HEX ] 2 ROT ! -

 RK> Hа Форте писать нечитаемые программы гораздо проще, чем на С. А читаемые,
 RK> соотвественно гораздо сложней :)

На ассемблере тоже писать сложнее, чем на Си, в том числе и нечитаемые
программы. Однако требования задачи могут превалировать над предпочтениями
программиста.

 IT>> А как ты считаешь, Си и Паскаль - разные языки?

 RK> Если сравнивать с Фортом - то они вообще одно и то же. Кстати, даже если
 RK> не сравнивать с Фортом, они весьма похожи, так как строятся
 RK> приблизительно на одних и тех же принципах, основные различия в
 RK> синтаксисе и немного в семантике.

О чем и речь. Конструкции этих языков могут быть записаны, например, в форме
Бэкуса-Наура таким образом, что понять, что это за язык, будет невозможно.

 RK> Intel'овские процессора _гораздо_ сложнее, чем все вместе взятые
 RK> процессора Atmel'а и Microchip'а. Кстати, и у них ошибок в кристалах
 RK> хватает (не зря они сделали загружаемый микрокод :)

Загружаемый микрокод говорит о том, что в результате планирования такие
ситуации были спрогнозированы :)

 RK>>> От математики до железа довольно большой путь :)
 IT>> В среднем - один транслятор HDL :)

 RK> HDL - это не чистая математика, он к железу все же ближе.

Это формальный язык для записи математических соотношений. От матмодели к HDL
очень маленький шаг - выучить синтаксис HDL.

 RK>>> Мне так до сих пор никто не сказал - _почему_ Форт процессор
 RK>>> производительнее обычного RISC'а?

 IT>> У меня получалось так, что экономились прологовые и эпиолговые части
 IT>> при вызове функций. Два-три уровня вложения - и Си начинает
 IT>> генерировать пары push/pop, которые для Форт-процессора попросту не
 IT>> нужны.

 RK> Это вопросы кодогенерации, к эффективности процессорной архитектуры это

Ну у меня же не сферическая лошадь в вакууме, надо получить вполне конкретный
результат. Чем именно объясняется слабая пригодность какого-то процессора к
конкретной задаче - вопрос второй. А первый - как сделать, чтобы работало с
нужной производительностью?

 RK> отношения не имеет. Hапример на SPARC'е операции со стеком при вызове
 RK> функций не нужны (пока этот стек умещается в регистровых окнах на
 RK> кристале) - получается, что SPARC должен быть быстрее Форта?

Значит, эту часть кода он "сэкономит". Я же не говорю о том, что Форт вообще в
принципе быстрее всего на свете. Это просто _другая_ вычислительная модель, со
своими плюсами и минусами. Если для данных условий плюсы перевешивают, то что
мешает его использовать?

(А еще были Holy wars "Си против Паскаля" - ууу!... И чего ради? Все равно
тенденции таковы, что без понимания математики эмбеддеры скоро вымрут - то,
что они умеют, будет делаться какими-нибудь автоматическими генераторами
железа, кода и программируемой периферии. Вот мне и непонятно, почему все так
ополчились именно на Форт, видя в нем внешнюю шелуху и не видя того, что это
практически ЕДИНСТВЕННЫЙ язык, который дает возможность прикладному
программисту понять, как вообще строятся компиляторы, и почему они строятся
именно так)

 RK>>> Одинаковый, а РОH'ы наращиваются почти так же прозрачно.
 IT>> Hет, в ПЛИС не одинаковый, а ровно в 16 раз больше.

 RK> Одинаковый, на той же распределенной памяти.

Я описываю регистр, и не вижу сообщения о том, что он помещен в распределенной
памяти. А когда описываю стек, сообщается о занятых LUT.

 IT>> По иерархии - распределенная память (блоки по 16 бит), блочная память
 IT>> (4 или 18 кбит на блок в зависимости от серии), внешняя память.
 IT>> Собственно, так и сейчас эти проблемы решаются, и стеки у программ
 IT>> далеко не резиновые.

 RK> Это, конечно, хорошо, но в вопросах прогнозирования необходимой глубины
 RK> стека это не поможет :)

А что поможет? :) Из существующего?...

 IT>> Далеко не все равно! А как они будут соединяться?

 RK> Hикак - используется выход одного блока памяти.

Тогда ты описываешь плохой процессор, поскольку на то, чтобы достать пятый и
двенадцатый регистр, сложить их, и результат поместить в восьмой, потребуется
больше одного такта. Даже с двупортовой памятью. Кстати, вполне можно то ядро,
которое я делал для Xilinx, рассматривать именно в таком качестве - 32
регистра общего назначения, на каждом такте доступ к двум любым по чтению, и к
двум - по записи. Вопрос в том, что такое ядро может меняться за часы, а то и
минуты, и насколько целесообразно пользоваться для него довольно сложными
компиляторами?

 IT>>>>>> a = b + c + d  (1)
 IT>>>>>> b = a + d - с  (2)
 IT>>>>>> c = a + b + 3  (3)
 IT>>>>>> d = a + b + c  (4)

 RK>>> (1)

 IT>>>> b = (b + c + d ) + d - c
 IT>>>> с = (b + c + d ) + d - c
 IT>>>> d = (b + c + d ) + b - c

 RK>>> (2)

.........

 RK> Подставим все выражения в (1), получим (все 4 выражения исполняются
 RK> одновременно): a=b+c+d
 RK> b=2*d
 RK> c=b+c+3*d-3
 RK> d=2*b+2*c+6*d-3
 RK> (3)

Не 4, а первое, затем (2)-(4). Хотя бы пара строк (при необходимости можно
завести дополнительные теневые регистры).

 IT>> Здесь важно не столько параллельное исполнение, а то, что при
 IT>> назначении "теневых" регистров разрешаются некоторые зависимости по
 IT>> данным.

 RK> Hет, изначально это зависимости нет, она может появится из за нехватки
 RK> регистров (регистры начнут переиспользоваться).

О чем и речь! И сколько таких регистров надо: 8, 16, 32?

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

 RK> Все компиляторы, ориентированные на архитектуру с РОHами допускают
 RK> переменное число этих РОHов.

Почему качество кода у этих компиляторов разное?

 IT>> Hо даже для фиксированной архитектуры выписать все
 IT>> зависимости - очень и очень сложное дело.

 RK> Все не надо. Так как регистры (в РОHах) равноправны, то и зависимости
 RK> будут одинаковые, компилятор будет использовать РОH как пул регистров и
 RK> аппаратные зависимости по их использованию будут относится к пулу в
 RK> целом.

А если не фиксированная? В этом случае назначение регистров похоже на
собирание мозаики. Ну и что, что для симметричных регистров мозаика
укладывается в идеально круглую форму? А точнее, в правильный n-угольник...

 IT>> Тут эмпирики тоже достаточно много, не говоря уже о строгой матмодели
 IT>> (напоминаю, назначение регистров считается NP-полной задачей).

 RK> Строго ее никто и не пытается решать.

Потому и получаем ситуацию, когда приходится кое-что писать руками на
ассемблере.

 IT>> Что касается терминологии, то тут трудно говорить... от недостатка
 IT>> конструктивного обсуждения Форта в том числе

 RK> К сожалению, есть некоторые темы, любая дискуссия в рамках которой очень
 RK> быстро перерастает в выяснение отношений между участниками :(

Вот именно, что ":("

 RK> Мне кажется, что такой вещи, как Форт-процессор вообще не существует.
 RK> Форт это не язык програмирования и не тип архитектуры, а _система_
 RK> програмирования. И если из этой системы убрать любую часть - она
 RK> перестанет быть Форт системой. То есть процессор для Форта нельзя
 RK> рассматривать в отрыве от того, что будет на нем крутиться.

Тем не менее про отдельно взятый аппаратный или программный модуль можно
сказать, может он являться частью Форт-системы, или нет.

 IT>> Если же возможности стековой машины позволяют реализовать транслятор
 IT>> Форта, то это Форт-процессор.

 RK> Практически на любой стековый процессор можно поставить Форт. Hа любой не
 RK> стековый процессор можно поставить Форт.

Не на всех процессорах стековая модель будет одинаково эффективной. Если
атомарные операции, которые не могут быть выражены более простыми понятиями
языка, в свою очередь включают в себя больше одного состояния целевого
процессора, это не есть хорошо. У процессора может быть аппаратный второй
стек, может быть возможность для его организации (например, быстрое
переключение указателей), или же второй стек должен эмулироваться в памяти. В
последнем случае Форт превращается в академически интересный, но часто
бесполезный в практике случай.

 RK> Java VM - это Форт процессор или нет?

Набор команд JavaVM не эквивалентен набору слов Форта. Ставить туда Форт не
пробовал, поскольку незачем.

 RK> А Эльбрус - это Форт процессор или нет? (машина сама по себе стековая, но
 RK> его ассемблер - Эль76, больше напоминает Algol) А UDP Pascal VM (была
 RK> такая стековая машина, на которую компилировала одна из разновидностей
 RK> Pascal'я) - Форт процессор или нет?

Весь вопрос в том, в сколько команд ассемблера будут укладываться базовые
слова Форта.

Ну и, кстати, можно еще определить Форт через классификацию фаз компиляции.
Именно отсюда получается и стек, и постфиксная запись, и организация словарных
статей. Кстати, очень интересный разбор получился - фактически, рассматривая
классический интерпретатор, можно выделить: "вот это лексический анализ, вот
это синтаксический, семантический спрятан в IMMEDIATE-словах, вот генерация
кода"...


Re: _Loader_
Hello Ilia.

09 Oct 03 00:05, you wrote to me:

 RK>> А кто заставляет РОH'ы делать на регистрах? Они с испокон веков
 RK>> делались на памяти (возможно двухпортовой)

 IT> Ж:-[      ]

 IT> И как ЭТО параллелить? Это когда из 16 регистров доступ только к
 IT> одному (двум)?

А ко скольким тебе надо одновременно?

 IT> И сколько тактов гарантированно хватит на операции с таким набором?

Для 2х портовой - 1.5 (с конвеером):
Чтение 2х операндов
Операция+запись

 IT> Сколько ни видел софтовых ядер, везде регистрам соответствовали
 IT> обычные signal.

Крайне расточительно.

Roman


_Loader_
Thu Oct 09 2003 22:07, Roman Khvatov wrote to Ilia Tarasov:

 IT>> И как ЭТО параллелить? Это когда из 16 регистров доступ только к
 IT>> одному (двум)?

 RK> А ко скольким тебе надо одновременно?

Мне? Вообще не надо - те две ячейки, к которым есть доступ, укладываются в
схему стековых вычислений.

 IT>> И сколько тактов гарантированно хватит на операции с таким набором?

 RK> Для 2х портовой - 1.5 (с конвеером):
 RK> Чтение 2х операндов
 RK> Операция+запись

Т.е. с конечным автоматом мы прощаемся.

 IT>> Сколько ни видел софтовых ядер, везде регистрам соответствовали
 IT>> обычные signal.

 RK> Крайне расточительно.

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


Re: _Loader_
9-Oct-03 19:39 Ilia Tarasov wrote to Roman Khvatov:

IT>>> Сколько ни видел софтовых ядер, везде регистрам соответствовали
IT>>> обычные signal.

RK>> Крайне расточительно.

IT> Это регистры. По определению. Если ты хочешь память, соответственно,
IT> архитектуру надо так и назвать. Заставить HDL синтезировать что-то,
IT> отличное
IT> от триггеров, довольно сложно, для этого исходный текст должен
соответствовать

IT> определенному шаблону, распознаваемому средствами синтеза.

 Я для альтеры на AHDL пишу, как подсел на него на MAX+II 7.0, так до сих
пор и не слезу никак.

 А что, из VHDL никак нельзя использовать ни встроенные блоки ОЗУ,
ни распределённое 16-битовое ОЗУ в ячейках?
А как же тогда с fifo, стеками, двухпортовым ОЗУ?


9-Oct-03 19:44 Ilia Tarasov wrote to Roman Khvatov:

RK>> Одинаковый, на той же распределенной памяти.

IT> Я описываю регистр, и не вижу сообщения о том, что он помещен в
распределенной

IT> памяти. А когда описываю стек, сообщается о занятых LUT.

Ну один регистр - понятно. Но ведь банк из 16 регистров
можно уложить в ОЗУ 16x8 (16x16, или сколько там надо).
Т.е. занять столько же LUT, сколько и для стека на 16 позиций
той же ширины. И не надо никаких дополнительных мультиплексоров.


RK>> Hикак - используется выход одного блока памяти.

IT> Тогда ты описываешь плохой процессор, поскольку на то, чтобы достать
IT> пятый и
IT> двенадцатый регистр, сложить их, и результат поместить в восьмой,
 А почему сразу трёхадресаня система команд? "Чтобы невозможнее было"?

Для аккумуляторно-регистровой арихитектуры даже с "результат
назад в регистр или в аккумулятор" достаточно однопортового
ОЗУ с линиями DI/DO.

Для регистровой двухадресной достаточно двухпортового ОЗУ
с одним портом на чтение и одним портом на чтение/запись.
Т.е. "честного двухпортового" ОЗУ более чем достаточно.

 Но вот только у альтер нет распределённого ОЗУ и только
в самых толстых современных семействах появились сравнительно
мелкие блоки ОЗУ.
 А использовать встроенный блок 128x32 или 256x16 толи как банк
РОН, толи как один стек -- как то жалко.
Хотя в NIOS-е они сделали "стек банков РОН".
 Сейчас вот подумалось -- для утилизации "лишней" памяти
в блоке ОЗУ в случае стекового процессора можно было бы "раз такого
стека много для одного процессора, сделаем четыре".
АЛУ одно на всех. Один блок ОЗУ -- стеки данных, другой -- стеки
возвратов.
Разбить один блок ОЗУ на 4 части по 32x32 (64x16),
старшие 2 разряда адреса подать от счётчика номера "текущего
процессора".
 Всё глубоко конвейеризовать и отдать каждому процессору
4 такта на команду (конвейеры разрушаться не будут, так
как в каждый момент времени от каждого процессора в конвейере
будет только одна команда).

Для ухода от мультиплексоров (ячейки и, главное, скорость)
все "персональные" регистры этих 4 процессоров "закольцевать".
Т.е., скажем, указатели стеков данных
+------------------------ LU ------+
|                                  |
+-> DP3 -> DP2 -> DP1 -> LU -> DP0 +-> LU -> RGDP -> на адреса блока ОЗУ

Между DP1 и DP0 и между DP0 и DP3 могут быть инкременторы/декременторы,
управляемые от соответствующих выходов дешифратора команд (или битов
команды), между DP0 и регистром собственно адреса стека
RGDP -- тоже сумматор, позволит дотянуться до К-той от верхушки
позиции. Очень аккуратно придётся выписывать все пути
полей команды, чтобы нужное поле команды каждого процессора
подошло к соответствующему операционному узлу в нужный момент.
Но поскольку везде всего один слой логики в LUT ячейки, тактовая
этих узлов будет практически равна предельной для кристалла.
И надо ещё посмотреть, не окажется ли, что эта частота,
поделённая на 4, будет ненамного ниже, чем частота одного процессора,
имеющего всё монопольно и работающего в однотактовом режиме.

wbr,
===
Маленькая девочка: -- Хорошо, что я не люблю помидоры!
Взрослый: -- а почему?
М.д. -- да если бы я их любила, мне пришлось бы их есть, а я их
 терпеть не могу!

--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: _Loader_
Sun Oct 12 2003 03:52, Oleksandr Redchuk wrote to "Ilia Tarasov":

 OR>  Я для альтеры на AHDL пишу, как подсел на него на MAX+II 7.0, так до сих
 OR> пор и не слезу никак.

Altera и Xilinx , имхо, делают вполне паритетную продукцию.

 OR>  А что, из VHDL никак нельзя использовать ни встроенные блоки ОЗУ,
 OR> ни распределённое 16-битовое ОЗУ в ячейках?
 OR> А как же тогда с fifo, стеками, двухпортовым ОЗУ?

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

======================================================================
entity dpdistram is
 port (clk  : in std_logic;
     we   : in std_logic;
     a    : in std_logic_vector(4 downto 0);
     dpra : in std_logic_vector(4 downto 0);
     di   : in std_logic_vector(3 downto 0);
     spo  : out std_logic_vector(3 downto 0);
     dpo  : out std_logic_vector(3 downto 0));
 end dpdistram;
 
 architecture syn of dpdistram is
 type ram_type is array (31 downto 0) of std_logic_vector (3 downto 0);
 signal RAM : ram_type;
 
 begin
 process (clk)
 begin
     if (clk'event and clk = '1') then  
         if (we = '1') then
             RAM(conv_integer(a)) <= di;
         end if;
     end if;
 end process;
 
 spo <= RAM(conv_integer(a));
 dpo <= RAM(conv_integer(dpra));
 
 end syn;
======================================================================

Некоторая проблема в том, что внутри process не должно быть ничего лишнего,
иначе все попадает в регистры... :-/

 OR> Hу один регистр - понятно. Hо ведь банк из 16 регистров
 OR> можно уложить в ОЗУ 16x8 (16x16, или сколько там надо).
 OR> Т.е. занять столько же LUT, сколько и для стека на 16 позиций
 OR> той же ширины. И не надо никаких дополнительных мультиплексоров.

См. выше... Если к регистрам обращаться хоть как-то иначе, они могут не
попасть в LUT...

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

 OR>  А почему сразу трёхадресаня система команд? "Чтобы невозможнее было"?

Чтобы упростить жизнь оптимизатору.

 OR> Для аккумуляторно-регистровой арихитектуры даже с "результат
 OR> назад в регистр или в аккумулятор" достаточно однопортового
 OR> ОЗУ с линиями DI/DO.

Да... Получится КА с программным управлением :)

 OR> Для регистровой двухадресной достаточно двухпортового ОЗУ
 OR> с одним портом на чтение и одним портом на чтение/запись.
 OR> Т.е. "честного двухпортового" ОЗУ более чем достаточно.

Я такое уже пронаблюдал. Действительно, все так и есть, читать можно из любых
регистров, и писать тоже в любой. Однако работать с таким процессором сможет
только его автор :) Систему команд надо все же чем-то ограничить, иначе при
последующей отладке всего устройства может появиться мешанина из правок в
прикладной программе, в компиляторе/ассемблере и в самом процессоре. С Фортом
именно у нас так сложилось, поэтому я и привожу его в качестве примера. А
вообще в ПЛИС можно сделать практически любое процессорное устройство, в
пределах разумного...

 OR>  Hо вот только у альтер нет распределённого ОЗУ и только
 OR> в самых толстых современных семействах появились сравнительно
 OR> мелкие блоки ОЗУ.
 OR>  А использовать встроенный блок 128x32 или 256x16 толи как банк
 OR> РОH, толи как один стек -- как то жалко.
 OR> Хотя в NIOS-е они сделали "стек банков РОH".

Альтера от Xilinx отличается вобщем-то двумя моментами. Распределенная память
и внутренние Z-буферы. Xilinx делает и то, и другое, Altera - нет. У альтеры
получаются меньшие задержки, но в ряде случаев без таких возможностей
оказывается тяжеловато. Эти различия тоже бывают предметом Holy wars, хотя на
фоне всех остальных причин выбора той или иной фирмы это все очень
несущественно и влияет разве что на выбор стиля проектирования... Для альтеры
я, наверное, делал бы иначе и не все бы упиралось именно в возможности
распределенной памяти.

 OR>  Сейчас вот подумалось -- для утилизации "лишней" памяти
 OR> в блоке ОЗУ в случае стекового процессора можно было бы "раз такого
 OR> стека много для одного процессора, сделаем четыре".
 OR> АЛУ одно на всех. Один блок ОЗУ -- стеки данных, другой -- стеки
 OR> возвратов.
 OR> Разбить один блок ОЗУ на 4 части по 32x32 (64x16),
 OR> старшие 2 разряда адреса подать от счётчика номера "текущего
 OR> процессора".
 OR>  Всё глубоко конвейеризовать и отдать каждому процессору
 OR> 4 такта на команду (конвейеры разрушаться не будут, так
 OR> как в каждый момент времени от каждого процессора в конвейере
 OR> будет только одна команда).

Оооо! :)))) Это к Ивану Макарченко (Ivan Mak), уже не помню его домашний сайт,
но можно поискать на www.petersplus.com информацию по компьютеру "Спринтер".
Именно такой процессор на альтере он и разработал, и тоже под Форт.


Re: _Loader_
12-Oct-03 17:51 Ilia Tarasov wrote to Oleksandr Redchuk:

OR>>  Всё глубоко конвейеризовать и отдать каждому процессору
OR>> 4 такта на команду (конвейеры разрушаться не будут, так
OR>> как в каждый момент времени от каждого процессора в конвейере
OR>> будет только одна команда).

IT> Оооо! :)))) Это к Ивану Макарченко (Ivan Mak), уже не помню его домашний
IT> сайт,
IT> но можно поискать на www.petersplus.com информацию по компьютеру "Спринтер".
IT> Именно такой процессор на альтере он и разработал, и тоже под Форт.

 Я порылся по архивам pvt.hardw.max2plus, он когда-то туда кидал
структурную схему. Так там 4 стека по 64 слова и все в одном блоке памяти,
но то всё стеки одного процессора -- в каждой 16-битной команде
есть 2-битовое поле выбора стека. 4-процессорности я там не нашёл.
Впрочем, с 99 года утекло _очень_ много воды....

wbr,


--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: _Loader_
Sun Oct 19 2003 22:19, Oleksandr Redchuk wrote to "Ilia Tarasov":

 OR>  Я порылся по архивам pvt.hardw.max2plus, он когда-то туда кидал
 OR> структурную схему. Так там 4 стека по 64 слова и все в одном блоке
 OR> памяти,
 OR> но то всё стеки одного процессора -- в каждой 16-битной команде
 OR> есть 2-битовое поле выбора стека. 4-процессорности я там не нашёл.
 OR> Впрочем, с 99 года утекло _очень_ много воды....

У него сейчас несколько другие текущие задачи, но структурные схемы
процессоров в ПЛИС мы одно время очень активно обсуждали в почте. Его идея
была именно в 4-х процессорах, сдвинутых на такт в четырехтактной схеме
обработки команды. Другое дело, что ACEX1K30 (ACEX1K100?) - это немного не то,
что нужно, чтобы развернуться как следует и получить реальный проект. Не могу
сказать, какие материалы и где сейчас выложены, лучше, наверное, ему написать
и уточнить этот вопрос.


Re: _Loader_
Hello Artem.

09 Oct 03 00:19, you wrote to me:

 >>  IT> К тому же... а что, собственно, надо будет исправлять в железе
 >>  IT> после тщательного тестирования на моделях?
 >>
 >> Сколько Atmel и Microchip 'тщательно тестировали' свои кристаллы на
 >> моделях? Интересно, почему же у них новые версии кристаллов идут с
 >> _офигительным_ количеством errat?
 AK> Кстати, Атмел на последних чипах вроде исправился :).

Угу, наконец то вылизал все старые баги :)

 >>  RK>> А если у Форт процессора кончится стек? Это проблема того же
 >>  RK>> плана.
 >>
 >>  IT> Во-первых, он больше на тех же ресурсах, и наращивается
 >>  IT> прозрачнее.
 >>
 >> Одинаковый, а РОH'ы наращиваются почти так же прозрачно.

 AK> Hет. Добавление РОHа может повлечь необходимость изменения всей
 AK> системы комманд процессора (вплоть до увеличения размера комманды),

Только в этом случае.

Roman


Site Timeline