_Loader_

Hi Oleksandr,

Fri Oct 03 2003 00:05, Oleksandr Redchuk wrote to "Alex Kouznetsov":

OR> Я ещё не слышал, что после хорошего С-компилятора программа для OR> AVR|MCS51|PIC|MSP430 работает быстрее, чем написанная на ассемблере.

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

Граница, на которой человек "сломается", и на "голом" ассемблере уступит хорошему оптимизирующему компилятору, для каждого человека своя, но для каждого она существует, имхо. Поэтому я не стал бы разделять выч. технику по принципу "два мира - две системы", с моей точки зрения, то, что верно для пней (вроде бы все согласились, что для пней это верно?), _вообще_говоря_ не теряет своей силы даже небольших процев. То есть, всегда можно найти человека, который даже сравнительно небольшую программу на ассемблере напишет хуже чем то, что выдаст хороший оптимизирующий компилятор ;-)

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

OR> ассемблерррррррщиков, котороые ведут себя как форррррррррррррррртеры

Я вот все решить не могу, как правильнее называть тех, кто все без исключения пишет на Си: наСильщик или наСильник? ;-)

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

Hello, Sergey Brylew !

HÅ ×ÉÖÕ Ó×ÑÚÉ. ðÏ-Ô×ÏÅÍÕ, ÐÒÏÇÒÁÍÍÁ × 4Ë ÓÂÏÉÔ ×Ä×ÏÅ ÞÁÝÅ ÐÒÏÇÒÁÍÍÙ × 2Ë?

:)

HÕ Á Ñ embedded ÐÒÏÇÒÁÍÍÙ, × ÔÏÍ ÞÉÓÌÅ É ÄÌÑ ÂÏÌØÛÏÊ ÓÅÒÉÉ ÐÉÛÕ ÎÁ ó, ÉÎÏÇÄÁ Ó ÎÅÂÏÌØÛÉÍÉ ÁÓÓÅÍÂÌÅÒÎÙÍÉ ×ÓÔÁ×ËÁÍÉ. äÅÌÏ ×ËÕÓÁ ÐÏ ÂÏÌØÛÏÍÕ ÓÞÅÔÕ.

Fri Oct 03 2003 08:48, Sergey Brylew wrote to Dmitry Orlov:

DO>> þÔÏ ÏÄÉÎ É ÔÏÔ ÖÅ ÐÒÏÇÒÁÍÍÉÓÔ ÐÉÛÅÔ ÎÁ ó (ÅÓÌÉ ÜÔÏ ÓÉÛÎÙÅ ËÏÍÐÉÌÑÔÏÒÙ) DO>> ÌÕÞÛÅ ÞÅÍ ÎÁ ÁÓÓÅÍÂÌÅÒÅ ÎÉËÏÇÏ ÎÅ ÕÄÉ×ÌÑÅÔ, ÂÏÌÅÅ ÔÏÇÏ, ÄÌÑ ÓÏ×ÒÅÍÅÎÎÙÈ DO>> ÁÒÈÉÔÅËÔÕÒ É ÂÏÌØÛÉÈ ÐÒÏÇÒÁÍÍ ÜÔÏ ÅÓÔÅÓÔ×ÅÎÎÏ.

SB> ðÒÏÇÒÁÍÍÉÓÔÙ ÂÙ×ÁÀÔ ÒÁÚÎÙÅ. õ ÂÅÓÔÏÌËÏ×ÏÇÏ ÐÒÏÇÒÁÍÍÅÒÁ ÍÏÖÅÔ ÂÙÔØ SB> ÌÀÂÏÅ ÓÏÏÔÎÏÛÅÎÉÅ ÄÌÉÎÙ ËÏÄÁ ÐÒÉ ÉÓÐÏÌØÚÏ×ÁÎÉÉ ÒÁÚÎÙÈ ËÏÍÐÉÌÑÔÏÒÏ×. ðÒÉ SB> ÎÏÒÍÁÌØÎÏÍ ÐÏÄÈÏÄÅ ÄÌÉÎÁ ËÏÄÁ ÎÁ ÁÓÓÅÍÂÌÅÒÅ ×ÓÅÇÄÁ ÂÕÄÅÔ ÎÅ ÂÏÌØÛÅ, ÞÅÍ SB> ÎÁ ó.

