tarasv> Я не при чем в хуже, это был ты. Тебе с расчетом указали на несоответствие заявленных характеристик архитектуры реальности. Ты предложил решение, вернее "решение", которое я проанализировал и оно оказалось хуже чем то что было до него. Вот и все.
Уф.
Твой "анализ" - не для моего решения, а для твоего, ты почему-то прицепился к нынешней реализации, и то, что ты придумываешь в качестве альтернативы (отдельные кучи под свой размер) заставляет меня дыбиться.
tarasv> Ты мне про однородные массивы не пиши.
Я не пишу про однородные массивы. Я пишу про кучу. Но вижу какой-то барьер просто. Вот давай с другой стороны: как сейчас?
В общем случае чтобы выбрать "из памяти" (с той же кучи) некоторого произвольного размера переменную, тебе нужны
1) размер элемента массива данных: сейчас память есть массив из 8-бит элементов, так что 8 бит замертво вколочено в аппаратуру,
2) индекс начального элемента переменной в массиве данных: ты привык называть это "указателем" или "адресом", он указывает номер байта, с которого начинается нужная тебе переменная,
3) начало массива: сейчас это либо аппаратный ноль (в системах попроще), либо старт сегмента данных процесса,
4) размер этой самой переменной: сейчас это явно или неявно прописано в кратных 8 битам единицах в коде команды.
Когда ты выбираешь 64-битный long, тебя же не беспокоит, что до этого на куче лежит строка, а то того - 16-битное целое, а до того - ещё строка, а до неё ещё массив 32-битных полуслов, а до него ещё указатели... и т.п. Ведь правда? У тебя есть номер начального элемента - байта, у тебя есть размер данных, которые нужно вытащить в регистр. (Указатель будет "домножен" на неявные 8, база будет взята неявно за 0). Всё.
И больше тебе ничего не нужно, чтобы система аллокации кучи работала: искала подходящие куски байт под запрошенный размер, выделяла память, освобождала. Так?
В альтернативе
ВСЁ то же самое.
1) размер элемента массива данных задан в регистре,
2) индекс начального элемента данных - аналог указателя,
3) начало массива задано регистром базы,
4) размер выборки строго равен размеру элемента массива данных.
Ну и система аллокации считает свободную/занятую память побитно (и пословно), а не побайтно, только и всего. Я прошу мне выделить бит, система берёт первый попавшийся свободный бит и отдаёт мне "указатель" (он же битовый индекс, он же - тупо число бит от базы). Я прошу выделить мне 7 бит, система находит первые свободные 7 бит, которые находятся на кратном 7 расстоянии от базы, и отдаёт мне "указатель" (он же индекс, сколько 7-битовых значений нужно отсчитать от базы, чтобы взять нужные мне 7 бит).
Это
одна и та же память. Как и с байтами, никакой разницы, все данные сидят вперемешку. Только с байтовыми значениями у тебя всегда всё выравнено на байт, а у меня небайтовые n-битные значения находятся на расстоянии n*m бит от базы.
Сильное ли это ограничение при выделении памяти? Нет. Только лишь в случае исключительно сильной фрагментации, и в этом случае байтовая система хуже - у неё другой расход и фрагментация наступает раньше. Есть ли непроизводительный расход памяти? Да, но на практике он минимален, потому что в реальном коде одиночные переменные на куче, конечно, встречаются, но памяти они почти не занимают, основной потребитель - большие структуры и массивы, а тут выигрыш. Больше ли работы системе аллокации с побитным учётом? Хм, да нет. Размер оперируемых целых на 3 бита больше, но это важно только если куча размером с физическую память. Давай для ясности этот случай всё-таки замнём.
tarasv> Я и так знаю что они у тебя хорошо работают и уже несколько раз тебе это писал. Недостаток как обычно - лишняя аппаратура. Для вычисления эффективного адреса необходимо умножение.
Умножение - да, это я понимаю и принимаю. Насчёт этого я серьёзно думаю.
Сдвиг в сравнении с умножением ГОРАЗДО дешевле, почти-бесплатен. Ограничить вариативность степенями двойки соблазнительно, и сразу же экономится место под указание размера.
Я ещё не уверен, пока ещё рисую.
tarasv> И это работает только для целых. Ну и еще наверно перфокарт. А я вот экономно храню табель на диске id:16_len:8name_hours:8. (_ разделитель для читабельности) Сможешь придумать эффективную реализацию обработки таких записей?
Не очень понял, про какую "обработку", но адресовать поле из пачки таких структур очень просто, идеальный вариант.
16-битное id - адресуется как 16-битное mov r, (база + 32 * индекс_структуры),
8-битное len - mov r, (база + 8 * (индекс_структуры « 2 + 2)),
8-битное name_hours - mov r, (база + 8 * (индекс_структуры « 2 + 3)).
Точно так же, как и с побайтовой адресацией выражение типа "индекс_структуры « 2 + 2" ты вычислишь заранее, до выборки. Всё то же самое.
tarasv> 32 всегда пролетает до 2х раза по памяти против микса 8/16/32 и на 40% против микса 16/32, разве нет?
Конечно, нет. Ты зря считаешь в "расходе" базу. База у тебя есть и так, и этак, просто "классически" ты о ней не думаешь - ну есть выделенный сегмент и есть, а то, что есть регистр(-ы), которые это обеспечивают, ты как бы и "забыл". Ну или в системах с полностью плоской памятью база аппаратно 0, но это порождает неудобства другого рода, и ты в многозадачной системе начинаешь складывать какую-то базу в коде или извращаться как-то ещё. Тут у меня ничего лишнего.
Но и там, и там по "классике", у тебя требуется совершенно избыточный "полноценный" указатель, способный в пределе адресовать всю память, система опять бессмысленно занята перетаскиванием бессмысленных нулей.