Хороша ли идея не кратных машинных примитивов? - PullRequest
1 голос
/ 24 октября 2008

Допустим, у вас есть динамический язык (похожий на обычные языки сценариев) и вы хотите написать для него компилятор. Это хорошая идея, чтобы зарезервировать некоторые биты машинного слова для чего-то вроде тегов типа? Это хорошая идея для микроконтроллеров и подобных устройств?

Я могу подумать о некоторых преимуществах, таких как уменьшение хранилища для информации о типах, несколько более простое управление памятью (возможно, даже gc) и более простая отладка. Но оправдают ли они издержки на общие арифметические операции или другие операции, которые требуют полного слова? Обратите внимание, что виртуальная машина с байт-кодом будет намного хуже в этом отношении, так как производительность значительно возрастает. Так что не предлагайте это;)

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

Ответы [ 5 ]

2 голосов
/ 24 октября 2008

Дополнительная сложность обеспечения того, чтобы биты вашего типа не проходили через какие-либо вычисления, вероятно, намного превысила бы любую экономию хранилища. Вы всегда можете выделить поле типа рядом с любым примитивным полем, которое содержит любые необходимые метаданные / флаги. Затем вы знаете, что любое значение всегда имеет размер хранилища n + 1 слов, при условии, что вы можете сойтись с одним словом для хранения желаемого типа и информации о состоянии.

1 голос
/ 24 октября 2008
Микросхемы

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

Я думаю, что более ранние мелкие дроби делали это с маленькими целыми числами - до определенного значения было int, а через порог - указатель объекта.

1 голос
/ 24 октября 2008

Это может зависеть от того, насколько "микро" ваш микроконтроллер.

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

LISP использует флаги типов, которые означают, что fixnum меньше слова. Таким образом, вы можете обратиться к реализациям LISP (если сможете найти их для процессоров, которые вас интересуют), чтобы увидеть, как они минимизируют стоимость и соответствуют ли их лучшие усилия вашим требованиям.

0 голосов
/ 24 октября 2008

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

С другой стороны, простой компилятор для полностью динамического языка в любом случае должен будет выполнять некоторую форму проверки типов. Универсальное использование динамической диспетчеризации приведет к серьезным потерям производительности на современных процессорах (хотя, возможно, не столь серьезным для микроконтроллеров?)

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

0 голосов
/ 24 октября 2008

Нет, ни в коем случае это не хорошая идея для компилятора общего назначения. Затраты на обработку битов «тега типа» в арифметических операциях будут серьезными.

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

Например, если вы хотите сохранить массив из 5 целых чисел, Python list в порядке (он может хранить произвольно сложные смешанные типы). Но если вы хотите хранить массив из 5 миллионов целых чисел, вы должны использовать модуль array, который хранит их как однородный массив C, или NumPy, который делает что-то подобное, но оптимизированный для выполнения с ними больших математических операций.

...