Pull to refresh

Comments 26

Насколько я понял, в вашем языке переменные не могут иметь тип «множество» или «словарь» (как в python и javascript), есть только массивы. Не думали добавить?

Похожее реализовано на уровне транслятора.

Забавно наблюдать, как опыт автора от использования предыдущих языков влияет на синтаксис и фичи придумываемого им языка.
P.S. Я пробовал создать свой язык, он у меня совсем другим получался. (По крайней мере, идея, до практики я не довёл). И синтаксис, и фичи, и базовые термины, в которых я мыслил — всё иное.

  1. Насколько я вас понял, сборщик мусора убивает только того, для кого явно вызвали rem(). Тогда зачем он вообще нужен, если после вызова rem() можно сразу очищать объект?
  2. Вы плохо меняете размер стека. Так как реаллокация памяти работает за линию от размера буфера, у вас сейчас асимптотика — квадрат. Пример плохого теста — 1е6 раз сделать push. Чтобы ускорить работу стека до O(1) в среднем, нужно не прибавлять что-нибудь к размеру, а увеличивать его в несколько (например в 2 раза). А если, например, потребляется меньше четверти буфера — то сократить в 2 раза. По-прежнему остается недомтаток, что некоторые обращения к стеку будут медленными, но суммарно все отработаеи быстро.
    Есть другие подходы, но этот самый простой.

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


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

  1. Но вызов rem() или Free() или подобного все равно пишется вручную, так?
  2. В байткоде ВМ есть push. К тому же рекурсия может отъесть тот самый миллион фреймов в стеке вызовов.
1. Да. И реализуется в ручную. При этом, разработчик на 200% уверен в каждой переменной и объекте, что они не пропадут в никуда при вызове сборщика мусора, если он не написал соответствующий код.
2. Мне кажется, что увеличение в 2 раза размера стека каждый раз может привести к Access Violation.
  1. Тогда в чем проблема, когда программа на каком-то объекте вызывает rem(), сразу вычистить все? Это позволит выпилить из ВМ целую подсистему.
  2. Не каждый, а когда он заполнен до отказа.
    Оверхед по памяти от 0 до 3 раз. Но вообще, меняя границы реаллока, можно добиваться разных компромиссов между оверхедем по памяти и производительностью, но в любом случае O(N) памяти и времени.
    В принципе, вы можете организовать стек как односвязный список блоков, т.е. каждый блок имеет указатель на предыдущий, и буфер на, скажем, 256 элементов. Тогда оверхед по памяти вообще крошечный, время работы — О(1) на любой запрос. Единственная потеря — сложная и медленная индексация, но вам это вроде как не нужно.
Писать демонстрационный проект на Pascal — плохая идея. На нём уже не пишут, следовательно придёться адаптировать код Вашего репозитория под свои языки. В 90% случаев ими выступают C/C++ в силу специфики создания трансляторов.

Object Pascal — прекрасный язык общего назначения. Транслятор мне на нем было писать одним удовольствием, спасибо удобной реализации строк в языке. На плюсах я бы возился гораздо дольше. Да и переписывать нет смысла проект. Хочу в качестве бекенда LLVM взять. Позже соответственно и статью накатаю, если разберусь с этим.

Попробуйте C#, удобнее и Object Pascal и C/C++ в разы. Сам начинал свой путь с pascal, поэтому знаю, о чём говорю.
C# более платформозависим и не очень подходит для написания ВМ, к сожалению.

Ничо что на C# пишут и под iOS, и под Android? Не говоря уж о линуксах?
Игровой движок Unity как бы намекает (mono).
Net Core опять же.


Бросайте уже эту "платформозависимую" чушь десятилетней давности повторять.

Сравните перечень поддерживаемых платформ у того же FPC и у C#)

Сравните перечень поддерживаемых платформ у того же FPC и у C#)

Спору нет. Если вам ну очень нужна поддержка Solaris и PowerPC :)

Никогда не используйте вложенные конструкции switch/case. Это неудобно читать и неудобно сопровождать, и со временем такой код имеет тенденцию превращаться в нечто монструозное.
Как по мне — наоборот, код компактнее и проще.
Скажите, используя FPC, почему бы не переложить все низкоуровневые операции на сам язык? Т.е не управлять памятью непосредственно, а использовать, например, ряд доступных в языке классов(подозреваю, что класс стека в языке уже и так присутствовал, как и GC — в конечном счете вся выделенная память, используемая в ходе обработки опкодов, находится в FPC-шных переменных)? Таким образом, приведенной ВМ оставалось бы лишь управлять этим стеком на высоком уровне абстракции, занимаясь лишь интерпретацией опкодов(?).
И дополнительный вопрос(связанный с ленью заглянуть в репозиторий и найти ответ там): в каком виде существует ваша ВМ? Какая именно цепочка действий в итоге «скармливает» исходный файл(из файловой системы) с описанными в статье опкодами языковой ВМ?

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

Пишите, умоляю вас) Самого интересует это, на Хабре довольно много статей на эту тему, но к сожалению они не доходят дальше 1-2 части, заканчиваясь на самом интересном и важном, видать у мамкиных создателей языков пропадает запал к тому времени) У вас, я вижу, пороха много, может быть вы наконец-таки напишете полный курс статей на эту тему)

Третья статья (ч. 2) уже на подходе ;)
Надеюсь, что проделанная работа будет оценена обществом по достоинству.

Хо-хо, рад слышать) Но здесь стоит уточнить, что тема эта все-таки узкоспециализирована, ибо к сожалению очень не у многих имеется свободное время и желание изобретать что-то свое, причем не массовое, то ли дело готовые языки. Плюс регулярно будут спрашивать в лоб мол зачем все это, нахрен я это прочитал, и вообще, но это не критерии что ваша работа не нужна никому, она нужна тем, кому нужна, и они будут обязательно, просто понятно что не столько, сколько ожидается. Разумеется тема будет скорее всего обсуждаема, но в большинстве случаев не по существу. Просто немного объясняю ситуацию в этой области, если вдруг что ;)

Не очень удачное название, т.к. SVM довольно устоявшаяся аббревиатура для Support Vector Machine («Метод опорных векторов»).

Ну. Я не шибко уж красноречив на названия.

Only those users with full accounts are able to leave comments. Log in, please.