Почему мой процессор не сделал, чтобы встроенный BigInt поддерживал?
Насколько я понял это, BigInts обычно реализуются на большинстве языков программирования как массивы, содержащие цифры, где, например: при добавлении двух из них каждая цифра добавляется один за другим как, мы знаем это из школы, например:
246
816
* *
----
1062
Где * метки, что было переполнение. Я изучил это этот путь в школе и всем BigInt, добавляющем функции, я реализовал работу, подобную примеру выше.
Таким образом, все мы знаем, что наши процессоры могут только исходно управлять ints от 0 до 2^32 / 2^64.
Это означает, что большинство языков сценариев, чтобы быть высоким уровнем и арифметикой предложения с большими целыми числами, иметь для реализования/использования библиотек BigInt, которые работают с целыми числами как массивы как вышеупомянутый. Но конечно это означает, что они будут намного медленнее, чем процессор.
Таким образом, то, что я спросил меня:
- Почему мой процессор не сделал, чтобы встроенный BigInt функционировал?
Это работало бы как любая другая библиотека BigInt, только (намного) быстрее и на более низком уровне: Процессор выбирает одну цифру от кэша/RAM, добавляет его и записывает результат обратно снова.
Походит на прекрасную идею мне, итак, почему не там что-то как этот?
4 ответа
Просто слишком много проблем, требующих от процессора обработки большого количества вещей, которые не являются его работой.
Предположим, что DID процессора имеет эту функцию. Мы можем разработать систему, в которой мы знаем, сколько байтов используется данным BigInt - просто используйте тот же принцип, что и большинство строковых библиотек, и запишите длину.
Но что произойдет, если результат операции BigInt превысит объем зарезервированного пространства?
Есть два варианта:
- Он будет перемещаться внутри имеющегося пространства или
- Это займет больше памяти.
Дело в том, что если он сделал 1), то это бесполезно - вам нужно заранее знать, сколько места требуется, и это одна из причин, по которой вы хотели бы использовать BigInt - так что вы не ограничен этими вещами.
Если он сделал 2), то ему придется как-то выделить эту память. В разных операционных системах распределение памяти выполняется по-разному, но даже если бы это было так, все равно пришлось бы обновить все указатели на старое значение. Как он узнает, что такое указатели на значение, а какие просто целые значения, содержащие то же значение, что и рассматриваемый адрес памяти?
На мой взгляд, основная идея отказа от поддержки bigint в современных процессорах - это желание сократить ISA и оставить как можно меньше инструкций, которые извлекаются, декодируются и выполняются на полном ходу. Кстати, в процессорах семейства x86 есть набор инструкций, которые делают написание большой библиотеки int делом одного дня. Другая причина, я думаю, - цена. Гораздо эффективнее сэкономить место на пластине, исключив избыточные операции, которые можно легко реализовать на более высоком уровне.
Предположим, для сохранения результата умножения требуется в 3 раза больше места (памяти) - где процессор сохранит этот результат? Как пользователи этого результата, включая все указатели на него, узнают, что его размер внезапно изменился - и изменение размера может потребовать его для перемещения в памяти, потому что расширение текущего местоположения будет конфликтовать с другой переменной.
Это привело бы к большому взаимодействию между процессором, управлением памятью ОС и компилятором, которое было бы трудно сделать как общим, так и эффективным.
Процессор не должен управлять памятью типов приложений.
Десятичное число в двоичном коде - это форма математической строки. Процессоры Intel x86 имеют коды операций для прямых артметических операций BCD .