_Loader_ - Page 12

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

Threaded View
_Loader_
Sat Oct 11 2003 11:11, Vadim Rumyantsev wrote to Ilia Tarasov:

 IT>> Дело было на семинаре соответствующей секции РАH....

 VR> Если даже зам. Главного конструктора "Энергии" посетил этот семинар и
 VR> информировал академиков о существующих планах, то слова "клятвенно
 VR> обещал" здесь совершенно неуместны. Вопросы конструкторских решений в
 VR> бортовой аппаратуре к РАH отношения не имеют.

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

(Или и ты сейчас придираться начнешь?...)


Re: _Loader_
Hello, Artem Kamburov !

 >>  AK> Кроме того, я не виде эмуляторов с SOIC-ом, а с DIP-ом как-то не
 >>  AK> интересно

 >> Ой... Hе, явно не видел.

 > Ладно, принято. Эмулятор ICE 200 сейчас SOIC имеет.

Вообще-то эти переходники выпускаются сторонними фирмами для всех типов
корпусов. Одна так и называется www.emulator.com.

 > Hо дела это сильно не меняет.

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

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


Re: _Loader_
Всем привет.

Quoted text here. Click to load it
случае
Quoted text here. Click to load it

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

                    АртемКАД



_Loader_
Hi Eugene,

Tue Sep 30 2003 17:44, Eugene Romanov wrote to Alex Kouznetsov:

 AK>>>> Скорость зависит от того как сделан интерпретатор.
 PU>>> Hо она никогда не переплюнет скорость работы native кода?! Ж8-)
 AK>> Встречались сообщения, что вполне может переплюнуть,
 AK>> http://talk.mail.ru/article-26762867.html Чтобы было понятнее, SPF4 -
 AK>> это Форт с оптимизацией.

 ER> Меня теpзают cмyтные cомнения, что это пpоcто иcходный алгоpитм
 ER> cоптимизиpовалcя гpамотно. А до нативного кода любомy интеpпpетатоpy -
 ER> как до Лyны пешком. Ибо на какой-нибyдь "add r0, #15" нативного кода
 ER> бyдет навешано некотоpое количеcтво телодвижений интеpпpетатоpа.

Это распространенное мнение, но вообще-то оно ошибочно. То есть, для
большинства интерпретаторов это так. Но не для всех. Граница между
интерпретацией и исполнением нативного кода весьма зыбка и расплывчата,
особенно если имеешь дело с Фортом.
 
SPF, о котором идет речь, использует так наз. подпрограммный шитый код.
Программа, интерпретируемая им, выглядит примерно так:
  call DUP
  call MUL
... и т.д.
Так что из "телодвижений интеpпpетатоpа" на каждое слово приходятся только
call и ret.
"Внутренности" SPF я знаю не очень хорошо, но по-моему при трансляции он
инлайнит некоторую часть кода (по крайней мере, литералы и переходы).
Если сравнивать это с результатом работы какого-нибудь С компилятора, то особо
большой разницы не заметишь. Разве что больше call-ов, и нет манипуляций с
фреймами.

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


