_Loader_

4-Oct-03 07:23 Alex Kouznetsov wrote to Oleksandr Redchuk:

OR>> Я ещё не слышал, что после хорошего С-компилятора программа для OR>> AVR|MCS51|PIC|MSP430 работает быстрее, чем написанная на ассемблере. OR>> Про форт такое слышал. Впрочем, заодно с тем, что "у него ядро 17 байт, OR>> а вот у С!!!!"

AK> придет в голову обычному эмбедеру, настолько же и Форт-система организована AK> в определенном смысле необычно и во многих смыслах эффективно. Никогда с этим не спорил.

AK> Поэтому человеку, AK> незнакомому с принципами работы Форта, тоже в голову не придет писать на AK> ассемблере так, как написан Форт. Хотя вообще говоря его, казалось бы, AK> никто в этом не ограничивает. Имеется ввиду шитый код? Или сразу вместе со стековой машиной :-)? Или ещё с организацией подпрограмм в словарь и с компилятором новых слов на этот словарь? Подпрограммный шитый код я на "СОУ-1" и на "Э-60" применял, ещё не зная ничего про форт. Года за 3 до издания "Баранова-Ноздрунова" и лет за 12 до заглядывания в него. Поэтому я лично не считаю, что если использован шитый код - то это сразу "по мотивам форта". Это естественный способ сэкономить объём, думаю, родился задолго до форта. Просто очень удачно лёг на стековую машину, но если посмотреть на мой asm-модуль работы с I2C из-под КейлC51, то "верхний" слой этого модуля, непосредственно вызывающийся из C, выглядит в духе

_RTCreadCheck: ;;;;;; ; bit RTCreadCheck( void idata *ptr, u8 rtcaddr, u8 len); mov DPH,R3 acall _RTCread ajmp CheckCsum_a

_EEreadCheckParam: ;;;;;;;;;;;;;;; ; bit EEreadCheckParam( u8 paramnum); ; EE_CFG[ee_table[paramnum]] -> union t acall prepare_ee_table _EEreadCheck: ;;;; ; bit EEreadCheck( void idata *ptr, u16 eeaddr, u8 len); mov DPH,R3 ; DPH not changed by I2C functions acall _EEread ; R7 (ptr) not changed in I2C functions ajmp CheckCsum_a

_EEread: ;;;; ; bit EEread( void idata *ptr, u16 eeaddr, u8 len); ; > R7 -> buffer in idata ; R5R4 = hi,lo bytes of address in EEPROM ; R3 = data length ; < C = 1 error acall ee_prepare_addr sjmp i2c_read_block ; это где-то внутри RTCread

_EEwrite: ;;;; ; bit EEwrite( void idata *ptr, u16 eeaddr, u8 len); ; arguments and return value as in EEread acall ee_prepare_addr sjmp i2c_write_block

А внутри i2c_read_block и i2c_write_block вызыается i2c_start_exchange, которая вызывает i2c_start и i2c_put. По сравнению с собственно soft-i2c передачей эти задержки пренебрежимо малы, а код вышел очень компактный, что было важно. Кстати, Баранова-Ноздрунова я читал после того, как сдал этот проект и впервые за несколько лет (перед этим проектом тоже было "давай-давай") спокойно поехал в отпуск не беря с собой схем и распечаток :-)))

Т.е. код шьётся и вне стековой модели, в упомянутом коде регистры как загрузились ещё вызовом из C, так и с минимальными копированиями используются до конца. А с учётом глобальной регистровой оптимизации в кейле и при том, что этот код специально не трогает R7 - указатель на буфер, во многих случаях сгенерённый кейлом код выглядел в духе mov lcall _EEreadCheck jc lcall _OtherFunction без перезагрузки регистров

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

Чтобы "два раза не вставать":

4-Oct-03 04:12 Alex Kouznetsov wrote to Yuriy K:

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

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