HÅÔ. úÁ×ÉÓÉÔ ÏÔ ÒÁÚÍÅÒÁ ÐÒÏÇÒÁÍÍÙ, ÐÒÏÃÅÓÓÏÒÁ É ËÏÍÐÉÌÑÔÒÏÒÁ.

SB> ðÏÓËÏÌØËÕ ËÔÏ ÍÎÅ ÐÏÍÅÛÁÅÔ ÎÁÐÉÓÁÔØ ÎÁ ÁÓÍÅ ÔÏ, ÞÔÏ ÎÁËÏÍÐÉÌÉÒÏ×ÁÌ ó?

HÅÓÐÏÓÏÂÎÏÓÔØ ÏÄÏ×ÒÅÍÅÎÎÏ ÄÅÒÖÁÔØ × ÕÍÅ ÂÏÌØÛÏÅ ÞÉÓÌÏ ÓÕÝÎÏÓÔÅÊ É ÎÉÚËÁÑ ÓËÏÒÏÓÔØ ÐÏÉÓËÁ.

SB> á ×ÏÔ ÎÁÓÞÅÔ ÓÏ×ÒÅÍÅÎÎÙÈ ÁÒÈÉÔÅËÔÕÒ É ÂÏÌØÛÉÈ ÐÒÏÇÒÁÍÍ × ÐÒÉÌÏÖÅÎÉÉ Ë SB> ÜÈÏÔÁÇÕ, ÔÁË ÂÏÌØÛÏÊ ÐÒÏÇÒÁÍÍÅ - ÂÏÌØÛÏÊ ÓÂÏÊ. ðÏÞÅÍÕ-ÔÏ ÚÄÅÓØ Ï ÜÔÏÍ SB> ÎÉËÔÏ ÎÉ ÓÌÏ×Á.

SB> äÌÑ ÐÒÏÇÒÁÍÍÙ, ÒÁÂÏÔÁÀÝÅÊ × ÇÁÄËÉÈ ÕÓÌÏ×ÉÑÈ, Õ×ÅÌÉÞÅÎÉÅ ÏÂßÅÍÁ = SB> ÐÏ×ÙÛÅÎÉÅ ×ÏÚÍÏÖÎÏÓÔÉ ÓÂÏÑ.

HÅÔ. ïÂßÅÍ != ÓÌÏÖÎÏÓÔØ.

WBR, àÒÉÊ.

Hello everybody.

OR> üÔÏ ÏÔÄÅÌØÎÊ ÒÁÚÇÏ×ÏÒ. OR> "üÔÏ" - ÜÔÏ ÔÏ, ÞÔÏ ÄÌÑ ÓÏ×ÒÅÍÅÎÎÙÈ ÐÒÏÃÅÓÓÏÒÏ× Ó ÎÅÓËÏÌØËÉÍÉ ÉÓÐ. OR> ÕÓÔÒÏÊÓÔ×ÁÍÉ, ÐÅÒÅÉÍÅÎÏ×ÁÎÉÅÍ ÒÅÇÉÓÔÒÏ×, out of order ÉÓÐÏÌÎÅÎÉÅÍ É OR> Ô.Ð. ÎÁ ÁÓÍÅ ÒÕÞËÁÍÉ ÔÑÖÅÌÏ ×ӣ ÕÞÅÓÔØ É _ÈÏÒÏÛÉÊ_ ËÏÍÐÉÌÑÔÏÒ ñ÷õ

