Pull to refresh

Comments 18

Не понятно. Всё это можно сделать и на других языках (C/C++/Tcl/Python/Ruby/C#/Java....). Будет точно так же переносимо.
Такой производительности не дает никакой из вышеперечисленных языков, кроме С. А его использование обходиться дороже, как как требуются более мощные процессоры на микросхемах и больше памяти. В результате нам дешевле тратить деньги на разработку и поддержку собственных языков, которые мы делаем так, как нужно нам.
> как как требуются более мощные процессоры на микросхемах и больше памяти.
В примере, который в данной статье даётся, используется ввод/вывод и работа с HTTP. Вы его сможете запустить на этих вот микросхемах?

Мне не понятно, где вы его используете, и почему он вдруг лучше оказывается остальных «традиционных решений».
Используется:
Носители боеголовок Z0,A1,B2,C3,D4 — к ним драйвера на С — 20 Mb, на LLP/HPL — 4/16MB.
Здесь очень важно быстродействие и время связи с спутниками. Примеры производительности (макс 200): C — 162, C++ — 149, LLP — 198, HPL — 162, L.Script Driver — 175

Системы охлаждения 6CHIP Nano II/II — драйвера C — 2Mb, LLP/HTPL — 0.8 Kb/1.2Kb, ПО — C — 12 Mb, LLP/HPL — 6Mb/8Mb

Запущу я, или нет тот, или иной скрипт зависит от подгруженных драйверов.
>к ним драйвера на С — 20 Mb
>Запущу я, или нет тот, или иной скрипт зависит от подгруженных драйверов.
Всё это всё больше какой-то анекдот напоминает.

>Здесь очень важно быстродействие
Я совсем недавно наблюдал своими глазами такую ситуацию — для полной перекомпиляции одного большого ПО требовалось установить дополнительно компилятор ассемблера, так как как минимум один из компонентов был написан на нём, родимом. Ассемблерная реализация использовалась, так как «обычная» на С не давала нужной производительности.
Веский аргумент и правильное решение. Правда, как сейчас выяснилось, «компонент на С» всё это время компилировался без оптимизации — оттого и все эти следствия.

Просто пока всё, что вы написали — это «мы тут написали собственный скриптовый язык. И теперь можем вызывать из него другие части нашей собственной системы!».

Молодцы, да. Но мои сомнения в том, что эти задачи нужно решать таким вот образом — только укрепляются.
Я же вроде написал, что в следующем посте напишу про практическое применение не для наших целей, а для рядовых. И язык этот не такой уж и скриптовый. В названии Script используется как наследство от старого языка. А даже HLP и LLP расшифровываются как High/Low Programming Language.
Хотя с такой кармой у меня вряд ли скоро будет следующий пост.
>И язык этот не такой уж и скриптовый.
Ещё интересней. То есть у вас язык, который компилируется, но при этом получается и быстрее, и компактнее, чем С.

Я вам не верю.
Причиной скорости в решаемых нами задачах есть то, что там нету ничего не нужного нам. Написан на чистом ассемблере. Сейчас вот занимаюсь разработкой (точнее переработкой) С приложения на L.Script. Результаты выложу в следующем обзоре. Я считаю что именно в такой задачи язык столкнется с трудностями.
>Причиной скорости в решаемых нами задачах есть то, что там нету ничего не нужного нам
Вы так говорите, как будто компилятор С вам sleep(1000); постоянно в код вставляет.

Можете мысль раскрыть подробнее? То есть «вот эта конкретная особенность/фича языка C приводит к тому, что вот этот алгоритм/задача начинает приобретать (изначально отсутствующие в ней) тяжеловесность и неэффективность».
Как раз сейчас я и занимаюсь этими исследованиями, так как до этого тестировалась эффективность в общем, а не именно в какой-то задачи и тп.
Уважаемый автор, оформите, пожалуйста, мотивационную часть статьи (aka Rationale) первым абзацем. Из контекста статьи не вполне очевидно, что вас заставило разработать новые ЯП.
Языки написаны на чистом ассемблере благодаря чему имеют большую производительность.

Язык не может быть написан на ассемблере. На ассемблере может быть написан компилятор (вас правда настолько волнует его производительность?) или используемая библиотека (а не пофиг ли тогда откуда ее вызывать?).
Я понимаю, что на ассемблере написан компилятор. Нас действительно волнует производительность, так как это гораздо уменьшает стоимость производства оборудования!..
Нас действительно волнует производительность, так как это гораздо уменьшает стоимость производства оборудования!..

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

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

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

А обсуждали мы ваше (как теперь уже видно, ложное) утверждение о том, что язык написан на ассемблере, благодаря чему он имеет более высокую производительность.
Only those users with full accounts are able to leave comments. Log in, please.

Please pay attention