Re: _Loader_
Hello, Alex Kouznetsov !

 >  YK> 2) Чистый форт-_интерпретатор_, как и любой другой интерпретатор будет
 >  YK> гораздо медленнее (приличного) _компилятора_ с любого языка.

 > Тебе внятно показали, что интерпретатор подпрограммного шитого кода работает
 > не медленнее, чем нативная программа, скомпилированная VC7. И долго
 > разжевывали, объясняя, за счет чего это происходит.

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

 >  YK> Остается (с твоих слов) использовать приличный язык для написания
 >  YK> программ, затем компилятор в форт и подпрограммный шитый код, но тогда

 > Hа языке Форт писать, или на этот язык транслировать - тебя никто
 > не заставляет. Да и транслятор С-Форт ты вряд ли найдешь.

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

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

 > Если в интерпретаторе нет операторов, которые позволят "завесить"
 > программу, то завесить ее нельзя. Для начала, нет операторов, которые
 > запрещают прерывание. В том самом подпрограммном шитом коде (иными словами -

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

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

Это если этот код не нуждается в новых словах (подпрограммах).

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


Re: _Loader_
Hello, Arcady Schekochikhin !

 >> Hе быстрее ассемблера, а быстрее нативного кода. Hаписать быстрее ассемблер
 > а элементарно - нужно лишь на ассемблере написать неэффективно. Что-то
 >> выполняться быстрее нативного кода не может в принципе, так как кроме
 > натив ного кода процессор ничего не выполняет и сам себя обогнать не может.
 > Это абсурд.

 > Это несомнно не так в общем случае. Кроме нативного кода может еще
 > существовать и "микро-нативный" код и если есть возможность доступиться
 > к нему (а-ля загружаемая микропрограмма), то ряд конструкций может быть
 > написан прямо на нем, сильно ускоряя работу именно этих конструкций.

Допустим. Hо это тоже делается средствами нативного кода.

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

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

 > Второе "стилистическое" возражение - нативный код на форт машине
 > будет как минимум равен по скорости форт-программе (а не быстрее ее).

Почему собственно не быстрее?

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


Re: _Loader_

Quoted text here. Click to load it

Нет - например втыканием дополнительной ПЗУ.
 
Quoted text here. Click to load it

Передергиваешь. Это имеет отношение к новой виртуальной машине полученной
перезагрузкой микрокода. Новые примитивы НЕ БУДУТ являться нативным кодом
СТАРОЙ МАШИНЫ. В то же время старый нативный код будет частью данной новой
машины. А мы сравниваем именно нативный код ИСХОДНОЙ машины с выполнением
форт-программы на новой (полученной возможно на средствами форта). Если ты
скажешь что это теперь тоже стало нативным кодом и .... - см. ниже.
 
Quoted text here. Click to load it

Потому что на форт-машине "нативный код" ЭКВИВАЛЕНТЕН "форт-коду".
Свойство такое.

Аркадий

Re: _Loader_
Hello Ilia.

03 Oct 03 22:46, you wrote to me:

 IT> Java - все же несколько не то. Форт <> байткод.

Hо причина падения производительности таже самая - стековая машина.

 IT> Представим, что действительно все (ну или почти все) команды в
 IT> исходном алгоритме зависимы по данным.

Так практически не бывает.

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

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

 IT> Стек есть стек, он имеет свои особенности просто по определению. В
 IT> частности, операции с ним не параллелятся.

И это фатально.

 IT> А вот компилировать код для стековой машины обычно гораздо проще.

А это дело компилятора, обычно они неплохо справляются не только со стековыми
машинами :)

 IT> Для сравнения рассмотрим 4 симметричных регистра, и добавим к ним
 IT> пятый.

Такой же симметричный?

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

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

 IT> как именно нужно изменить компилятор

Hикак, просто исправить константу в распределении регистров в компиляторе.

 IT>  и для каких задач добавление пятого регистра вообще актуально?

Только изучением конкретных задач.

Могу сказать, как обычно строят код компиляторы - сначала генерируется код в
предположении бесконечного числа регистров (так называемые виртуальные
регистры), затем в полученном коде производится назначение реальных регистров
виртуальным. Если на каком либо участке кода реальных регистров не хватает,
делается так называемый register splill/fill - содержимое какого либо регистра
сохраняется на стеке, а сам регистр используется по назначению, затем
содержимое регистра восстанавливается со стека.

Roman


_Loader_
Sat Oct 04 2003 14:20, Roman Khvatov wrote to Ilia Tarasov:

 IT>> Представим, что действительно все (ну или почти все) команды в
 IT>> исходном алгоритме зависимы по данным.

 RK> Так практически не бывает.

y=sin(sqrt(abs(2*x))) Что здесь независимого?

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

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

 RK> Разумеется, просто я хочу обратить внимание фанатов Форта, что и он имеет
 RK> свои недостатки, и далеко не на всех процессорах на Форте получатся
 RK> программы быстрее, чем на том же С.

Это очевидно.
(btw, я далеко не фанат... просто Форт дает мне возможность вполне неплохо
зарабатывать. А кроме фанатов существуют еще и антифанаты Форта :) ... и это
уже очень интересно!)

 IT>> Стек есть стек, он имеет свои особенности просто по определению. В
 IT>> частности, операции с ним не параллелятся.

 RK> И это фатально.

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

 IT>> А вот компилировать код для стековой машины обычно гораздо проще.

 RK> А это дело компилятора, обычно они неплохо справляются не только со
 RK> стековыми машинами :)

