При генерации кода, какой язык вы должны генерировать? - PullRequest
6 голосов
/ 25 февраля 2009

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

Недостатком является то, что мы требуем, чтобы пользователи устанавливали компилятор (главным образом в MS Windows).

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

Мы рассматриваем возможность использования GNU C и, возможно, C ++, но даже там есть постоянные проблемы с версиями.

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

В идеале был бы какой-то способ создания сгенерированного кода, который был бы гибким, быстрым и не подвергал бы нас прихотям сторонних поставщиков.

Может быть, я пропускаю что-то простое, например, Java. Любые идеи были бы хорошы. Спасибо.

Ответы [ 12 ]

8 голосов
/ 25 февраля 2009

Если вы рассматриваете C и даже ассемблер, сначала посмотрите на LLVM: http://llvm.org

3 голосов
/ 18 мая 2009

Если вы хотите сгенерировать код на ассемблере, вы можете взглянуть на asmjit .

3 голосов
/ 25 февраля 2009

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

Это будет называться компилятором:)

Почему бы тебе не придерживаться C90?

Я не слышал о серьезных нарушениях стандартов со стороны gcc, если вы не используете расширения.

И вы всегда можете распространять определенную версию gcc вместе с вашим продуктом, например, 4.3.2, предоставляя пользователям возможность использовать собственный компилятор на свой страх и риск.

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

3 голосов
/ 25 февраля 2009

Возможно, мне не хватает некоторого контекста здесь, но не могли бы вы приковать себя к определенной версии? Например, .NET 2.0 может быть установлен бок о бок с .NET 1.1 и .NET 3.5, а также с другими версиями, которые появятся в будущем. Итак, если ваш код использует конкретную версию компилятора, в чем проблема?

2 голосов
/ 25 февраля 2009

Похоже, вы ищете LLVM.

2 голосов
/ 25 февраля 2009

Почему бы не отправить компилятор GNU C вместе с генератором кода? Таким образом, у вас нет проблем с версией, и клиент может постоянно генерировать код, который можно использовать.

2 голосов
/ 25 февраля 2009

Одним из вариантов будет использование языка / среды, обеспечивающей доступ к компилятору в коде; Например, вот пример C # .

2 голосов
/ 25 февраля 2009
1 голос
/ 21 ноября 2010

В духе «может быть, не поздно добавить мои 2 цента», как в случае с ответом @ Элвина, я хотел бы подумать о следующем: если ваше приложение рассчитано на несколько лет, оно будет несколько изменений в том, как работают приложения и системы .

Например, допустим, вы думали об этом 10 лет назад. Я тогда смотрел на Декстера, но, думаю, у вас действительно есть воспоминания о том, как все было в то время. Из того, что я могу сказать, многопоточность не была большой проблемой для разработчиков 2000 года, и теперь это так. Так что закон Мура нарушился для них. До этого людям даже не было дела до того, что произойдет в «Y2K».

Говоря о законе Мура, процессоры действительно становятся достаточно быстрыми, поэтому, возможно, некоторые оптимизации не будут даже такими необходимыми. И, возможно, массив оптимизаций будет намного больше, некоторые процессоры получают оптимизацию для нескольких серверных задач (XML, криптография, сжатие и регулярные выражения! Я удивлен, что такие вещи могут получить сделано на чипе), а также тратить меньше энергии (что, вероятно, очень важно для военной техники ...).

Моя точка зрения заключается в том, что фокусироваться на том, что существует сегодня в качестве платформы для завтрашнего дня, не очень хорошая идея. Сделайте так, чтобы это работало сегодня, и, безусловно, оно будет работать завтра (обратная совместимость особенно ценится Microsoft, Apple, кажется, неплоха, и Linux очень либерален в том, чтобы заставить ее работать так, как вы хотите).

Да, есть одна вещь, которую вы можете сделать. Прикрепите свою технологию к чему-то, что просто (вероятно) не умрет, например, к Javascript. Я серьезно, виртуальные машины Javascript становятся ужасно эффективными в наши дни и будут только улучшаться, плюс всем это нравится, так что они не исчезнут внезапно. Если вам нужно больше эффективности / функций, возможно, нацельтесь на CRL или JVM?

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

PS: В любом случае, я полагаю, что оптимизация C в прошлом все еще вполне применима для современных компиляторов!

1 голос
/ 08 октября 2010

Вставьте переводчик для языка, как Lua / Scheme , в вашу программу и сгенерируйте код на этом языке.

...