| предсонное, неинтересное, гиковское, мысли, дыбр (да, это тэги) |
[Jan. 17th, 2013|01:02 am] |
подумываю таки оживить проект mist. это такой язык, у которого вся основа спизжена со смолтолка, но немного своего добавлено и у объектов есть такая фича, как «состояние» (спизжено из анрылскрипта). язык скорее скриптовый, чем standalone. собственно, реализации там немного, но при написании «в лоб» оно будет атомно тормозить. а с другой стороны — надо, всё же, сделать хотя бы прототип, пусть и мегатормозной. а потом уже ваять версию побыстрее.
да, предварительный набросок техдока на язык давно есть. техдоки на рантайм нет пока, но тут можно спереть основу из Little Smalltalk и доработать напильником.
правда, я пока не могу решить, разрешить ли перегрузку математических и условных сообщений. в принципе, идеологически надо разрешить, но тогда компилятор не сможет читерить, компилируя их напрямую в инструкции VM, а не как обычную посылку сообщений. как вариант — это можно решить, зарезервировав за ними определённые «номерные» слоты (чтобы избежать тормозов при поиске метода) и отключать читерство, если в этих слотах находится нестандартная реализация (компилятор и VM могут это определить).
также думаю, как получше и попроще организовать кэш сообщений. можно, например, хранить индексы нескольких слотов (и то, какому объекту они принадлежат) прямо в коде VM. тогда если некий обработчик постоянно посылает определённые сообщения определённым объектам (а так и есть обычно), то не надо будет их каждый раз искать заново. ну, и там же хранить «индекс модификации объекта», чтобы инвалидировать кэш, если добавили/убрали обработчик. надо будет сделать компилятор mist'а на mist'е, и собирать ним стандартную библиотеку (как достаточно большой кусок кода). соответственно, потенциальное ускорение будет видно просто глазами (и time), и будет ясно, есть ли смысл усложнять код.
с GC, опять же, не очень ясно. с одной стороны инкрементальный+generational выглядит красиво. с другой стороны — refcounter, возможно, проще (плюс периодический mark/sweep для убития циклов; или спиздить где-нибудь детектор циклов). запарка в том, что это надо бы решить сразу, потому что в код придётся мандячить соответствующую логику: или write barriers для первого варианта, или ебопляску со счётчиком для второго.
пока что первый вариант мне нравится больше. в частности и потому, что чистый refcounter всё равно нихера не обеспечивает «прогнозируемого времени»: а если по цепочке 100500 объектов освободится? так что всё равно получится комбинированый вариант, а тогда зачем делать такого монстрика?
зачем? просто потому, что давно я язычков не делал. а какие делал — те все какие-то «обычные», неинтересные. |
|
|