В википедии сказано что не все процессоры используют обратный порядок байтов, на компьютерах с привычным порядком байтов BinaryReader и BinaryWriter будут вести себя по другому?
будет ли byte($01020304) на процессорах с привычным порядком байтов возвращать $01 вместо $04?
На самом деле все еще запутаннее и должно определяться экспериментально.
В микропроцессорах фирмы IBM и совместимых с ними принят “обратный” порядок хранения данных (он же - “little endian”),
Т.е. если у нас имеется число 2018(10)= 07 Е2(16), то его байты будут помещены в регистры процессора в виде Е2 07. У математиков это обратный порядок, потому что чем бит при записи “на бумажке” левее, тем он старше. В компьютерной памяти это фактически “прямой” порядок, потому что если байт с Е2 попадет в адрес N, то байт с 07 попадет в адрес N+1.
Самое забавное, что все это действительно для физического хранения и чтения данных напрямую из памяти или с регистров процессоров. Разработчики компиляторов самостоятельно принимают решение, каким образом в их программном продукте интерпретируются последовательности байтов.
Ещё 1, как так получается что побитовый сдвиг делается медленнее чем деление? Оно же более сложным должно быть? Или же это только у меня так странно работает? Вот программа которой я тестировал. Дебаг компилятора выключил, по Shift+F9 запустил.
begin
var LT: System.DateTime;
var IC := 1000000000;
var res: integer;
var i: integer := $12345678;
LT := System.DateTime.Now;
loop IC do res := i div 256;
writeln(System.DateTime.Now - LT);
LT := System.DateTime.Now;
loop IC do res := i shr 8;
writeln(System.DateTime.Now - LT);
readln;
end.
Речь не персонально о ком-либо и даже не о конкретном PascalABC.NET.
Речь о том, как отображать битовые цепочки именно цепочками, а не трактовать их, как числа.
test.pas(2) : Ошибка при чтении сборки 'C:\Windows\assembly\GAC\Microsoft.DirectX\1.0.2902.0__31bf3856ad364e35\Microsoft.DirectX.dll'
Что ему может не нравиться? Так при чём с каждой из этих библиотек…
Они вроде на компьютере установлены но находятся ни в каком ни GAC а на прямую в assembly:
DirectX это managed-библиотека написанная под .NET 1.1 на MC++. Такие dll не поддерживаются компилятором, так как System.Reflection их не умеет читать.
Нет ну подождите, директ это одна из передовых графических библиотек, её надо хоть как то поддерживать. Это ни в какие ворота не лезет. Возможно надо как для OpenGL написать модуль, загрузив в него через external все функции и написать от руки все типы?
Вообще мне бы только доступ к пикселям экрана и видео карте на прямую, друзья подсказали что DirectX как раз разбирается с версиями видео карты и даёт возможность делать остальное самому. Есть другой способ?
Я не знаю, когда и что ответят разработчики, но по-моему это анахронизм, сохраненный исключительно для совместимости. Если бы я был разработчиком, то после анализа лексему packed просто бы удалял.
Ничего особого оно не делало. Экономило память путем упаковки данных. Для работы - распаковывало их, т.е. тратило процессорное время на упаковку-распакову - это была плата за экономию памяти. Сейчас памяти много, поэтому проще не упаковывать, чтобы потом не распаковывать.
Хотел только добавить, что модификатор packed в Паскале до сих пор иногда имеет смысл использовать (напр. в Turbo Pascal / Delphi или FreePascal) при описании структурированных типов данных для типизированных файлов, чтобы обеспечить более высокую совместимость по чтению/записи для разных компиляторов и сред исполнения, т.к. все данные в них будут записаны плотно, без платформо-зависимых “дыр” (правда, остается еще проблема endianness и представления/кодировки строк). Но в PABC.NET этот метод работать не будет – здесь это просто заглушка.