Microsoft Research подтверждает преимущество Линукс

а в чем проблемма с проверками есть ассемблерные инструкции
bound и т.д.,
так что...

Смачно ты в лужу пукнул...

Какие нах структуры - базар про проверку границ массивов и строк. Которая НИЧЕГО не стоит начиная с первого пня без MMX.

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

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

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

Сделали же они автодополнение по [Tab]( правда, и то коряво) !! :-)

> Имхо проще проверить сам компилятор (чтоб он однозначно правильно генерил код), чем проверять ассемблерные инструкции в КАЖДОЙ программе, им скомпилированной.

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

К тому же, ты ваааащще не понял. Проверяется в любом случае сама "КАЖДАЯ" программа - на предмет соотвествия спецификации (собственной и интерфейсов ОС). А проверять "типизированный ассемблер" сильно проще, чем C#.

> >реально используются (а не весь объектный архив, как при статической компиляции в существующих системах)

> Кто вам такое сказал???

$ cat hw.c

#include <stdio.h>

int main() {puts("Hello, world!"); return 0;}

$ gcc -static -o hw hw.c

$ nm hw | wc -l

1782

Ну да, я слегка нагнал - не архив, а объектник из него. Но это дела не меняет - если бы я компилял это "правильным" компилятором, в бинаре бы остались, скажем, определения только тех системных вызовов, которые он делает в коде. И nm писал бы строчек 15-20, а размер бинаря был бы кила 2. Как с dietlibc.

$ diet gcc -static -o hw_diet hw.c

$ ls -l hw_diet

-rwxrwxr-x 1 xxx yyy 2070 Nov 10 18:45 hw_diet

$ nm hw_diet | wc -l

27

Речь о том ассемблере, который будет рожать этот Sing# - автоматически проверять который якобы будет проще, чем исходники

>А проверять "типизированный ассемблер" сильно проще, чем C#.

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

$ diet gcc -static -o hw_diet hw.c $ ls -l hw_diet -rwxrwxr-x 1 xxx yyy 2070 Nov 10 18:45 hw_diet $ nm hw_diet | wc -l 27

Ну и о чём это говорит? А если проще:

$ nm hw_diet

Посмотреть (а не просто поччитать строки) и увидеть, что присутствуют символы только те, которые использует puts и неявный exit? Где там весь объектник?

$ strip -s hw_diet

даст размер 796 байт - где вы видели такой "весь объектник"?:)

Led, млин, ты вообще читать умеешь, или тупо флеймишь?

>>А проверять "типизированный ассемблер" сильно проще, чем C#.

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

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

> Ну и о чём это говорит?

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

$ ar t /usr/lib/dietlibc/lib-i386/libc.a | wc -l

629

ls -la /usr/lib/dietlibc/lib-i386/libc.a

-rw-r--r-- 1 root root 615436 May 26 18:21 /usr/lib/dietlibc/lib-i386/libc.a

Т.е. по килобайту на объектник, в среднем. Нестрипанный. Ы? Если посмотреть на их имена, мы это увидим еще отчетливее, по объектнику на функцию:

fwrite.o printf.o putchar.o puts.o scanf.o

Еще рекомендую посмотреть на /sbin/ FreeBSD 4.х: размер самых тривиальных программ, типа kget - >50Kb. Притом что их же, собранных динамически - меньше 5.

>>Что мешает положить тот же вирус в этот "объектник"? Пусть в этот установщик они положат СВОЙ антивирус и антируткит, но! Всегда же выходят вирусы, которые не находят антивирусы.

Для тех кто в такне! Софт проверяется не на вирусы, а на валидность работы с памятью.

>Это не скомпилируется.

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

Сейчас линуксоиды будут говорить что в одной части доклада врут, а в другой - говорят правду...

Что за бред???
Ну, ОК. Исключтельно для безмозглых онанистов промоделируем ситуацию.

Предположим, задача "работа с последовательным портом".

На Си: 3 функции: инициализация, прием, передача. ЭТО ВСЁ.