PicoJava ÔÏÖÅ ÓÕÐÅÒÓËÁÌÑÒ, ÎÏ × ÎÅÊ ×ÓÅ ÏÂÓÔÏÉÔ ÇÏÒÁÚÄÏ ÈÕÖÅ - ÔÁË ËÁË Java VM ÜÔÏ ÓÔÅËÏ×ÁÑ ÍÁÛÉÎÁ (ËÁË É æÏÒÔ, ËÓÔÁÔÉ), É ×ÓÅ ÏÐÅÒÁÃÉÉ ×ÙÐÏÌÎÑÀÔÓÑ ÎÁÄ ×ÅÒÈÕÛËÏÊ ÓÔÅËÁ, ÔÏ ÐÒÁËÔÉÞÅÓËÉ _×ÓÅ_ ËÏÍÁÎÄÙ ÏËÁÚÁÌÉÓØ ÚÁ×ÉÓÉÍÙ ÐÏ ÄÁÎÎÙÍ, É ÞÉÓÌÏ ÏÄÎÏ×ÒÅÍÅÎÎÏ ÉÓÐÏÌÎÑÅÍÙÈ ËÏÍÁÎÄ ÕÐÁÌÏ ÐÒÁËÔÉÞÅÓËÉ ÄÏ 1 (ÔÏ ÅÓÔØ ×ÓÑ ÓÕÐÅÒÓËÁÌÑÒÎÏÓÔØ ÒÁÂÏÔÁÔØ ÐÅÒÅÓÔÁÌÁ).

Roman

Hello, Artem Kamburov !

Hello, Artem Kamburov !

Fri Oct 03 2003 20:53, Roman Khvatov wrote to All:

RK> Есть такая фирма, Sun называется, и пыталась она сделать Java процессор RK> (что бы байткод от Java VM был ее машинным кодом), и сделала - PicoJava RK> назывался. Делался он на той же технологии, что и UltraSparc II. В RK> результате, один и тот же Java байткод на PicoJave исполнялся в несколько RK> раз _медленнее_, чем тот же код на UltraSparc II на JIT'е :(

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

RK> Разбор полетов выявил причину - UltraSparc II супер скалярный процессор, RK> то есть он пытается загрузить сразу несколько команд и исполнять их в RK> параллель. Очевидно это можно сделать только для независимых команд, в RK> частности тех, которые не связаны по используемым регистрам. Компиляторы RK> (в том числе и JIT) об этом знают, и стараются расположить команды так, RK> что бы процессор мог загрузить максимальное количество команд.

RK> PicoJava тоже суперскаляр, но в ней все обстоит гораздо хуже - так как RK> Java VM это стековая машина (как и Форт, кстати), и все операции RK> выполняются над верхушкой стека, то практически _все_ команды оказались RK> зависимы по данным, и число одновременно исполняемых команд упало RK> практически до 1 (то есть вся суперскалярность работать перестала).

Абсолютно верно!

RK> Это не значит, что нельзя аппаратно распараллелить операции со стеком, RK> это лишь значит, что затраты аппаратуры на такое распараллеливание RK> превысят затраты аппаратуры на само ядро процессора - спрашивается, RK> нафига это надо? Сделать обычный RISC SuperScalar будет гораздо проще, а RK> производительность будет той же.

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

Fri Oct 03 2003 23:14, Artem Kamburov wrote to Roman Khvatov:

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

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

AK> Я могу Вам предложить более простое решение - т.к. сам форт-процессор AK> достаточно прост, засуньте в ресурсы этого "обычного" RISC SuperScalar AK> несколько маленьких форт-процессоров (возможно частичное перекрытие AK> ресурсов) - каждый с собственным потоком команд. Получите реальную AK> многозадачность и реальное быстродействие :).

В ПЛИС - уже :) Суперскаляру там делать явно нечего - не те ресурсы. А вот форт-процессор(ы) там чувствуют себя прекрасно.

Hello, Ilia Tarasov !

