Индусские программисты и индусский код
-
- Уже с Приветом
- Posts: 15475
- Joined: 27 Sep 2007 22:53
Re: Индусские программисты и индусский код
а если, к примеру А немного подлиннее чем int, то всегда ли f возвратит true?
bool f() {
long A = ..... ;
if(A) return A;
return true;
}
bool f() {
long A = ..... ;
if(A) return A;
return true;
}
-
- Уже с Приветом
- Posts: 63377
- Joined: 03 Nov 2004 05:31
- Location: RU -> Toronto, ON
Re: Индусские программисты и индусский код
хм... должно "усечь", т.е. ноль получить как нефиг делать.
Not everyone believes what I believe but my beliefs do not require them to.
-
- Уже с Приветом
- Posts: 15242
- Joined: 01 Mar 2007 05:18
- Location: VVO->ORD->DFW->SFO->DFW->PDX
Re: Индусские программисты и индусский код
Не, ничего никуда не усекается, токма что проверил. До компилятора доходит, что он сначала должен сделать преобразование long -> bool
Но от греха подальше я бы так не стал. либо long f(), либо return (bool) A;
Но от греха подальше я бы так не стал. либо long f(), либо return (bool) A;
Мат на форуме запрещен, блдж!
-
- Уже с Приветом
- Posts: 4637
- Joined: 24 Oct 2009 01:38
- Location: Chicago ;-) -> SFBA!
Re: Индусские программисты и индусский код
Так какой же все таки ответ про архитектуры процессоров? Кажется коллективное (без)сознательное не породило никаких интересных идей.Dweller wrote:и все же дам интересующимся возможность пообсуждатьcrypto5 wrote:Предположим. И какая бывает разница?Dweller wrote:имеются в виду разные архитектуры процессораcrypto5 wrote:А какой ответ про "типы машин"?
In vino Veritas!
-
- Уже с Приветом
- Posts: 15475
- Joined: 27 Sep 2007 22:53
Re: Индусские программисты и индусский код
Но это если тип bool определен в языке, как например в С++,АццкоМото wrote:Не, ничего никуда не усекается, токма что проверил. До компилятора доходит, что он сначала должен сделать преобразование long -> bool
Но от греха подальше я бы так не стал. либо long f(), либо return (bool) A;
В обычном С это вроде простой макрос.
-
- Уже с Приветом
- Posts: 15242
- Joined: 01 Mar 2007 05:18
- Location: VVO->ORD->DFW->SFO->DFW->PDX
Re: Индусские программисты и индусский код
Ну и как должен выглядеть макрос, который обеспечиваетМальчик-Одуванчик wrote:Но это если тип bool определен в языке, как например в С++,АццкоМото wrote:Не, ничего никуда не усекается, токма что проверил. До компилятора доходит, что он сначала должен сделать преобразование long -> bool
Но от греха подальше я бы так не стал. либо long f(), либо return (bool) A;
В обычном С это вроде простой макрос.
bool v=3; // v==1
?
Насколько я понимаю (могу ошибаться), реальный тип - _Bool, а bool - его синоним, определенный макросом. Т.е. на уровне йызыка он какгбэ все равно есть, но решили не использовать bool на уровне йызыка, так как он определен в куче легасевого кода.
Мат на форуме запрещен, блдж!
-
- Уже с Приветом
- Posts: 12257
- Joined: 20 Dec 2000 10:01
- Location: Bellevue, WA
Re: Индусские программисты и индусский код
Есть sequential consistency и weak consistency в исполнении инструкций. При weak consistency соседний проц может увидеть присвоение Х=1 после того как первый выполнит if (Y == 1), в абсолютном времени. Т.е. для первого проца порядок в каком увидятся результаты инструкций не важен.crypto5 wrote:Так какой же все таки ответ про архитектуры процессоров? Кажется коллективное (без)сознательное не породило никаких интересных идей.Dweller wrote:и все же дам интересующимся возможность пообсуждатьcrypto5 wrote:Предположим. И какая бывает разница?Dweller wrote:имеются в виду разные архитектуры процессораcrypto5 wrote:А какой ответ про "типы машин"?
Last edited by Dweller on 30 Jan 2013 21:59, edited 1 time in total.
-
- Уже с Приветом
- Posts: 4637
- Joined: 24 Oct 2009 01:38
- Location: Chicago ;-) -> SFBA!
Re: Индусские программисты и индусский код
Это на каких процессорах/языках программирования такое? Ну и помоему даже если так, это на результат не влияет.Dweller wrote:Есть sequential consistency и weak consistency в исполнении инструкций. При weak consistency присвоение Х=1 может исполниться после if (Y == 1)crypto5 wrote:Так какой же все таки ответ про архитектуры процессоров? Кажется коллективное (без)сознательное не породило никаких интересных идей.Dweller wrote:и все же дам интересующимся возможность пообсуждатьcrypto5 wrote:Предположим. И какая бывает разница?Dweller wrote:имеются в виду разные архитектуры процессора
In vino Veritas!
-
- Уже с Приветом
- Posts: 15475
- Joined: 27 Sep 2007 22:53
Re: Индусские программисты и индусский код
Собственно об этом и речь, что полно кода где bool задан, к примеру, как сhаr (старый код или все еще в некоторых компиляторах для микроконтроллеров)АццкоМото wrote:Ну и как должен выглядеть макрос, который обеспечиваетМальчик-Одуванчик wrote:Но это если тип bool определен в языке, как например в С++,АццкоМото wrote:Не, ничего никуда не усекается, токма что проверил. До компилятора доходит, что он сначала должен сделать преобразование long -> bool
Но от греха подальше я бы так не стал. либо long f(), либо return (bool) A;
В обычном С это вроде простой макрос.
bool v=3; // v==1
?
Насколько я понимаю (могу ошибаться), реальный тип - _Bool, а bool - его синоним, определенный макросом. Т.е. на уровне йызыка он какгбэ все равно есть, но решили не использовать bool на уровне йызыка, так как он определен в куче легасевого кода.
-
- Уже с Приветом
- Posts: 15242
- Joined: 01 Mar 2007 05:18
- Location: VVO->ORD->DFW->SFO->DFW->PDX
Re: Индусские программисты и индусский код
Влияет, очевидноcrypto5 wrote: Ну и помоему даже если так, это на результат не влияет.
Мат на форуме запрещен, блдж!
-
- Уже с Приветом
- Posts: 4637
- Joined: 24 Oct 2009 01:38
- Location: Chicago ;-) -> SFBA!
Re: Индусские программисты и индусский код
Можете привести пример как?АццкоМото wrote:Влияет, очевидноcrypto5 wrote: Ну и помоему даже если так, это на результат не влияет.
In vino Veritas!
-
- Уже с Приветом
- Posts: 15242
- Joined: 01 Mar 2007 05:18
- Location: VVO->ORD->DFW->SFO->DFW->PDX
Re: Индусские программисты и индусский код
Разумеется, если это pre-C99, то может и обрезать. Если С99 и bool из stdbool.h - то все ОКМальчик-Одуванчик wrote:Собственно об этом и речь, что полно кода где bool задан, к примеру, как сhаr (старый код или все еще в некоторых компиляторах для микроконтроллеров)
Мат на форуме запрещен, блдж!
-
- Уже с Приветом
- Posts: 3647
- Joined: 23 May 2010 15:10
Re: Индусские программисты и индусский код
на little endian нет, т.е. на всех x86 (собственно тем little endian и хорош )Flash-04 wrote:хм... должно "усечь", т.е. ноль получить как нефиг делать.
это если bool это не bool, а char или еще что
если bool это bool, то должно быть нормально в любом случае
на big endian архитектурах, для bool pre-c99, будет ноль
Last edited by Alexandr on 30 Jan 2013 21:55, edited 1 time in total.
-
- Уже с Приветом
- Posts: 15242
- Joined: 01 Mar 2007 05:18
- Location: VVO->ORD->DFW->SFO->DFW->PDX
Re: Индусские программисты и индусский код
Дык. Если последовательность соблюдается строго, то как ни верти, а минимум одна единичка будет напечатана. Если нет - могут быть два нолика. Как-то так.crypto5 wrote:Можете привести пример как?АццкоМото wrote:Влияет, очевидноcrypto5 wrote: Ну и помоему даже если так, это на результат не влияет.
Мат на форуме запрещен, блдж!
-
- Уже с Приветом
- Posts: 4637
- Joined: 24 Oct 2009 01:38
- Location: Chicago ;-) -> SFBA!
Re: Индусские программисты и индусский код
Да нет, присвоение в одном потоке может быть не видно из другого потока. В джаве для таких случаев переменную обозначают как volatile и всякие Atomic* придуманы.АццкоМото wrote:Дык. Если последовательность соблюдается строго, то как ни верти, а минимум одна единичка будет напечатана. Если нет - могут быть два нолика. Как-то так.crypto5 wrote:Можете привести пример как?АццкоМото wrote:Влияет, очевидноcrypto5 wrote: Ну и помоему даже если так, это на результат не влияет.
In vino Veritas!
-
- Уже с Приветом
- Posts: 15242
- Joined: 01 Mar 2007 05:18
- Location: VVO->ORD->DFW->SFO->DFW->PDX
Re: Индусские программисты и индусский код
Ну в джаве и операции не атомарные. Если представить себе сферический одноядерный контупер с переключением контекста промеж потоков, общей памятью и атомарными операциями - то получается разница. каждый дополнительный уровень абстракции будет только добавлять пачку "да, но если ***, то все-таки нет"crypto5 wrote: Да нет, присвоение в одном потоке может быть не видно из другого потока. В джаве для таких случаев переменную обозначают как volatile и всякие Atomic* придуманы.
Мат на форуме запрещен, блдж!
-
- Уже с Приветом
- Posts: 4637
- Joined: 24 Oct 2009 01:38
- Location: Chicago ;-) -> SFBA!
Re: Индусские программисты и индусский код
С этим не поспоришьАццкоМото wrote:Ну в джаве и операции не атомарные. Если представить себе сферический одноядерный контупер с переключением контекста промеж потоков, общей памятью и атомарными операциями - то получается разница. каждый дополнительный уровень абстракции будет только добавлять пачку "да, но если ***, то все-таки нет"crypto5 wrote: Да нет, присвоение в одном потоке может быть не видно из другого потока. В джаве для таких случаев переменную обозначают как volatile и всякие Atomic* придуманы.
In vino Veritas!
-
- Уже с Приветом
- Posts: 12257
- Joined: 20 Dec 2000 10:01
- Location: Bellevue, WA
Re: Индусские программисты и индусский код
добавил:
Есть sequential consistency и weak consistency в исполнении инструкций. При weak consistency соседний проц может увидеть присвоение Х=1 после того как первый выполнит if (Y == 1), в абсолютном времени. Т.е. для первого проца порядок в каком второй увидит результаты инструкций не важен.
Есть sequential consistency и weak consistency в исполнении инструкций. При weak consistency соседний проц может увидеть присвоение Х=1 после того как первый выполнит if (Y == 1), в абсолютном времени. Т.е. для первого проца порядок в каком второй увидит результаты инструкций не важен.
-
- Уже с Приветом
- Posts: 15475
- Joined: 27 Sep 2007 22:53
Re: Индусские программисты и индусский код
Это вы про знак наверное имеете ввиду.Alexandr wrote:на little endian нет, т.е. на всех x86 (собственно тем little endian и хорош )Flash-04 wrote:хм... должно "усечь", т.е. ноль получить как нефиг делать.
это если bool это не bool, а char или еще что
если bool это bool, то должно быть нормально в любом случае
на big endian архитектурах, для bool pre-c99, будет ноль
#include <stdio.h>
#define bool char
bool f() {
int i = 0x0100;
return i;
}
int main()
{
if(f()) {
printf("true\n");
} else {
printf("false\n");
}
return 0;
}
Спокойно усекает до 0
-
- Уже с Приветом
- Posts: 3647
- Joined: 23 May 2010 15:10
Re: Индусские программисты и индусский код
поправлю, не не видно, а видно, но в порядке отличном от program order (исполняющий процессор видит чтения записи всегда в program order). Ну а что может реодериться - зависит от платформы, на x86 только read after write, на alpha - всеcrypto5 wrote:Да нет, присвоение в одном потоке может быть не видно из другого потока. В джаве для таких случаев переменную обозначают как volatile и всякие Atomic* придуманы.АццкоМото wrote:Дык. Если последовательность соблюдается строго, то как ни верти, а минимум одна единичка будет напечатана. Если нет - могут быть два нолика. Как-то так.crypto5 wrote:Можете привести пример как?АццкоМото wrote:Влияет, очевидноcrypto5 wrote: Ну и помоему даже если так, это на результат не влияет.
volatile и interlocked - это не совсем одно и то же (я сейчас говорю не об InterlockedIncrement и им подобным)
как так JVM уже имеет свою модель памяти (как и C#), то volatile уже генерит memory fences. Так что чтение запись можно делать и без Interlocked. Более того, даже не во всех случаях нужен volatile, а только в тех случаях, если нам важен порядок чтения/записи
на C# можно обойтись и без volatile, так как там есть метод MemoryBarrier
InterlockedXXX тоже могут заменять барьер памяти банально по тому, что InterlockedXXX операции сбрасывают содержимое буферов записи на процессоре прежде, чем что-то записать и а также обрабатывают invalidation queues на кеше, прежде чем прочить что-то из этой кеш-линии
собственно на старых процессорах, барьер был реализован как
Code: Select all
lock; xadd $0, $0(%%esp) // по сути ничего не делает
-
- Уже с Приветом
- Posts: 3647
- Joined: 23 May 2010 15:10
Re: Индусские программисты и индусский код
поспоришь, в Java, как и в C#, как и в C++, всегда можно атомарно прочитать или записать, если размер типа меньше либо равен разрядности шины (проще говоря, размеру регистра), если правильно выравнено, что для простых типов всегда так и для C++ и для C# и для Java. (правда в отличии от C++ на C# и Java long не гарантирован atomic, чтобы не было разницы между 32 разрядной JVM и 64 разрядной)crypto5 wrote:С этим не поспоришьАццкоМото wrote:Ну в джаве и операции не атомарные. Если представить себе сферический одноядерный контупер с переключением контекста промеж потоков, общей памятью и атомарными операциями - то получается разница. каждый дополнительный уровень абстракции будет только добавлять пачку "да, но если ***, то все-таки нет"crypto5 wrote: Да нет, присвоение в одном потоке может быть не видно из другого потока. В джаве для таких случаев переменную обозначают как volatile и всякие Atomic* придуманы.
т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlocked
конечно операции: чтение + последующая запись, чтение + изменение + запись не атомарны
-
- Уже с Приветом
- Posts: 4637
- Joined: 24 Oct 2009 01:38
- Location: Chicago ;-) -> SFBA!
Re: Индусские программисты и индусский код
Что вы вкладываете в слово "могу"? инт на 32 разрядной платформе всегда атомарно пишется? Или нужны какие то дополнительные телодвижения?Alexandr wrote:т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlockedcrypto5 wrote:С этим не поспоришьАццкоМото wrote:Ну в джаве и операции не атомарные. Если представить себе сферический одноядерный контупер с переключением контекста промеж потоков, общей памятью и атомарными операциями - то получается разница. каждый дополнительный уровень абстракции будет только добавлять пачку "да, но если ***, то все-таки нет"crypto5 wrote: Да нет, присвоение в одном потоке может быть не видно из другого потока. В джаве для таких случаев переменную обозначают как volatile и всякие Atomic* придуманы.
И что такое здесь "атомарно пишется"?
Last edited by crypto5 on 30 Jan 2013 22:26, edited 1 time in total.
In vino Veritas!
-
- Уже с Приветом
- Posts: 3647
- Joined: 23 May 2010 15:10
Re: Индусские программисты и индусский код
сейчас "все" процессоры weak consistency с точки зрения памяти, вопрос только в том, насколько weak, например на альфе (alpha) могут просто волшебные чудеса происходить, а на x86 только stores reordered after loadsDweller wrote:добавил:
Есть sequential consistency и weak consistency в исполнении инструкций. При weak consistency соседний проц может увидеть присвоение Х=1 после того как первый выполнит if (Y == 1), в абсолютном времени. Т.е. для первого проца порядок в каком второй увидит результаты инструкций не важен.
-
- Уже с Приветом
- Posts: 3647
- Joined: 23 May 2010 15:10
Re: Индусские программисты и индусский код
скажем так: всегда атомарно, если выравнен на границе слова. По умолчанию - это всегда так: что в C++ (до C++11 вообще понятия memory consistency model не существовало), что в C#, что в Javacrypto5 wrote:Что вы вкладываете в слово "могу"? инт на 32 разрядной платформе всегда атомарно читается? Или нужны какие то дополнительные телодвижения?Alexandr wrote:т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlockedcrypto5 wrote:С этим не поспоришьАццкоМото wrote:Ну в джаве и операции не атомарные. Если представить себе сферический одноядерный контупер с переключением контекста промеж потоков, общей памятью и атомарными операциями - то получается разница. каждый дополнительный уровень абстракции будет только добавлять пачку "да, но если ***, то все-таки нет"crypto5 wrote: Да нет, присвоение в одном потоке может быть не видно из другого потока. В джаве для таких случаев переменную обозначают как volatile и всякие Atomic* придуманы.
но можно руками добиться того, чтобы оно не было выравнено правильно (один кусок будет на одной строке кеша, другой на другой), тогда для чтения или записи нужно выполнить 2 чтения (сейчас процессоры сами работают с невыравненными данными, скорее всего операция все равно не атомарна, так как пока читает сам процессор с одной строки, вторая может быть в кеше другого процессора и туда что-то пишут)
вот цитата из CLI Specification:
в Java шарманка подобная"A conforming CLI shall guarantee that read and write access to properly aligned memory locations no larger than the native word size is atomic when all the write accesses to a location are the same size."
т.е. если вам нужно атомарно записать или прочитать int или меньше, то можно просто писать как обычную переменную, если вам не важна последовательность (то о чем сейчас говорили - memory reordering)
Last edited by Alexandr on 30 Jan 2013 22:32, edited 1 time in total.
-
- Уже с Приветом
- Posts: 15242
- Joined: 01 Mar 2007 05:18
- Location: VVO->ORD->DFW->SFO->DFW->PDX
Re: Индусские программисты и индусский код
Смотреть на выделенное и фтыкать тут: http://lurkmore.to/%D0%92%D0%B7%D0%B0%D ... 1%84%D1%8BAlexandr wrote: поспоришь, в Java, как и в C#, как и в C++, всегда можно атомарно прочитать или записать, если размер типа меньше либо равен разрядности шины (проще говоря, размеру регистра), если правильно выравнено, что для простых типов всегда так и для C++ и для C# и для Java. (правда в отличии от C++ на C# и Java long не гарантирован atomic, чтобы не было разницы между 32 разрядной JVM и 64 разрядной)
т.е. грубо говоря int на 32 разрядной платформе я могу атомарно записать и прочитать без всяких volatile и interlocked
конечно операции: чтение + последующая запись, чтение + изменение + запись не атомарны
Мат на форуме запрещен, блдж!