На объектных языках (C++, JAVA, C# и прочая поебень):
объект COMPORT, состоящий из нескольких промежуточных переменных, функции инициализации, функции получения данных, функции передачи данных, функции проверки четности и т. д.

Внимание вопрос, дорогой онанист, ЧТО проще? И ЧТО требует меньше ресурсов (памяти и процессора)?

Так, ты, тупорылое жывотное из мудацкого городишки Подоньска, читай внимательнее и ещё раз: компактифицирующий GC снижает количество кэш-промахов.

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

И про объекты - не надо тяффкать, тупое жывотное. Безграмотен ты, сучонок, а безграмотным тяффкать не полагается. Про static-методы и поля жывотинушко не слышало, да?

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

Луговский, уежище, ты решил опять на год сгинуть? Смотри, такими темпами годам к 40 в твоем изъеденном глистами организме не останется целой ни одна косточка.
Теперь оцениваем твой высер:

"на Java, где они будут строго последовательно"
Никогда такого небыло. Память, как и дисковое пространство, дефрагментированы: что-то появляется, что-то исчезает. Так что найти "строго последовательный буфер" для данных - задача весьма близкая к идеалу и очень отдаленная от суровой действительности.

"static-методы и поля"
Умгу. Наш герой Луговский предлагает для каждого чиха полностью glibc линковать. Сколько там статический "Hello World" весит? 400К? Уебок Луговский предлагает самый идиотский способ распределения оперативной памяти, который когда-либо видел этот бренный мир.

"жывотному из Подоньска надо убить себя об стену"
Жывотному Луговскому надо бы со мной встретиться в реале, дабы вопрос о продолжении существования жывотного Луговского был решен раз и навсегда путем погребения жывотного Луговского. Заживо.

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

И что такое static-методы сучка из Подоньска не знает, спутало со статической линковкой (во долбоёб! это ж надо так пиздануться!). Объясняю для долбоёбов - static-метод - это ровно то же самое, что функция в Си, static-поле - это глобальная переменная в Си. Всосало, ничтожество? Теперь изволь убить себя об стену, гандон.

Ха-ха-ха, R00T опять обосрался, на всеобщее посмешище себя выставил. Ржунимагу!

>Софт проверяется не на вирусы, а на валидность работы с памятью.

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

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

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

>"static-методы и поля" Умгу. Наш герой Луговский предлагает для каждого чиха полностью glibc линковать. Сколько там статический "Hello World" весит? 400К?

Елки-палки, вот такие вот "специалисты" и кричат о том, что мол С --- это круто, а С++ --- ацтой.... :/

Гораздо честнее было просто сказать: "Я полный НОЛЬ в С++, поэтому КОНКРЕТНО Я лучше пишу на С, чем на С++"....

Древний спор ... программистов системщиков и программистов прикладников :) IMHO Просто смотрят на реализацию задачи с разных сторон.

> Так я не пойму, что мешает софту собрать программу в памяти и каким-либо образом ее запустить?

продемонстрируй это на linux хотябы :))
c добавленными секюрити патчами к ядру :))

в .net нет способа выполнить произвольный код, просто нет
только через создание сборки и загрузки ее в домен

так что получеется, в сингулярности
1) code сегмент приложения всегда readonly
2) исполнить можно только code segment
3) исполнить то о чем система не знает, принципиально невозможно

еще раз напоминаю - процессы защищены друг от друга

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

С этим не спорил:)

>А семантика "типизированного асемблера" сильно проще, чем C#

Могу согласиться только с тем, что семантика какого-то примитивного ассемблера может быть и проще, чем сематика "недоязыка" C#. Вот только проверять код на MIPS-ассемблере (например) намного сложнее, чем на Modula-2/3 с парой десятков зарезервированных слов языка, или, скажем, на Forth с полсотней "разрешённых" слов. Хотя... удачи! Можете взять "брошурку" по MIPS-ассемблеру (на 1000 страниц) - проверяйте:)

>Еще рекомендую посмотреть на /sbin/ FreeBSD 4.х: размер самых тривиальных программ, типа kget - >50Kb

Не передёргивайте: kget - на C++.:)

>Т.е. по килобайту на объектник, в среднем. Нестрипанный. Ы?

А теперь смотрим сюда:

$ ls -l /usr/lib/libc.a

-rw-r--r-- 1 root root 2595894 Ноя 9 03:33 /usr/lib/libc.a

[led@led led]$ ar t /usr/lib/libc.a | wc -l

1312

Менее 2k на объектник в среднем. Ы?:) О чём это говорит? Это вам, студент, домашнее задание - разобраться, почему "средний размер объектника" различается в 2 раза, размер ститического бинарника - почти в 500 раз, и почему этот ваш "довод" в данном случае "не канает":)

Блин, Led, ты - идиот.

> >А семантика "типизированного асемблера" сильно проще, чем C#