HÉÞÅÇÏ, ËÒÏÍÅ ÓÏÂÓÔ×ÅÎÎÏ ÆÏÒÔÏ× É ÎÅÓËÏÌØËÉÈ ÍÅÌËÉÈ ÐÒÏÇÒÁÍÍÏË (ËÁËÏÊ-ÔÏ ×ØÀ×ÅÒ Ë interrupt list by Ralf Brown) ÍÎÅ ÎÅ ÐÏÐÁÄÁÌÏÓØ, ÄÁ É ÔÅ ÅÝÅ ×Ï ×ÒÅÍÅÎÁ 286 ÍÁÛÉÎ. HÅ ÓÏÍÎÅ×ÁÀÓØ, ÞÔÏ ÏÔÄÅÌØÎÙÅ ÆÁÎÁÔÙ ÞÔÏ-ÔÏ ÐÉÛÕÔ, ÎÏ ÄÁÌØÛÅ ÜÔÏ ÐÏ ÂÏÌØÛÅÊ ÞÁÓÔÉ ÒÁÓÐÒÏÓÔÒÁÎÅÎÉÑ ÎÅ ÐÏÌÕÞÁÅÔ.

PS HÏ ÄÁÖÅ ÅÓÌÉ ÂÙ ×ÓÅ ÓËÁÚËÉ Ï ÎÅ×ÅÒÏÑÔÎÏÊ ÜÆÆÅËÔÉ×ÎÏÓÔÉ ÆÏÒÔÁ ÂÙÌÉ ÐÒÁ×ÄÏÊ, Ñ ÂÙ ×ÓÅ ÒÁ×ÎÏ ×ÙÖÉÇÁÌ ÅÇÏ ËÁÌÅÎÙÍ ÖÅÌÅÚÏÍ ÚÁ ÁÂÓÏÌÀÔÎÕÀ ÎÅÞÉÔÁÂÅÌØÎÏÓÔØ ÔÅËÓÔÏ× ÎÁ ÎÅÍ ÎÏÒÍÁÌØÎÙÍ ÞÅÌÏ×ÅËÏÍ. åÓÌÉ Ï ó ÎÅ ÂÅÚ ÏÓÎÏ×ÁÎÉÑ ÇÏ×ÏÒÑÔ ËÁË Ï write only ÑÚÙËÅ, ÔÏ Ë ÆÏÒÔÕ ÜÔÏ ÐÒÉÍÅÎÉÍÏ ÔÙÓÑÞÅËÒÁÔÎÏ.

Fri Oct 03 2003 22:41, Dima Orlov wrote to Artem Kamburov:

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

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

DO> Думаю, что ни к чему, да и массовостью Атмелу не приходится хвастаться. DO> Это не Моторола, не Микрочип и даже не ST. Впрочем для четырехбитных DO> процессоров может форт и даст приемлимый результат, говорить о DO> производительности тут явно не приходится.

Не скажу про ASIC, а в ПЛИС Форт-процессору самое место. От 8 до 32 разрядов, производительность вполне приемлемая для эмбеддед.

(Я даже не касаюсь вопроса поддержки софт-ядер на Си и вообще ЯВУ. По оперативности внесения изменений в системный софт Форт вне конкуренции)

DO> Есть там компилятор с языка Форт.

btw, встроенный в интерпретатор командной строки. Что касается собственно компиляции, то получить код, ПОЛНОСТЬЮ идентичный ассемблерному, на Форте довольно просто.

(скипнул многое, с чем в принципе согласен)

Sat Oct 04 2003 00:15, Artem Kamburov wrote to Yuriy K:

AK> çÌÕÂÉÎÏÊ ×ÌÏÖÅÎÉÑ É ÞÁÓÔÏÔÏÊ ÉÓÐÏÌØÚÏ×ÁÎÉÑ.

AK> á óÉ ÓÏ Ó×ÏÉÍÉ ÆÕÎËÃÉÑÍÉ AK> ×ÏÏÂÝÅ ÐÏÓÔÕÐÁÅÔ ËÁË ÅÍÕ ÎÒÁ×ÉÔÓÑ (ÞÁÝÅ ÉÎÌÁÊÎÉÔ × ÍÅÓÔÏ ×ÙÚÏ×Á).