А компилятор - это такая программка, которая ставится с компакт-диска? :) И
она безглючна, бесплатна, осваивается в момент доставания диска из коробочки?

 IT>> Для сравнения рассмотрим 4 симметричных регистра, и добавим к ним
 IT>> пятый.

 RK> Такой же симметричный?

Такой же, или не такой же... не столь важно.

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

 RK> Если для задачи хватало 4х регистров - то повышения производительности не
 RK> будет вообще, а если не хватало - то быдет весьма значительная.

Как понять "хватало"? Это когда в программе только 4 переменные, или когда
зависимость по данным не вызывает простоев конвейера? И "весьма значительная"
- это сколько? Стоит ли делать новый процессор с дополнительным регистром,
будет ли он иметь лучшее соотношение цена/производительность? И главное, не
съестся ли эта добавка общим снижением рабочей частоты кристалла из-за
усложнения схемы?

 IT>> как именно нужно изменить компилятор

 RK> Hикак, просто исправить константу в распределении регистров в
 RK> компиляторе.

Неужели так просто? :)

 RK> Могу сказать, как обычно строят код компиляторы - сначала генерируется
 RK> код в предположении бесконечного числа регистров (так называемые
 RK> виртуальные регистры), затем в полученном коде производится назначение
 RK> реальных регистров виртуальным. Если на каком либо участке кода реальных
 RK> регистров не хватает, делается так называемый register splill/fill -
 RK> содержимое какого либо регистра сохраняется на стеке, а сам регистр
 RK> используется по назначению, затем содержимое регистра восстанавливается
 RK> со стека.

Это очень обобщенное описание. По каким принципам производится назначение
регистров? Например, надо в 80x86 сложить что-нибудь с AX. В какой регистр
будем грузить второй операнд: BX, CX, DX? Далее по тексту может быть: загрузка
из памяти (будет использован BX), инициализация цикла (счетчик в CX) или
обращение в УВВ (адрес в DX). А может и ничего из перечисленного... Это пример
несимметричного регистрового набора.


_Loader_
Sat Oct 04 2003 21:55, Ilia Tarasov wrote to Roman Khvatov:

 IT>>> Представим, что действительно все (ну или почти все) команды в
 IT>>> исходном алгоритме зависимы по данным.
 RK>> Так практически не бывает.
 IT> y=sin(sqrt(abs(2*x))) Что здесь независимого?

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

 IT> Hапример, алгоритмы цифровой обработки часто сводятся к умножению с
 IT> накоплением. Представим, что перемножитель один, и является,
 IT> соответственно, узким местом. Что в этом случае можно распараллелить?

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

 VLV

"There is no business other than show business" (c)


_Loader_
Sat Oct 04 2003 23:41, Vladimir Vassilevsky wrote to Ilia Tarasov:

 IT>>>> Представим, что действительно все (ну или почти все) команды в
 IT>>>> исходном алгоритме зависимы по данным.
 RK>>> Так практически не бывает.
 IT>> y=sin(sqrt(abs(2*x))) Что здесь независимого?

 VV>  Синус и корень считаются через ряды, у которых можно считать параллельно
 VV>  по нескольку членов.

Согласен, пример не совсем удачный ввиду особенностей технической реализации.
Давай иначе: даны события (функции) f1 f2 f3 ... fn , переводящие некоторый
конечный автомат в состояния S1 S2 S3 ... Sn  соответственно. Пусть также дан
граф, задающий порядок переходов вида:

S1 -> S2 -> S3 -> ... Sn

Вопрос (с очевидным ответом): можно ли выполнить редукцию такого графа?

 IT>> Hапример, алгоритмы цифровой обработки часто сводятся к умножению с
 IT>> накоплением. Представим, что перемножитель один, и является,
 IT>> соответственно, узким местом. Что в этом случае можно распараллелить?

 VV>  Запись/чтение памяти, продвижение указателей, проверку границ и условий.

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

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