> Могу согласиться только с тем, что семантика какого-то примитивного ассемблера может быть и проще, чем сематика "недоязыка" C#. Вот только проверять код на MIPS-ассемблере (например) намного сложнее, чем на Modula-2/3 с парой десятков зарезервированных слов языка, или, скажем, на Forth с полсотней "разрешённых" слов. Хотя... удачи! Можете взять "брошурку" по MIPS-ассемблеру (на 1000 страниц) - проверяйте:)

Еще раз повторяю, ты - идиот. Ты понимаешь, что такое "типизированный ассемблер"? Ти-пи-зи-ро-ван-ный. Ты вообще понимаешь, что язык ассемблера может быть не привязан к железу? Но при этом тривиально (вплоть до подстановки по таблице) транслироваться в машинный код? Или ты не веришь, что байткод JVM, CLR или Parrot - это тоже асссемблер?

> >Еще рекомендую посмотреть на /sbin/ FreeBSD 4.х: размер самых тривиальных программ, типа kget - >50Kb

> Не передёргивайте: kget - на C++.:)

kget - это такая программка из FreeBSD, которая спрашивает у ядра какие-то там параметры работы, не помню точно. На plain C. Примерно 500 строк, из которых 60 - это BSDL, и еще 100 - разбор параметров getopt'ом.

По поводу libc и diet: ты таки попробуй собрать статическую прогу с обычной либсей. Посмотри на размер. Потом повтыкай на размер libc-start.o и вывод nm на него (hint: оно живет в архиве libc.a). Потом пойми, почему в статическом бинаре helloworld'а оказывается вкомпиленным динамический редактор связей, и еще много интересных функций, типа *printf (хотя в программе используется write(0, "string", sizeof("string")) и malloc (хотя в программе все статическое). И почему их нельзя оторвать просто так. Потом почитай на тему 'whole program optimization', 'dead code elimination', и подумай, почему это хорошо. И почему плохо, тоже, кстати, подумай.

Да, я и анонимус, имитирующий vsl - разные анонимусы ;)

> Так, уёбисто-безмозглое жывотное из Подоньска таки не знает, что такое компактифицирующий GC. Какая на хер фрагментация, жывотное - память всегда по определению дефрагментирована (в старшем поколении).

Пример реальной системы с компактифицирующим GC, пожалуйста. Потом еще было бы здорово объяснить, зачем оно нужно при наличии страничного MMU и 64-битном адресном пространстве (вырожденные варианты типа "мы возьмем миллиард 10-байтовых объектов, а потом через один их выбросим" не рассматривать, если можно). Также было бы неплохо понять, как их использовать при разработке драйверов (DMA, anyone?), и в FFI (на той стороне - свой GC или явное управление памятью). Вести учет "заякоренных" объектов? Фе.

Да, R00T и правда, как всегда, несет бред...

>Ты вообще понимаешь, что язык ассемблера может быть не привязан к железу? Но при этом тривиально (вплоть до подстановки по таблице) транслироваться в машинный код?

Разберись в терминологии, "самородок":) То, что ты описываешь - это уже не ассемблер, а Forth. Да-да, открой для скбя историю и удивись - java-байткод - это тоже в своей основе таблица для стековой машины - Forth'а.

>kget - это такая программка из FreeBSD, которая спрашивает у ядра какие-то там параметры работы

Да, здесь прогнал - читал невнимательно:)

>По поводу libc и diet: ты таки попробуй собрать статическую прогу с обычной либсей

Пробовал, почему и написал, что "размер объектников" в libc.a - ни причём.

>почему в статическом бинаре helloworld'а оказывается вкомпиленным динамический редактор связей, и еще много интересных функций

Наверное из-за "размеров объектников"?:)

>Как ты себе это представляешь? Загрузка вируса будет происходить до загрузки неопределенности? Всмысле загрузить скажем линукс и заразить загрузчик неопределенности? Так, проще монтировкой комп долбануть и хотя бы винт форматнуть :)

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

Оно из астрала эту инфу берет?

>продемонстрируй это на linux хотябы :)) >c добавленными секюрити патчами к ядру :))

Вот как раз на линуксе такого не повторить.

> >Ты вообще понимаешь, что язык ассемблера может быть не привязан к железу? Но при этом тривиально (вплоть до подстановки по таблице) транслироваться в машинный код?