HÅÔ. ïÚÎÁËÏÍØÓÑ ×ÓÅ ÖÅ Ó ÐÏ×ÅÄÅÎÉÅÍ ËÏÍÐÉÌÑÔÏÒÏ× ó. ëÓÔÁÔÉ, Ï ËÁËÏÍ ÉÍÅÎÎÏ ËÏÍÐÉÌÑÔÏÒÅ ó É ÄÌÑ ËÁËÏÇÏ ÐÒÏÃÅÓÓÏÒÁ ÔÙ ÒÁÓÓËÁÚÙ×ÁÅÛØ?

AK> éÎÔÅÒÐÒÉÔÁÔÏÒ ÔÏ ÖÅ ÚÁÇÒÕÖÁÅÔÓÑ ÔÏÌØËÏ ÏÄÉÎ ÒÁÚ - ÐÒÉ ÐÅÒ×ÏÍ ×ÙÚÏ×Å :).

AK> á ÐÏ-ÔÏÞÎÅÅ ÍÏÖÎÏ - ÞÔÏ Ñ ÕÐÕÓÔÉÌ?

AK> ëÁÖÄÙÊ ÇÏÄ ÁÐÇÒÅÊÔ ÖÅÌÅÚÁ ÂÅÚ ÒÅÁÌØÎÏÇÏ Õ×ÅÌÉÞÅÎÉÑ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ AK> (ÐÒÏÓÔÏ ÎÁ ÓÔÁÒÏÍ ×ÓÅ ÓÔÁÎÏ×ÉÔÓÑ ÎÕ ÏÞÅÎØ ÍÅÄÌÅÎÎÙÍ).

"People who think they know everything really irritate those of us who do"

WBR, àÒÉÊ.

Sat Oct 04 2003 01:04, Dima Orlov wrote to Ilia Tarasov:

DO> PS HÏ ÄÁÖÅ ÅÓÌÉ ÂÙ ×ÓÅ ÓËÁÚËÉ Ï ÎÅ×ÅÒÏÑÔÎÏÊ ÜÆÆÅËÔÉ×ÎÏÓÔÉ ÆÏÒÔÁ ÂÙÌÉ DO> ÐÒÁ×ÄÏÊ, Ñ ÂÙ ×ÓÅ ÒÁ×ÎÏ ×ÙÖÉÇÁÌ ÅÇÏ ËÁÌÅÎÙÍ ÖÅÌÅÚÏÍ ÚÁ ÁÂÓÏÌÀÔÎÕÀ DO> ÎÅÞÉÔÁÂÅÌØÎÏÓÔØ ÔÅËÓÔÏ× ÎÁ ÎÅÍ ÎÏÒÍÁÌØÎÙÍ ÞÅÌÏ×ÅËÏÍ. åÓÌÉ Ï ó ÎÅ ÂÅÚ DO> ÏÓÎÏ×ÁÎÉÑ ÇÏ×ÏÒÑÔ ËÁË Ï write only ÑÚÙËÅ, ÔÏ Ë ÆÏÒÔÕ ÜÔÏ ÐÒÉÍÅÎÉÍÏ DO> ÔÙÓÑÞÅËÒÁÔÎÏ.

WBR, àÒÉÊ.

Hi Roman,

Fri Oct 03 2003 20:53, Roman Khvatov wrote to All:

RK> Кстати, по поводу современных процессоров и Форт процессоров есть одно RK> любопытное наблюдение:

RK> Есть такая фирма, Sun называется, и пыталась она сделать Java процессор RK> (что бы байткод от Java VM был ее машинным кодом), и сделала - PicoJava RK> назывался. Делался он на той же технологии, что и UltraSparc II. В RK> результате, один и тот же Java байткод на PicoJave исполнялся в несколько RK> раз _медленнее_, чем тот же код на UltraSparc II на JIT'е :(

Ссылочку не дашь, где про это можно прочитать?

RK> Разбор полетов выявил причину - UltraSparc II супер скалярный процессор, RK> то есть он пытается загрузить сразу несколько команд и исполнять их в RK> параллель. Очевидно это можно сделать только для независимых команд, в