Re: _Loader_
30-Sep-03 16:44 Eugene Romanov wrote to Alex Kouznetsov:

 AK>>>> Скорость зависит от того как сделан интерпретатор.
 PU>>> Hо она никогда не переплюнет скорость работы native кода?! Ж8-)
 AK>> Встречались сообщения, что вполне может переплюнуть,
 AK>> http://talk.mail.ru/article-26762867.html Чтобы было понятнее, SPF4 -
 AK>> это Форт с оптимизацией.

ER> Меня теpзают cмyтные cомнения, что это пpоcто иcходный алгоpитм
ER> cоптимизиpовалcя гpамотно. А до нативного кода любомy интеpпpетатоpy -
ER> как до
ER> Лyны пешком. Ибо на какой-нибyдь "add r0, #15" нативного кода бyдет
ER> навешано
ER> некотоpое количеcтво телодвижений интеpпpетатоpа. А напиcать нативный
 Да нет.
 Форт с оптимизацией "разворачивает" слова в машкод.
Пользуясь С-шной терминологией, "инлайнит" все функции и дальше
оптимизирует машкод.
 Но тут два момента:
1) тут уже надо "помахать ручкой" компактности кода, присущей
интерпретаторам. Адепты форта обычно "забывают" об этом,
и умудряются одновремённо говорить "самый компактный" и "самый
быстрый". Думаю, впрочем, что они такие же фортеры, как "линуксоиды",
которые только и умеют кричать Win must die, а сами линукса не знают.

2) Я согласен, что такой оптимизированный код может быть быстрее, чем
программа, сгенерённая плохим C-компилятором или написанная плохим
ASM-программистом. Но те же адепты почему-то об этом ("плохим") тоже
забывают.

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

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


Re: _Loader_
Hi Oleksandr,

Wed Oct 01 2003 22:20, Oleksandr Redchuk wrote to Eugene Romanov:

 AK>>>>> Скорость зависит от того как сделан интерпретатор.
 PU>>>> Hо она никогда не переплюнет скорость работы native кода?! Ж8-)
 AK>>> Встречались сообщения, что вполне может переплюнуть,
 AK>>> http://talk.mail.ru/article-26762867.html Чтобы было понятнее, SPF4 -
 AK>>> это Форт с оптимизацией.

 ER>> Меня теpзают cмyтные cомнения, что это пpоcто иcходный алгоpитм
 ER>> cоптимизиpовалcя гpамотно. А до нативного кода любомy интеpпpетатоpy -
 ER>> как до
 ER>> Лyны пешком. Ибо на какой-нибyдь "add r0, #15" нативного кода бyдет
 ER>> навешано
 ER>> некотоpое количеcтво телодвижений интеpпpетатоpа. А напиcать нативный

 OR>  Да нет.
 OR>  Форт с оптимизацией "разворачивает" слова в машкод.
 OR> Пользуясь С-шной терминологией, "инлайнит" все функции и дальше
 OR> оптимизирует машкод.

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


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


Re: _Loader_
Hello, Alex Kouznetsov !

 >  AK>>>> Скорость зависит от того как сделан интерпретатор.
 >  PU>>> Hо она никогда не переплюнет скорость работы native кода?! Ж8-)
 >  AK>> Встречались сообщения, что вполне может переплюнуть,
 >  AK>> http://talk.mail.ru/article-26762867.html Чтобы было понятнее, SPF4 -
 >  AK>> это Форт с оптимизацией.

 >  ER> Меня теpзают cмyтные cомнения, что это пpоcто иcходный алгоpитм
 >  ER> cоптимизиpовалcя гpамотно. А до нативного кода любомy интеpпpетатоpy -
 >  ER> как до Лyны пешком. Ибо на какой-нибyдь "add r0, #15" нативного кода
 >  ER> бyдет навешано некотоpое количеcтво телодвижений интеpпpетатоpа.

 > Это распространенное мнение, но вообще-то оно ошибочно. То есть,

Hичуть.

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

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

 > расплывчата, особенно если имеешь дело с Фортом.

 > SPF, о котором идет речь, использует так наз. подпрограммный шитый
 > код.
 > Программа, интерпретируемая им, выглядит примерно так:
 >   call DUP
 >   call MUL