> Разберись в терминологии, "самородок":) То, что ты описываешь - это уже не ассемблер, а Forth. Да-да, открой для скбя историю и удивись - java-байткод - это тоже в своей основе таблица для стековой машины - Forth'а.

Теперь почитай, и найди мне слово "стековый" в моих сообщениях. Для сведения - Parrot - регистровая VM, а не стековая. То, что у нее бесконечный регистровый файл - дело десятое. Можно легко слепить типизированный ассебмлер (простой пометкой типов указателей), с любым желаемым набором регистров. В т.ч. соотвествующим реальному железу.

>почему в статическом бинаре helloworld'а оказывается вкомпиленным динамический редактор связей, и еще много интересных функций Наверное из-за "размеров объектников"?:)

Эээ. А из-за чего? Ну, кроме отсутствия той самой пресловутой оптимизации полной программы, из-за которой каждый объектник приклеивается целиком, и тянет за собой еще несколько (i.e., libc-start.o трубует, как минимум динамического линкера, аллокатора, принтфа). Ты не поверишь - но даже в dietlibc-шном варианте куча "мертвого кода".

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

Ты привел пример java - там практически стековая forth-машина. Думаю, в .NET аналогично. Зачем приплетать Parrot?

>Можно легко слепить типизированный ассебмлер (простой пометкой типов указателей), с любым желаемым набором регистров. В т.ч. соотвествующим реальному железу.

"соответствующим реальному железу" с ЛЮБЫМ желаемым набором регистром ассемблер не сделаешь - это уже будет не ассемблер по определению.

>приклеивается целиком, и тянет за собой еще несколько (i.e., libc-start.o трубует, как минимум динамического линкера, аллокатора, принтфа)

Вот именно: "тянет", потому как "требует"! "Тянет" то, что "требует" (в иделале - ТОЛЬКО то что требует).

>Древний спор ... программистов системщиков и программистов прикладников :) IMHO Просто смотрят на реализацию задачи с разных сторон.

Не-е-е, это явно не из области этого спора....

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

> Пример реальной системы с компактифицирующим GC, пожалуйста.

Sun Java 1.5, IBM JRE с какой-то страсть как замшелой версии.

> вырожденные варианты типа "мы возьмем миллиард 10-байтовых объектов, а потом через один их выбросим" не рассматривать, если можно

Любой парсер. IP-стек. Очередь с приоритетами в драйвере I/O. Наоборот, сложно найти такие структуры данных в системном программировании, которые не получили бы серьёзное преимущество от компактификации.

> DMA, anyone?

Нерелевантно. Данные неструктурированы.

