Свой язык программирования

[netrino]

Сообщение от DiemonStar

сильно упрощённый вариант - обработка координатной точки (вроде типа TPoint). в обычном коде сложение двух переменных будет выглядеть так:

mov ax, Point1.x
add ax, Point2.x
mov Point1.x, ax
mov ax, Point1.y
add ax, Point2.y
mov Point1.y, ax

хотя, при некоторых допущениях, будет намного функциональнее код типа:

mov eax, Point1
add eax, Point2
mov Point1, eax

при этом можно учесть и оптимизацию по поточным вычислениям для операций со структурами больших объёмов.

Какие такие допущения приведут к вышеуказанному коду? Должна быть как минимум гарантия, что x == 0 и y неотрицательны у обоих точек. Таких гарантий на момент компиляции дать невозможно, следовательно такая оптимизация неосуществима.
Далее, когда заходит речь о скорости выполнения, основная проблема не в языках, а в том, во что их преобразует компилятор. То есть, если хотите производить супер-пупер оптимизации, то нужно не свой язык пилить, а воспользоваться готовой инфраструктурой и внедрять свои оптимизации в неё (например LLVM).
В общем, что хочу сказать, мне кажется, Вы не правильно ставите цели, или же выбрали неверный путь для их решения.

[DiemonStar]

Какие такие допущения приведут к вышеуказанному коду? Должна быть как минимум гарантия, что x == 0 и y неотрицательны у обоих точек. Таких гарантий на момент компиляции дать невозможно, следовательно такая оптимизация неосуществима.

Это всего лишь грубый пример не претендующий на реализуемость. Просто показать принцип оптимизации.

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

Я высказывал такие же соображения несколькими постами ранее.

То есть, если хотите производить супер-пупер оптимизации, то нужно не свой язык пилить, а воспользоваться готовой инфраструктурой и внедрять свои оптимизации в неё (например LLVM).

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

[Utkin]

Это всего лишь грубый пример не претендующий на реализуемость. Просто показать принцип оптимизации.

Счас компилятор от Intel выпустит аналогичный код . От функциональных языков научились так оптимизировать выражения вплоть до констант в случаях когда это возможно. Не думаю, что вы со своими структурами сможете обскакать современные трансляторы.
Возвращаясь к Вашему примеру - точка используется редко и Ваша оптимизация, имей она место не дала бы прироста производительности.

[DiemonStar]

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

попробуйте мыслить абстрактно - это лишь грубый пример, о чём я сказал сразу же. это примерно как спор RISC и CISC архитектур - обе прекрасно применяются, просто в первом случае область применения узкоспециализирована. Теперь представьте на месте этой точки структуры данных по 1-2 кб объёмом)

[crazy horse]

эти конструкции могут быть оптимизированно встроены в язык, а не прифигачены к нему пятой ногой.

Если эти конструкции медленно обрабатываются в языке, на котором пишется новый язык, то каким, прости господи макаром, они быстро заработают в новом? Если просто другая реализация библиотек? Но это не новый язык, это новые библиотеки с теми же ограничениями.

[Utkin]

Теперь представьте на месте этой точки структуры данных по 1-2 кб объёмом)

Назовите нам эти структуры . Я пока не вижу таких уникальных структур.

[DiemonStar]

Назовите нам эти структуры . Я пока не вижу таких уникальных структур.

например, если хотите конкретики, ключевая информация, блоки данных при кодировании.

[Utkin]

например, если хотите конкретики, ключевая информация, блоки данных при кодировании.

Узкая специализация. Программами для кодирования занимается ничтожный процент программистов.
Не знаю что Вы сможете придумать быстрей конвеерных команд процессора... Это я Вам сразу про конкурентов пишу. А именно про интеловский Фортран. Вот если его обскочите, тогда возможно программисты начнут обращать внимание на Ваш продукт.

[DiemonStar]

Узкая специализация. Программами для кодирования занимается ничтожный процент программистов.

И что из этого? В некоторых сетях изменение алгоритма шифрования по времени само по себе будет немалой защитой и язык программирования, который позволяет изменить этот алгоритм в течении 2-3 минут будет довольно-таки востребован) Не сомневаюсь, что многие силовые структуры оценили бы такой подход.
А никто и не говорил о том, что это будет среда для широкого круга программистов)

Вот если его обскочите, тогда возможно программисты начнут обращать внимание на Ваш продукт.

Какой мой продукт?) у меня так вообще и близко в планах нет заниматься такими вещами)

[Дэнис]

А вот тут есть проблемка с выбором:
Сам язык будет Объекто орианированным. Путь такой(по началу, ибо самый лёгкий из всех, что есть):

Моя язык <компилируется> в C/C++ <компилируется с помощью GCC в байт код> Байт код.


Вопрос вот какой: Что лучше для этого C или C++?