Здравствуйте, B0FEE664, Вы писали:
BFE>и всё. приплыли. BFE>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int.
Здравствуйте, Shmj, Вы писали:
S>А Ubuntu так же себя ведет?
Не знаю. Попробуй.
S>Другие версии Linux?
Debian 10 на все даты уходящие за 2038 год говорил, что формат даты не правильный. А в версии 12 ядро подправили и теперь этот порог можно преодолеть, но к такому остальные части системы не готовы...
Здравствуйте, B0FEE664, Вы писали:
BFE> BFE>sudo date --set="2040-12-13 10:09:08" BFE>sudo hwclock --systohc --noadjfile --utc BFE>
BFE>и всё. приплыли.
Куда приплыли-то? Подробности расскажи.
BFE>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int.
Здравствуйте, Философ, Вы писали:
BFE>>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int. Ф>А time_t в линухе не 8 байт? Почему кастят? Ф>Блин, прибил бы автора слова "int" — не понятно же, какого размера...
Ф>UPD: проверил — действительно 8 байт, как и в винде. А как они это кастят?
Никогда не видели кода:
int n = time(NULL);
?
Ф>Почему кастится?
by designe
Причём с gcc опции -Wall -Wpedantic -Wextra не спасут. Нужно дополнительно -Wconversion и только тогда будет предупреждение.
Но это ещё цветочки.
Я не знаю кто и что в недрах gcc или Linux что-то такое предусмотрел, но приложение в конторе (что я консультирую) падает не доходя до main. Причём с какой-то совершенно невнятной диагностикой про размер файла.
Здравствуйте, Pzz, Вы писали:
BFE>> BFE>>sudo date --set="2040-12-13 10:09:08" BFE>>sudo hwclock --systohc --noadjfile --utc BFE>>
BFE>>и всё. приплыли. Pzz>Куда приплыли-то? Подробности расскажи.
Клиенты решили протестировать девайс.
И первым же делом поменяли дату на вышеуказанную (из интерфейса).
И всё, девайс кажет чёрный экран.
Клиент, что характерно, на другом континенте. На этом никому в голову подобное не пришло.
Шев проекта не рискнул повторить трюк, а мне было интересно.
Результат тот же.
По ssh не зайти, девайса в сети нет (хотя ip на нём фиксированный)
Через последовательный порт видно , что загрузка с ошибками, но проходит.
putty подвисает после каждого нажатия enter, так что каждая команда требует переподключения.
Обратно дату на текущую не изменить: команда завершается с ошибкой.
У многих файлов и каталогов дата поменялась на 2040... и именно это приводит к проблемам. Если поменять даты каталогов /etc и /dev на текущие, то кое-что начинает работать.
Я не стал дальше разбираться, а просто переставил систему с флешки.
BFE>>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int. Pzz>А там в хардварии сколько битов-то?
ARM 64 бита.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int. Pzz>>А там в хардварии сколько битов-то? BFE>ARM 64 бита.
Это у процессора. Интересно, сколько битов в том месте железа, куда время пишется.
Кстати, раз это ARM, то вся эта дичь в BSP, или в "общем" коде?
Здравствуйте, Pzz, Вы писали:
Ф>>Блин, прибил бы автора слова "int" — не понятно же, какого размера...
Pzz>Удобного для процессора. На PDP/11 вообще 16 бит было. И на 16-битном 8086 тоже.
Pzz>Автор-то уже помер, поди. Наверное, это был Денис Ричи.
Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
Никогда не любил тестировать подобные штуки, в те времена особенно, но если это так, то это костыль, ныне утративший единственный смысл, который в нём был. Но люди упорно пытаются найти новый (смысл).
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>Никогда не любил тестировать подобные штуки, в те времена особенно, но если это так, то это костыль, ныне утративший единственный смысл, который в нём был. Но люди упорно пытаются найти новый (смысл).
В смысле?
Во времена, когда Си был придуман, были 16-битные компьютеры, они аппаратно складывали за раз два 16-битных числа, а вот чтобы сложить два 32-битных числа, требовалось несколько команд, и были 32-битные компьютеры, их команды за раз оперировали 32-битными числами.
Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32. Поэтому тип, достаточно длинный для подобных применений, но при этом без гарантий относительно конкретной длины (1) имеет смысл (2) очень востребован. Даже и до сих пор.
Здравствуйте, Pzz, Вы писали:
Pzz>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32...
А что, во время 16-битных регистров мегабайтных файлов ещё не было? Или никто последовательно не вычитывал сотни тысяч элементов структуры? Вроде когда C придумали, уже юникс был — уже должны были быть подобные задачи, тем более Масачусетском универе.
Я не сишник, если что.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Pzz, Вы писали:
Pzz>Во времена, когда Си был придуман, были 16-битные компьютеры, они аппаратно складывали за раз два 16-битных числа, а вот чтобы сложить два 32-битных числа, требовалось несколько команд, и были 32-битные компьютеры, их команды за раз оперировали 32-битными числами.
Что происходило с производительностью, если на тех 16-битных компьютерах ты складывал два 8-битных числа?
Допустим, ты портировал код с 8-битной платформы и поэтому точно знал, что диапазона тебе хватит. Получал ли ты выигрыш по скорости, заменив безо всякого прикладного смысла все переменные на 16-битные?
Я, к сожалению, так давно не живу. Почитываю иногда старые статьи, и не уверен, что понимаю их правильно.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Философ, Вы писали:
Pzz>>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32...
Ф>А что, во время 16-битных регистров мегабайтных файлов ещё не было? Или никто последовательно не вычитывал сотни тысяч элементов структуры? Вроде когда C придумали, уже юникс был — уже должны были быть подобные задачи, тем более Масачусетском универе. Ф>Я не сишник, если что.
Здравствуйте, Alekzander, Вы писали:
A>Что происходило с производительностью, если на тех 16-битных компьютерах ты складывал два 8-битных числа?
A>Допустим, ты портировал код с 8-битной платформы и поэтому точно знал, что диапазона тебе хватит. Получал ли ты выигрыш по скорости, заменив безо всякого прикладного смысла все переменные на 16-битные?
Не знаю. Думаю, для разных машин разный ответ.
Но в целом, во времена засилия 16-битных машин памяти было очень мало. Поэтому тратить при работе со строками по 16 бит на символ было бы расточительством; возможность напрямую работать с 8-битными значениями была важна.
Здравствуйте, B0FEE664, Вы писали:
BFE>Никогда не видели кода: BFE>
BFE> int n = time(NULL);
BFE>
BFE>?
Я видел код, в котором в int запихивали указатель. А потом рассчитывали его оттуда достать, в целости и сохранности.
Собственно, даже во времена MS-DOS это было дикостью, потому что int был 16-битным, а far pointer — нет. Но на VAX-е, где родился BSD UNIX, все было 32-битным, очень удобно, пока кому-нибудь не придет в голову такой код куда-нибудь спортировать.
BFE>Я не знаю кто и что в недрах gcc или Linux что-то такое предусмотрел, но приложение в конторе (что я консультирую) падает не доходя до main. Причём с какой-то совершенно невнятной диагностикой про размер файла.
Можно написать функцию, которая исполнится (и упадет) до main-а. В C++ для этого предусмотрены конструкторы статических объектов, для Си в gcc есть специальные расширения.
Ты б дал ему отложить core и посмотрел бы отладчиком на стек...
Здравствуйте, Pzz, Вы писали:
Pzz>Но в целом, во времена засилия 16-битных машин памяти было очень мало. Поэтому тратить при работе со строками по 16 бит на символ было бы расточительством
Речь не про символы, а про счётчики циклов и тому подобное. До сих пор тратить по 16 бит на символ считается расточительством (UTF-8).
Плюс, что тогда было с многозадачностью? Программа начинала требовать больше памяти, но если эта память была увеличена пропорционально разрядности, и никто её больше не тратил, не один ли хрен.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
Pzz>>Но в целом, во времена засилия 16-битных машин памяти было очень мало. Поэтому тратить при работе со строками по 16 бит на символ было бы расточительством
A>Речь не про символы, а про счётчики циклов и тому подобное. До сих пор тратить по 16 бит на символ считается расточительством (UTF-8).
Ну если мы можем вычесть из ASCII-символа цифры '0', чтобы получить ее численное значение, значит, 8-битная арифметика в машине предусмотрена.
Другой вопрос, что счетчик цикла с хорошей вероятностью ляжет на регистр, а дальше надо уже архитектуру конкретных процессоров смотреть, чтобы понять, будет ли ему удобнее в 16-битном регистре, чем в его половинке, или это все равно.
A>Плюс, что тогда было с многозадачностью? Программа начинала требовать больше памяти, но если эта память была увеличена пропорционально разрядности, и никто её больше не тратил, не один ли хрен.
Если памяти, скажем, 128 килобайт на всех, то не один хрен.
Килобайт, обрати внимание. В килобайте 1024 байта.
Здравствуйте, Pzz, Вы писали:
Pzz>Если памяти, скажем, 128 килобайт на всех, то не один хрен.
Pzz>Килобайт, обрати внимание. В килобайте 1024 байта.
128 килобайт было ещё у восьмибитного Спектрума. А Спектрум я уже вполне застал. А у промышленных систем, ну вот я загуглил:
PDP–11/70 – 1975.[15] The 11/45 architecture expanded to allow 4 MB of physical memory segregated onto a private memory bus, 2 KB of cache memory, and much faster I/O devices connected via the Massbus.
Другая известная 16-битная система, 80286 — "640К хватит всем". 640, а не 128.
Я думаю, при переносе восьмибитных программ на практике ты всегда влезал в память, если тупо заменял главный int на 16-битный. Если при этом ты избавлялся от тормозов или ещё какого-нибудь говна, связанного с неродной разрядностью, то в этом и был смысл плавающего размера.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>128 килобайт было ещё у восьмибитного Спектрума. А Спектрум я уже вполне застал. А у промышленных систем, ну вот я загуглил:
A>
A>PDP–11/70 – 1975.[15] The 11/45 architecture expanded to allow 4 MB of physical memory segregated onto a private memory bus, 2 KB of cache memory, and much faster I/O devices connected via the Massbus.
"Allow" != "installed". 128-256 Kb — вполне нормальная сборка для PDP-ки (вернее, я застал советские PDP, СМ/4). В персоналки (Электронока-60) больше 64К не ставили.
A>Другая известная 16-битная система, 80286 — "640К хватит всем". 640, а не 128.
Это уже была прям продвинутая система.
A>Я думаю, при переносе восьмибитных программ на практике ты всегда влезал в память, если тупо заменял главный int на 16-битный. Если при этом ты избавлялся от тормозов или ещё какого-нибудь говна, связанного с неродной разрядностью, то в этом и был смысл плавающего размера.
Что-то я не припомню, чтобы я куда-нибудь переносил 8-битные программы.
16-битные, с MS-DOS на UNIX переносил, как и в обратном направлении.