> FFI (на той стороне - свой GC

Мы же про ядро ОС на гипотетическом языке с GC говорим. Какой тут на фиг FFI - всё монолитно!

> Да, R00T и правда, как всегда, несет бред...

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

Уфф. Все, надоело. Ты передергиваешь и не отвечаешь на вопросы.

Последний ответ:

> >Теперь почитай, и найди мне слово "стековый" в моих сообщениях. > > Ты привел пример java - там практически стековая forth-машина.

> Думаю, в .NET аналогично. Зачем приплетать Parrot?

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

> > с любым желаемым набором регистров. В т.ч. соотвествующим > > реальному железу.

> "соответствующим реальному железу" с ЛЮБЫМ желаемым набором > регистром ассемблер не сделаешь - это уже будет не ассемблер по > определению.

Вот урод, а? Для идиотов:

- Мы можем специфицировать простой, строго типизированный язык с минимальной удобной нам семантикой, включающий понятия "операции", "типа", "объекта", "функции", "вызова", "регистра". Где в "регистрах" могут храниться ссылки на типизированные объекты.

- Количество регистров N, на этапе проектирования языка, можно выбрать произвольно.

- Некоторая интересная нам аппаратная архитектура имеет (ну, упрощенно считаем банк регистров плоским и однородным) K регистров.

- Ничто не мешает, задавшись заранее K, выбрать N = K.

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

Q.E.D.

> >приклеивается целиком, и тянет за собой еще несколько (i.e., > > libc-start.o трубует, как минимум динамического линкера, > > аллокатора, принтфа)

> Вот именно: "тянет", потому как "требует"! "Тянет" то, что > "требует" (в иделале - ТОЛЬКО то что требует).

_Цельными_объектниками_, говорят тебе. вот, например:

---main.c--- #include "other.h" int main() { other1(); return(0); } --other.c--- #include "other.h" void other1() { write(0, MSG1, sizeof(MSG1)); } void other2() { write(0, MSG2, sizeof(MSG2)); } ---other.h--- #ifndef OTHER_H #define OTHER_H #include <unistd.h> #define MSG1 "Hello, world!\n" void other1(); #define MSG2 "This is unused\n" void other2(); #endif ---Makefile--- CC=diet gcc proc: main.o other.o $(CC) -static -o prog main.o other.o ---end---

Теперь скажи make, потом nm prog | grep other2. Потом подумай головой.

Кнопочкой промахнулся.

Уфф. Все, надоело. Ты передергиваешь и не отвечаешь на вопросы.

Последний ответ:

> >Теперь почитай, и найди мне слово "стековый" в моих сообщениях.
> > Ты привел пример java - там практически стековая forth-машина.

> Думаю, в .NET аналогично. Зачем приплетать Parrot?

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

> > с любым желаемым набором регистров. В т.ч. соотвествующим
> > реальному железу.

> "соответствующим реальному железу" с ЛЮБЫМ желаемым набором
> регистром ассемблер не сделаешь - это уже будет не ассемблер по
> определению.

Вот урод, а? Для идиотов:

- Мы можем специфицировать простой, строго типизированный язык с
минимальной удобной нам семантикой, включающий понятия "операции",
"типа", "объекта", "функции", "вызова", "регистра". Где в
"регистрах" могут храниться ссылки на типизированные объекты.

- Количество регистров N, на этапе проектирования языка, можно
выбрать произвольно.

- Некоторая интересная нам аппаратная архитектура имеет (ну,
упрощенно считаем банк регистров плоским и однородным) K регистров.

- Ничто не мешает, задавшись заранее K, выбрать N = K.

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

Q.E.D.

> >приклеивается целиком, и тянет за собой еще несколько (i.e.,
> > libc-start.o трубует, как минимум динамического линкера,
> > аллокатора, принтфа)

> Вот именно: "тянет", потому как "требует"! "Тянет" то, что
> "требует" (в иделале - ТОЛЬКО то что требует).

_Цельными_объектниками_, говорят тебе. вот, например:

---main.c---
#include "other.h"
int main() {
other1();
return(0);
}
--other.c---
#include "other.h"
void other1() { write(0, MSG1, sizeof(MSG1)); }
void other2() { write(0, MSG2, sizeof(MSG2)); }
---other.h---
#ifndef OTHER_H
#define OTHER_H
#include <unistd.h>
#define MSG1 "Hello, world!\n"
void other1();
#define MSG2 "This is unused\n"
void other2();
#endif
---Makefile---
CC=diet gcc
proc: main.o other.o
$(CC) -static -o prog main.o other.o
---end---

Теперь скажи make, потом nm prog | grep other2. Потом подумай головой.

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

Так можно спорить бесконечно:) Пока не определимся, что такое "ассемблер". В моём понимании, ассемблер - это мнемоническая запись всех атомарных команд CPU или VM (при том, что мнемонические команды ОДНОЗНАЧНО транслируются в соответствующие им коды), всё что выше этого (включая макросы, etc.) - это имхо уже нельзя назвать ассемблером ИМХО. Я неправ? Если так - упираться не стану - просветите, плиз, как правильно (хотя меня именно так учили, в т.ч. и неглупые книжки:))

>вот, например: >.....

Что тут можно сказать? Нерациональная реализация (запихивание двух независимых друг от друга функций в один объектник). При желании можно ещё и не такое намутить:)

>Dimentiy кто тебе это сказал ? у меня всё чудно компилируется

"Если программа собралась без ошибок, сообщите об этом разработчику компилятора. Он найдёт ошибки в компиляторе" (c) вольный пересказ из "Теории ошибок" :)

>Потом почитай на тему 'whole program optimization', 'dead code elimination', и подумай, почему это хорошо. И почему плохо, тоже, кстати, подумай.

Я не Led, но мне интересно, чем это так уж плохо. /* Чем хорошо - понятно :) */

> Потом почитай на тему 'whole program optimization', 'dead code elimination', и подумай, почему это хорошо. И почему плохо, тоже, кстати, подумай.

> Я не Led, но мне интересно, чем это так уж плохо. /* Чем хорошо - понятно :) */

Памяти много жрет, настолько, что для крупных монолитных программ нереалистично. Использовать можно либо для встраиваемых приложений (google://NesC/ ;-), либо как в сингулярности - когда каждый объект - программа, и везде "честный" message passing.