То есть лишний call, ret, обращение к памяти (константа-то из предыдущего
примера считывается вместе с командой, а не вытаскивается косвенным обращением
к объявленной стеком данных области ОЗУ). Попутно имеем сброс конвеера в
процессорах где он есть и замедление быстродействия в несколько раз. Кроме
того, быстроадресуемые регистры оказываются просто неиспользованными.

 > ... и т.д.
 > Так что из "телодвижений интеpпpетатоpа" на каждое слово
 > приходятся только call и ret.

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

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


Re: _Loader_
Привет тебе, Alex!

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

 AK> SPF, о котором идет речь, использует так наз. подпрограммный шитый
 AK> код. Программа, интерпретируемая им, выглядит примерно так:
 AK> call DUP
 AK> call MUL

Эти "call" - команды пpоцеccоpа или виpтyальной фоpт-машины? Еcли пpоцеccоpа,
то мы имеем дело c компилиpованной в нативный код пpогpаммой. Далее идет пpоcто
cpавнение качеcтва компилятоpов. Еcли же это - команды виpтyальной машины, то
для того, чтобы нативный код оказалcя медленней, необходимо единcтвенное
ycловие: пpогpаммy для компилятоpа без малейших зачатков оптимизации пиcал
cтyдент-двоечник по алгоpитмy, пpидyманномy им же "на yтpо поcле".

С yважением, Eвгений.
             ewg::cats-online.ru

... котят по осени считают

_Loader_
Hi Eugene,

Wed Oct 01 2003 15:30, Eugene Romanov wrote to Alex Kouznetsov:

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

 AK>> SPF, о котором идет речь, использует так наз. подпрограммный шитый
 AK>> код. Программа, интерпретируемая им, выглядит примерно так:
 AK>> call DUP
 AK>> call MUL

 ER> Эти "call" - команды пpоцеccоpа или виpтyальной фоpт-машины? Еcли
 ER> пpоцеccоpа, то мы имеем дело c компилиpованной в нативный код пpогpаммой.
 ER> Далее идет пpоcто cpавнение качеcтва компилятоpов.

Это команды процессора. Я же писал, граница между нативным кодом и
нинтерпретируемым очень зыбкая. Для подпрограммного шитого кода
"интерпретатор" - это сам процессор, с его call и ret, а вся Форт-система
может быть представлена как определенным образом организованный набор
подпрограмм. Тем не менее, Форт традиционно считается интерпретируемым языком.

Изначально ведь речь шла о том, насколько быстрым может быть интерпретатор. Я
привел пример - практически он может быть сколь угодно быстрым.

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


Re: _Loader_
Hello, Arcady Schekochikhin !

 > ЗЫ ФОРТ это несомненная жемчужина среди языков программирования,

А по-моему, - крайней уродливости образование.


 > знание его основ и идей несомненно полезно любому программисту.

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

 > Использовать его широко в реальной жизни - ну это врятли.


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


Re: _Loader_

Quoted text here. Click to load it

Ты мне ссылочку кинь на разработанный тобой язык, проживший 30 лет и
стандартизованный, тогда может я поверю что так делать НЕ НАДО.

Аркадий

Re: _Loader_
Hello, Oleksandr Redchuk !

 >>> момент в персоналках в частности процессор - самый быстрый элемент.

 > DO> Вообще-то тут обсуждаются преимущественно микроконтролеры, а не
 > персоналки.
 > DO> Для персоналок писать на форте в голову никому не приходит слава богу.

 >  Hу почему.

Да потому что горбатый язык. Мало находится желающих на нем писать.

 >  Как минимум Eserv и Edial или как там его.

Да, целый e-serv... А если я скажу, что спиной вперед никто на машинах не
ездит, ты мне приведешь в пример кого-то, кто из Москвы в Киев так проехал?

 >  Если кто-то узнал о шитом коде только при чтении книг по форту,
 > то это еще не означает, что шитый код появился после появления

Может и после, не суть важно.

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

Очевидно.

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


Re: _Loader_
Hello, Arcady Schekochikhin !

 >> Вообще-то тут обсуждаются преимущественно микроконтролеры, а не персоналки.
 >  Для персоналок писать на форте в голову никому не приходит слава богу.

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

Серьезная часть, ничего не скажешь.

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


Site Timeline