На

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

RK> PicoJava тоже суперскаляр, но в ней все обстоит гораздо хуже - так как RK> Java VM это стековая машина (как и Форт, кстати), и все операции RK> выполняются над верхушкой стека, то практически _все_ команды оказались RK> зависимы по данным, и число одновременно исполняемых команд упало RK> практически до 1 (то есть вся суперскалярность работать перестала).

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

Ты ничего не путаешь, разве PicoJava - это суперскаляр, расходующий столько же кремния как UltraSparc II (5.4 млн транзисторов, если не ошибаюсь)? Насколько я знаю, это сравнительно маленький проц (примерно такого же класса как ARM), заточенный на встраиваемые применения:

-- Digital set-top boxes

-- Internet TVs

-- Internet screen phones

-- Automotive communications devices

Поэтому сравнивать его производительность с UltraSparc II, предназначенным для WorkStations, по крайней мере странно, это примерно то же что AVR сравнивать с пнем. Еще более странно делать какие-то выводы на основе такого сравнения.

RK> Это не значит, что нельзя аппаратно распараллелить операции со стеком, RK> это лишь значит, что затраты аппаратуры на такое распараллеливание RK> превысят затраты аппаратуры на само ядро процессора - спрашивается, RK> нафига это надо? Сделать обычный RISC SuperScalar будет гораздо проще, а RK> производительность будет той же.

Твое утверждение, что "затраты аппаратуры на такое распараллеливание превысят затраты аппаратуры на само ядро процессора" - совершенно безосновательно.

Есть такие чипы Нейрон, выпускаемые уже десятка полтора лет. Они являются основой сети LonWorks фирмы Echelon. Так вот, они сделаны именно так: это

Эшелон с понтом вешает лапшу на уши, что внутри Нейрона 3 процессора, на на самом деле процессор один, за полный цикл просто 3 раза переключаются указатели стеков. Поскольку стековому процессору не надо сохранять контекст, то такое переключение не требует времени. Затраты аппаратуры на 3 набора указателей стеков и мультиплексоры для их переключения мизерны и даже просто смехотворны на фоне остальной аппаратуры ЦПУ. Так что не надо пургу гнать ;-)

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

Hi Yuriy,

Sat Oct 04 2003 05:37, Yuriy K wrote to Dima Orlov:

DO>> PS Hо даже если бы все сказки о невероятной эффективности форта были DO>> правдой, я бы все равно выжигал его каленым железом за абсолютную DO>> нечитабельность текстов на нем нормальным человеком. Если о С не без DO>> основания говорят как о write only языке, то к форту это применимо DO>> тысячекратно.

YK> Именно! Программа должна быть сопровождаемой. Причем через два года и YK> другим программистом.

Не надо смешивать разные понятия в одну кучу. До сих пор в треде шла речь об эффективности работы интерпретатора. Было показано, что т.н. "внутренний интерпретатор", используемый Фортом (т.е. виртуальный Форт-процессор, или FVM, или стековый процессор), обладает интересными свойствами. В частности, один из способов его реализации - подпрограммный шитый код - не уступает по производительности коду, сгенерированному (неплохим) компилятором Си, или написанному не особо старательным программистом на ассемблере.

Этот факт к языку программирования никак не относится. Каким образом будет создаваться код для такого интерпретатора - не имеет значения. Если написать просто ассемблер для FVM, это будет ассемблер FVM. Если этот ассемблер улучшить, причесать, и превратить в ЯВУ - будет Форт, или ДССП, или что-то похожее. Если приделать соответствующий бэк-энд к gcc - будет Си. И т.д.

Например, стековый процессор Нейрон, о котором я упоминал, в качестве фронт-энда использует компилятор Си. Тем не менее, сгенерированный им код исполняется Форт-процессором.

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

Hello, Alex Kouznetsov !

HÅ ÆÏÒÔ-ÐÒÏÃÅÓÓÏÒÏÍ, Á ÓÔÅËÏ×ÏÊ ÍÁÛÉÎÏÊ.