Похоже, что я тут вот регулярно пользуюсь форт-калькулятором "Электроника МК61", до этого много работал на форт-калькуляторах Б3-21 и Б3-19. А более серьёзные рассчёты мне выполняет форт-сопроцессор с плавающей запятой в моём атлоне.

IMO: Скомпилированный для "Нейрона" из "Нейрон-C" код выполняется ПРОЦЕССОРОМ СО СТЕКОВОЙ АРХИТЕКТУРОЙ.

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

wbr,

Sat Oct 04 2003 14:53, Oleksandr Redchuk wrote to "Alex Kouznetsov":

OR> Скомпилированный для "Hейрона" из "Hейрон-C" код выполняется OR> ПРОЦЕССОРОМ СО СТЕКОВОЙ АРХИТЕКТУРОЙ.

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

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

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

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

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

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

AK>> Подпрограммный шитый код _ничего_не_компилирует_.

YK> Естественно. Только кто-то должен этот "шитый код" создать. Кто?

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

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

YK> И?

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

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

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

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

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

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

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

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

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

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

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

Тебе лень подумать, или ты правда не понимаешь? Для работы с железом исползуются низкоуровневые слова=операторы=подпрограммы=функции. Но, скажем, нет таких слов, которые могли бы запретить прерывания или обслужить WDT.

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

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

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

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

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

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

Sat Oct 04 2003 13:54, Yuriy K wrote to Lev Serebryakov:

LS>> Коммерческий. Успешно продается.

YK> Сколько штук продано?

Спроси у самой фирмы,

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

4-Oct-03 12:04 Alex Kouznetsov wrote to Oleksandr Redchuk:

OR>> Скомпилированный для "Hейрона" из "Hейрон-C" код выполняется OR>> ПРОЦЕССОРОМ СО СТЕКОВОЙ АРХИТЕКТУРОЙ.

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

AK> А... Опять спор о терминах и приоритетах... "Форт-процессор" и "стековый AK> процессор" - синонимы. Значит всё-таки у меня в атлоне стоит форт-сопроцессор плавающей арифметики... Может ещё и С-компилятор генерит вставки на форте для него?

И тот технологический управляющий контроллер Reliance Electric на рассыпухе 74-ой серии, в котором я копался когда-то (битовый процессор со стековой архитектурой) - тоже "форт-процессор"?

Улёт....

wbr,

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

DO> Hичего, кроме собственно фортов и нескольких мелких программок (какой-то DO> вьювер к interrupt list by Ralf Brown) мне не попадалось, да и те еще во DO> времена 286 машин. Hе сомневаюсь, что отдельные фанаты что-то пишут, но DO> дальше это по большей части распространения не получает.

Мне попадалось: Eserv (сервер, собственно...), nnCron (планировщик для win), еще была некая САПР, уже не помню, чья. Это из более-менее распространенного, причем только то, что само попалось на глаза в инете. Там, где я работаю, что-то около 30 проектов на Форте для разнообразных расчетов и управления установками с помощью PC, а в эхотажных разработках _ничего_, кроме Форта, и нет...

DO> Да и не знать не особо вредно.

Не особо, пока не припечет и грамотный фортер не решит его задачу комплексным подходом, переписав и системное и прикладное ПО.

DO> Речь-то шла о mark4 от Атмела, именно для него в качестве средства DO> программирования Атмел предлагает один из фортовских диалектов.

Не слышал, интересно...

DO> И по невозможности потом во всем этом разобраться, особенно не автору DO> этой системы.

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

DO> Да какая командная строка в четырехразрядном embedded процессоре?

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

DO> Что такое ассемблерный код?

Код, компилируемый ассемблером, надо полагать. :) Однозначное соответствие между мнемонической записью ассемблерных команд и двоичным кодом, располагающимся в памяти программ. Речь об оверхеде, который не делает ассемблер? Компилятор Форта можно скорректировать так, что он тоже не будет его делать. Правда, отказавшись от стековой машины.... или при использовании стека будет оверхед, а без него - нет....

