_Loader_

RK>> Монстры они не из за того, что компилированные :)

IT> Дааа??? :) И Дельфи генерирует hello, world в сотню килобайт, чтобы проверить IT> качество поверхности винчестера? :))))

Интересно, только что написал Writeln('Hello, world!'); и получил размер .exe файла 16384 байт. Много ? :)

IT> Специалист - он всегда специалист. И фразу "только писать надо обязательно на IT> Си" (ассемблере, форте, паскале) от него услышать практически невозможно. Есть IT> разные инструменты, разные подходы и разные критерии их оптимальности. Можно

Это верно, но многие широко используемые языки имеют сходную семантику при небольших различиях в синтаксисе. Форт имеет совсем другую структуру и переключение с него на другой язык (и наоборот) вызывает "некоторые" трудности. Даже в случае Pascal/C, после недели писанины на Дельфи, переход на C-проект приводит к лишним нажатиям клавиш вида: a :=<BS><BS>= :) То же и с ассемблерами разных архитектур, однако заменить их нечем...

IT> Что до того, _что_ именно нужно было сделать, то я скажу так, что каждый IT> коллектив и каждый проект уникальны. Примерять на всех одно и то же - IT> бесполезно по обычным житейским соображениям. Я применил _иные_ подходы, в IT> итоге мне есть о чем поговорить и чем заняться в плане разбора полученных IT> результатов. Се ля ви...

Тоже верно. Лет 10 назад наш сотрудник пробовал писать свою часть проекта на Форте. Мы с интересом к этому отнеслись, и ему было выделено время на адаптацию имеющегося компилятора к процессору... Все закончилось тем, что мне пришлось выполнить его работу на ассемблере.

Hi Roman,

Mon Oct 13 2003 23:07, Roman Khvatov wrote to Alex Kouznetsov:

IT>>>> А прямое соответствие конструкций высокого уровня машинному коду IT>>>> не лучше?

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

AK>> Для меня то что ты говоришь - не очевидно.

RK> Что именно? Что процессоры идут по пути упрощения? Это очевидно - RK> CISC,RISC(SuperScalar),VLIW Или что компиляторы усложняются? - Это RK> следствия п1

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

...

AK>> Если эти последовательности команд подчинены определенной логике, а AK>> именно - образуют Форт-процессор,

RK> Hет. Они не образуют Форт процессор.

Я знаю, что существующие компиляторы С не используют Форт-процессор. Я говорю что так можно было бы сделать. Т.е. можно было бы писать компилятор так, чтобы он транслировал код для (виртуального) Форт-процессора.

RK> Современные компиляторы строятся из 3х частей (в основном): RK> 1) Front-End. Разбирает исходные тексты программы и генерирует RK> промежуточное представление. Обычно это представление на основе какой RK> либо разновидности деревьев. RK> 2) Оптимизатор. Работает на промежуточном представлении п1, практически RK> не вдаваясь в детали устройства целевой платформы. Выполняет общие RK> платформо независимые оптимизации, такие как: RK> Вынесение общих подвыражений RK> Упрощение операций RK> Подстановка констант и присваиваний RK> Различные преобразования циклов RK> и пр

Это можно оставить (почти) таким как есть.

RK> 3) Кодогенератор. Преобразует промежуточное представление к код целевого RK> процессора. Выполняет все машинно зависимые оптимизации, их тоже довольно RK> много.

Целевым процем может быть FVM. Оптимизацию для SPF компилятора делал Михаил Максимов, так что опыт существует, и результаты тоже есть.

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

Tue Oct 14 2003 11:05, Boris Popov wrote to Ilia Tarasov:

IT>> Дааа??? :) И Дельфи генерирует hello, world в сотню килобайт, чтобы IT>> проверить качество поверхности винчестера? :))))

BP> Интересно, только что написал Writeln('Hello, world!'); и получил BP> размер .exe файла 16384 байт. Много ? :)

Форт для ДОС - 243 байта :)

Не в размере дело... точнее, не только в нем. Системы программирования создаются с прицелом на решение некоторого класса задач. От того, что RAD закрывает много задач в программировании для PC, он не становится автоматически удобным инструментом для эхотага.

BP> Это верно, но многие широко используемые языки имеют сходную BP> семантику при небольших различиях в синтаксисе. Форт имеет совсем другую BP> структуру и переключение с него на другой язык (и наоборот) вызывает BP> "некоторые" трудности. Даже в случае Pascal/C, после недели писанины BP> на Дельфи, переход на C-проект приводит к лишним нажатиям клавиш вида: BP> a :=<BS><BS>= :) То же и с ассемблерами разных архитектур, однако BP> заменить их нечем...

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

BP> Тоже верно. Лет 10 назад наш сотрудник пробовал писать BP> свою часть проекта на Форте. Мы с интересом к этому отнеслись, и ему BP> было выделено время на адаптацию имеющегося компилятора к процессору... BP> Все закончилось тем, что мне пришлось выполнить его работу на ассемблере.

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

OR>> Ведь "защитный диод на входе" это абстракция. Hа самом-то деле OR>> там выходит нечто похитрее и часть тока так или иначе уйдёт OR>> не в вывод VCC а пойдёт гулять и уйдёт оно в подложку или OR>> всосётся в переход "защитного диода" на соседней ноге -- вопрос.

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

OR>> Как прекрасно уходило напряжение на выходе 4051, когда на OR>> _невыбранные_ входы поступало 12В....

VB> Хм... Hевыбранный вход по схемотехнике такой же (те же диоды), но только VB> ты его не подсаживаешь через выход. И как бы всё лишнее должно было уйти через защитный диод в VCC.

VB> И что, при этом 4051 питался от тех же внутренних 5 вольт ? Да.

VB> А какого порядка было изменение на выходе ? Такие вещи я VB> стараюсь запоминать на будущее... 50-70mV, до 100 если на многих входах было 12V. Специально как следует всё проверил. За неимением под рукой вместо 4v7 сначала были поставлены нашедшиеся КС139, но их утечка при 2V сильно всё портила. Потом таки было сбегано на базар и всё заменено на 4v7.

VB> P.S. А вообще за этими 405x нужен глаз да глаз - было дело, нарвался,

VB> отечественные 561КП2). До тех пор, пока мы не получили моторольские. "вы будете смеяться", но то тоже были моторльские :-)

wbr,