С практической точки зрения складывать надо числа на 1 шаг разрядности меньшие, чем поддерживаются языком. Иначе будет то, что вы ожидаете от меня получить.
ЗЫ: Я знаю, как будет выглядеть код, если пытаться складывать 64-х битные числа.
Согласен с тем, что в Си нет проверки на переполнение. Было бы очень здорово, если бы оно было в виде int add_int(int *a, int b, int с) { ... *a += b + c; ... } , где возвращаемое значение 0 - если все в порядке, -1 если переполнение в отрицательную сторону, 1 - в положительную. В этом случае очень удобно бы было делать операции с многоразрядными числами.
Речь про процессоры, а не про языки программирования. Если вам нужно сложить два числа разрядностью 32 бита на 8-ми битном Z80, например, то вы делает это так:
Как не трудно заметить, сложность тут чисто линейная, чуть дороже, чем сложение 4-х 8-ми битовых чисел. И никакие библиотеки тут не нужны. А вот на языках высокого уровня сделать это значительно сложней, так как ни один язык, что я знаю, не предоставляет информацию о переполнении.
Цена 64-битнго сложения на 32-битной машине равна двум 32-битным сложениям: сложение и сложение с переносом. Ничего тут страшного нет. Другое дело, что неправильно так делать для проверки, с учетом того, что сам процессор, обычно, знает, когда произошло переполнение.
memset - это стандартная функция. Она есть в стандарте. Более того, сам Линукс к подобным функция не привязан. Более того, если не ошибаюсь, там вообще стандартная библиотека в ядре отсутствует.
А причина, по которой не хотят переносить ядро на другой язык, кроме того, что придется все переписывать, заключается в том, что другие языки требуют для работы программы поддержку со стороны стандартной библиотеки (runtime), а вот программа на Си не требует - все конструкции языка будут компилироваться даже без библиотеки.
Процессору пофиг. А вот компилятору нет. Сегодня ты компилмруешь для процессора с int=int32, а завтра int=int64, и твоя кривая проверка работать перестанет. Поэтому разработчики стандарта языка и компиляторов делают такие вещи. По мне, если ты делаешь какую-то дичь, которая не соответствует стандарту языка, ты обязан обложить ее проверками на архитектуру системы и написать кучу комментариев, почему ты это сделал, и как оно вообще работает. По-хорошему, компилятор должен ругаться, когда выкидывает часть кода. Ну, ненормально это в 99% случаев.
Нет, нет никакого лока. Ядро стартует когда нет ничего, кроме непрерывного куска памяти с кодом и процессора. В этом режиме очень хочется не отвлекаться на всякие магические процедуры, которые непонятно когда запускаются и сколько времени тратят. А вот когда ядро стартануло, запустило все дрова и инициализировало вверенное оборудование, то тогда можно и свистелки-перделки запускать.
С/х землю могли покупать в инвестиционных целях - с целью вложения денег во что-то. Пока не было штрафов, платился небольшой налог на собственность. А теперь заставляют обрабатывать землю, что ведет к увеличению занятости и ВВП в целом. Один недостаток - на жопе ровно сидеть дорого выходит...
Позволю себе позанудствовать.
Напряжение измеряется между двумя точками. Поэтому не важно сколько у вас фаз. В России в обычной сети между фазами 380-400 В, а между нулем и фазой 220-230 В. Поэтому худший случай — это 400 В (падение высоковольтного провода на низковольтную линию и прочие катастрофы не берем в расчет).
Вы делаете устройство, которое должно работать в условиях «если жопа» в сети. А классическая «жопа» — отгорание нуля, а это до 400В.
У моих родителей на даче напруга скачет от 160 В (ниже — вырубаются автоматы на вводе поселка) до 270 В (и это без отгораний нуля!). Поэтому ваши вводные кажутся довольно оптимистичными. Я бы делал от 160 В до 400 В, а если сделать от 80 В до 400 В, то можно будет по всему миру использовать.
Заправляюсь только на Лукойле. Первое время сервисмены на ТО очень удивлялись, чем я таким заправляюсь, что мыть ничего не надо (это доп. работа). Правда, сейчас каждый раз моют.
Тогда понятно, почему продвигают Rust для разработки ядра.
Тут кто-то очень щедро минусы расставляет. У меня почти все комментарии с минусами тут. :-)
Я вот не знаю Питона :-)
С практической точки зрения складывать надо числа на 1 шаг разрядности меньшие, чем поддерживаются языком. Иначе будет то, что вы ожидаете от меня получить.
ЗЫ: Я знаю, как будет выглядеть код, если пытаться складывать 64-х битные числа.
Согласен, это только на ассемблере можно так просто сделать. На Си будет чуть сложней.
Да, это несколько дороже... Возможно, компилятор при оптимизации сможет что-то сделать, но не уверен.
Согласен с тем, что в Си нет проверки на переполнение. Было бы очень здорово, если бы оно было в виде int add_int(int *a, int b, int с) { ... *a += b + c; ... } , где возвращаемое значение 0 - если все в порядке, -1 если переполнение в отрицательную сторону, 1 - в положительную. В этом случае очень удобно бы было делать операции с многоразрядными числами.
Речь про процессоры, а не про языки программирования. Если вам нужно сложить два числа разрядностью 32 бита на 8-ми битном Z80, например, то вы делает это так:
Как не трудно заметить, сложность тут чисто линейная, чуть дороже, чем сложение 4-х 8-ми битовых чисел. И никакие библиотеки тут не нужны. А вот на языках высокого уровня сделать это значительно сложней, так как ни один язык, что я знаю, не предоставляет информацию о переполнении.
Цена 64-битнго сложения на 32-битной машине равна двум 32-битным сложениям: сложение и сложение с переносом. Ничего тут страшного нет. Другое дело, что неправильно так делать для проверки, с учетом того, что сам процессор, обычно, знает, когда произошло переполнение.
memset - это стандартная функция. Она есть в стандарте. Более того, сам Линукс к подобным функция не привязан. Более того, если не ошибаюсь, там вообще стандартная библиотека в ядре отсутствует.
А причина, по которой не хотят переносить ядро на другой язык, кроме того, что придется все переписывать, заключается в том, что другие языки требуют для работы программы поддержку со стороны стандартной библиотеки (runtime), а вот программа на Си не требует - все конструкции языка будут компилироваться даже без библиотеки.
Процессору пофиг. А вот компилятору нет. Сегодня ты компилмруешь для процессора с int=int32, а завтра int=int64, и твоя кривая проверка работать перестанет. Поэтому разработчики стандарта языка и компиляторов делают такие вещи. По мне, если ты делаешь какую-то дичь, которая не соответствует стандарту языка, ты обязан обложить ее проверками на архитектуру системы и написать кучу комментариев, почему ты это сделал, и как оно вообще работает. По-хорошему, компилятор должен ругаться, когда выкидывает часть кода. Ну, ненормально это в 99% случаев.
Нет, нет никакого лока. Ядро стартует когда нет ничего, кроме непрерывного куска памяти с кодом и процессора. В этом режиме очень хочется не отвлекаться на всякие магические процедуры, которые непонятно когда запускаются и сколько времени тратят. А вот когда ядро стартануло, запустило все дрова и инициализировало вверенное оборудование, то тогда можно и свистелки-перделки запускать.
С/х землю могли покупать в инвестиционных целях - с целью вложения денег во что-то. Пока не было штрафов, платился небольшой налог на собственность. А теперь заставляют обрабатывать землю, что ведет к увеличению занятости и ВВП в целом. Один недостаток - на жопе ровно сидеть дорого выходит...
Вы не поверите, но многие ранее "бесхозные" земли вдруг неожиданно стали обрабатываться...
Напряжение измеряется между двумя точками. Поэтому не важно сколько у вас фаз. В России в обычной сети между фазами 380-400 В, а между нулем и фазой 220-230 В. Поэтому худший случай — это 400 В (падение высоковольтного провода на низковольтную линию и прочие катастрофы не берем в расчет).
У моих родителей на даче напруга скачет от 160 В (ниже — вырубаются автоматы на вводе поселка) до 270 В (и это без отгораний нуля!). Поэтому ваши вводные кажутся довольно оптимистичными. Я бы делал от 160 В до 400 В, а если сделать от 80 В до 400 В, то можно будет по всему миру использовать.
А если вы под колпаком у спец.служб, то о ваших перемещениях он будут знать по геопозиции телефона и фиксации номера дорожными камерами.