DO> Еще проще ассемблерный код писать на ассемблере.

Скажи пожалуйста, как проще:

mov bx, offset myvar mov ax, word ptr [bx] mov bx, offset another_var mov cx, word ptr [bx] add ax, cx

или

get_myvar get_another_var +

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

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

Вот тебе примерчик, скрипт на Форте. ЭТО нечитаемо???? ==================================================== ПЛОСКОСТЬ Базовая ПРЯМАЯ Прямая1 ПРЯМАЯ Прямая2

УГОЛ МЕЖДУ Прямая1 И Прямая2 БАЗА Базовая НОМИНАЛЬНО 18

+ДОПУСК 0.1

-ДОПУСК -0.1 ====================================================

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). А может и ничего из перечисленного... Это пример несимметричного регистрового набора.

Sat Oct 04 2003 16:37, Roman Khvatov wrote to Artem Kamburov:

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

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

RK> Это всеобщее заблуждение - он сложнее RISC'а, той же производительности. RK> RISC выполняет элементарные операции над регистровым файлом, Форт RK> процессор - над стеком (точнее двумя стеками). То есть Форт процессору, RK> вдобавок к регистровому файлу (который у него будет занят под стек), RK> нужно еще 2 указателя стека, блоки для работы с ними, плюс модификация RK> всех операций с прямоадресуемых (в регистровый файл) на косвенно RK> адресуемые (через указатели стеков). То есть вместо того, что бы прочесть RK> 2 регистра, выполнить операцию и записать результат в 3й регистр, Форт RK> процессор будет вынужден выполнить чтение указателя стека, чтение RK> регистрового файла по полученному адресу, инкремент адреса, чтение 2го RK> операнда по полученному адресу, собственно операцию, запись по косвенному RK> адресу и декремент указателя стека. Так что, по сравнению с RISC RK> процессором, Форт процессор делает много лишнего, а RISC процессор не RK> делает ничего, чего бы не делал Форт процессор. Плюс ко всему этому Форт RK> процессору понадобится поддержка со стороны ОС, для откачки его стеков в RK> память.

Там описание стекового процессора в ПЛИС. Форт-процессора, если угодно. Что интересно, все операции, которые ты перечислил, почему-то делаются за 1 такт... :)

RK> Оговорюсь, что тут сравниваются обычный RISC (не супер скаляр) и обычный RK> Форт (за бессмысленностью супер скалярного Форт процессора)

Да, такая навороченная архитектура для стековой машины действительно бессмысленна. Это для набора регистров надо конвейеризовать, переупорядочивать и следить за зависимостями. Для стека все сводится к последовательному выполнению элементарных операций, вплоть до 1 операции за такт (и обращаю внимание, что больше нельзя в принципе; а если будет разговор про одновременную пересылку в 2 регистра, то давайте тогда уж поставим и 2 стека?)

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

RK> Hи того ни другого не получите :(

Два процессора на той же площади кристалла - это не две задачи?

RK> В реальной системе обычно одновременно исполняется одно приложение, RK> остальные ждут какого либо ввода/вывода. Имеет смысл ориентироваться RK> только на multithreaded приложения - они реально могут использовать RK> несколько процессоров одновременно. Hо для этого приложение должно быть RK> так написано, компиляторы делать из обычных программ multithreaded не RK> умеют (за редким исключением, Форт к таковым не относится :) Кроме того, RK> вместо "обычного" RISC SuperScalar уже засовывают много маленьких RISC RK> процессоров - VLIW называется, что гораздо эффективнее 'многих маленьких RK> Форт процессоров'

А еще есть TTA (H.Corporaal серию работ написал), которая представляет собой дальнейшее развитие VLIW в сторону контроля над микрокодом (фактически, в TTA микрокода уже просто нет). А про стековую разновидность TTA можно почитать у меня на страничке... :)