А ка проверить число на ченость, есть такая функция, мол четное число или нет.

Nuzur
Чётное - если делится на 2.

Код

if (my_digit % 2 == 0) // если чётное - остаток от деления на 2 должен быть нулём {    is_parity = true;    // переменная определяющая, чётное число или нет. true - чётное, false -  нечетное }

Спасибо, плюсик не могу поставить

Поставил.

Если оно (число) целое, то просто проверить самый первый бит

Код

if ( value & 1 ) {  // нечетное } else {  // четное }

Вот, пару функций:

Код

// проверка на нечетность template<class T> inline bool oddnumber(T value) {  return (value & 1); } // проверка на четность template<class T> inline bool evennumber(T value) {  return !(value & 1); }

З.Ы.:

Цитата

Чётное - если делится на 2.

Неа. Четность - если установлен самый первый бит в единицу

Это сообщение отредактировал(а) bel_nikita - 22.12.2004, 23:36

Странно, если, например, разложить число 23, то получится такой вид: 10111. И где тут чётность? 

правый бит 1 => нечетный если 0 - четный
 

А если у меня процессор не с двоичной логикой, а с троичной? 

Сдай его в музей 

По идее там чтото вроде проверки последнего значения на 1 (тогда нечётный). Но операции & что там дадут?

Вообще процессоры у нас вроде с четвероичной логикой:

true
false
undefined
buss error

Добавлено @ 11:38 
 Хотя  undefined может и не учитываться.. 

проверку и дадут 

if( value % 2 )
{
  value -> нечетное
}
else
{
  value -> четное
} 

!(value & 1) - сработает быстрее, чем value % 2, и ни чем не хуже 

С двузначной логикой: true (1) и false (0). undefined и buss error не относятся к логике процессора.


Зато с (value%2==0) понятнее что делается, да и не особо медленне чем c (value&1).    

Это сообщение отредактировал(а) ptr - 21.7.2006, 13:22

На 32 битном процессоре мрдленнее в 32 раза 




Относятся конечно. На undefined он кладёт, но ошибки он должен логически обрабатывать(что будет, если на бусе одновременно 1 и 0 ?). Это же обыкновенный микрочип. Просто доступа к тий логике у программиста нет. Она на аппаратном уровне. 

модуль(%) - есть ни что иное, как арифметическое умножение на логарифм правой части выражения по основанию 2, так что операции (% 2) и (& 1) равнозначны, а самый младший бит является признаком нечетного числа (его еще называют parity), т.к. он инвертируется на каждый экземпляр последовательного числового ряда. 

Операции то равнозначные, но реализации различны. И поэтому "&" - выигрывает у "%" в проверке на четность.

З.Ы: Для тех кто в танке: посмотрите на реализацию % и & через дизассемблер... 

0042602E  mov         dword ptr [a],64h 
00426035  mov         eax,dword ptr [a] 
00426038  and         eax,80000001h 
0042603D  jns         WinMain+34h (426044h) 



0042602E  mov         dword ptr [a],64h 
00426035  mov         eax,dword ptr [a] 
00426038  and         eax,1 
0042603B  jne         WinMain+44h (426054h) 


Думаю пояснять ни чего не надо?!

Добавлено @ 20:03 
единственное, в чем преимущество (%), так в том, что проблем с unsigned у вас никогда не будет, поэтому (%) корректнее чем (&) 

Это медленнее, чем 

  


Все зависит от степени привыкания    

Неа, в твоем примере мы видим оптимизацию компилятора, а никак не реализацию  


З.Ы.: для танкистов:
 

Слушай, танкист! не морочь людям мозги. Посмотри на свой же код! 

против:
Что называется - почувствуйте разницу. 

ну и ты хоть взгляни, может найдешь отличия   


З.Ы.: для тех, кто еще остается в танке - вместо int подставть unsigned ...
 

Если танкист пишет только в дебаге, то мне пора на пенсию )
Вот релиз, проверка HINSTANCE на четность:



00403169  mov         edi,dword ptr [esp+10h] 
0040316D  mov         esi,edi 
0040316F  and         esi,1 
00403172  je          WinMain+1Eh (40317Eh) 
        ::MessageBox(0,0,0,0);
00403174  push        0    
00403176  push        0    
00403178  push        0    
0040317A  push        0    
0040317C  call        ebx  
    }
    if(a&1){
0040317E  test        esi,esi 
00403180  je          WinMain+2Ch (40318Ch) 
        ::MessageBox(0,0,0,0);
00403182  push        0    
00403184  push        0    
00403186  push        0    
00403188  push        0    
0040318A  call        ebx  
    }

Добавлено @ 11:27 
Глупо спорить на тему скорости с оптимизацией VS от самой Microsoft ) 

GremlinProg, а кроме VS других компилеров не существует? % есть остаток от деления и если бы компилер делал то, что ему говорят (А многие так и делают), то провёл бы деление и взял остаток. Ваш промер есть оптимизация кода конкретного компилера и для общего случая он (как пример) не годится.

Точно так же х/2 компилеры оптимизуют в х>>1. Но говорить, что в общем случае деление по скорости совпадает со сдвигом на 1 - бесмыссленно.  

Проверь на другом компиляторе, чтобы удостовериться в своей правоте.

Деление целочисленных есть ни что иное, как сдвиг вправо, а остаток от деления - правая часть результата этого сдвига. Зачем делить, если можно просто взять этот остаток Эндом? Оптимизация в любом компиляторе это должна учитывать, иначе на что она нужна, такая оптимизация?
А по поводу 
заблуждаешься: код высокого уровня для того и нужен, чтобы абстрагировать задачу от конкретной её реализации на конкретном компиляторе, поэтому, если необходимо вычислить остаток, то и нужно писать (%), а не (&), а компилятор сам знает, что он должен сделать быстрее, а что - медленнее. Может быть это и прописные истины, но почему-то многие о них забывают.  

Уровень кода тут не причём. Тем более С (о котором мы сейчас в общем-то и говорим). Например освобождение памяти прямо таки опускает на землю абстрактность любой задачи.
Вообще С тем и примечателен, что даёт делать то, что угодно (в отличии он Явы например). И если я хочу, чтобы он делил, он должен делить. 
И компилеров существует масса и никто не может со 100% увереностью сказать во что превратиться его код, если он не будет вручную навязывать это компилятору сам.

Другое дело, что оптимизатор на многих компилерах по умолчанию включен. Это с идеалогической точки зрения как раз ошибочный подход. 

где-то в этой фразе должно быть словосочетание "степень двойки"... 

ps. так и не смог уловить предмет спора. такое впечатление что "каждый о своем"...  

dumb, похоже прав: я тут говорю о "бессмертном" коде, т.е. код живет и развивается до тех пор, пока его понимают, и как бы вы не издевались над ним, как бы не ускоряли его выполнение - код умирает сразу, если хотя бы часть его становится нечитабельной. sergej.z мешает две абсолютно разные вещи: моделирование и оптимизация. Как известно, моделирование - первостепенная задача - это есть сам процесс создания программы, на этом этапе закладываются основы её функционирования. А оптимизация - второстепенная задача, которая не всегда оправдывает затраты: оптимизировать можно вечность, а результат будет скрыт от глаз пользователя за толщей интерфейсов операционной системы, и даже не важно какой. 

Предмет в том, что GremlinProg утверждаетм что х%2 и х&1 - одинаковые операции.
Я же придерживаюсь мнения, что это может быть верно, но после оптимизации на конкретном компиляторе. 

не совсем так, я пытался объяснить, почему нельзя использовать такие оптимизации в коде. И показал пример, который визуально указывает на разные действия, в данном случае модуль и умножение, а практически делает одно и то же. Объяснил, почему для разработчика так важно знать, что действительно происходит в коде, т.е. что он имел ввиду, когда писал код. Если над проектом работает один программист, то, конечно, можно положиться на его память и надеяться на то, что через пару недель, месяцев, лет он таки вспомнит свои действия. Но, если над проектом работает несколько программистов, то бишь группа, тогда с такими подходами, как у sergej.z, сработаться им будет крайне сложно.

Моя позиция такая: если хочешь оптимизировать - используй оптимизацию компилятора. Если оптимизация не устраивает - меняй компилятор и учи язык. Почти все компиляторы, которые только существуют имеют возможность работать в нескольких режимах оптимизации. Суть даже не в том, нужна оптимтзация или нет, оптимизация присутствует всегда, разница лишь в её детальности. 

Какими подходами????
Если программисту не очевидно, что х&1 дают последний бит, то с ним в любом случае сработаться будет тяжело.
 

Зри в корень! Отсюда все и начинается. Думаешь ты один такой? ) Наивный...

Оптимизация типа х&1 или (!(id+1)) и т.п. - это болезнь, от которой нужно поскорее избавляться, если ты хочешь прославиться программистом. Все через неё проходят, ты не первый. Возможно меня поддержат профессионалы, если увидят.

До сих пор вижу код, который нспещрен примочками типа встроенного ассемблера, сажусь разбирать - чушь полнейшая, которая либо заменяется парой строк на си, либо работает только при ограничениях на оптимизацию, (т.е. из за долбанного куска асма приходится отказываться от скорости исполнения остального кода). Раньше любой школьник, который хоть мало-мальски интересовался кодингом мог подглядеть, содрать, украсть очередную примочку и всем хвастаться: какой он молодец. Но этот бум давно прошел, сейчас рынок труда не терпит такого издевательства, такие грамотеи отсеиваются элементарной конкуренцией, а програмное обеспечение уже давно ушло за рамки асма, невозможно сейчас просто даже вручную посчитать элементарную програмку с использованием различных наворотов типа ASP, с импортом библиотек от различных производителей, даже если ты супер-пупер классно этот асм знаешь. Поэтому большое значение имеет компилятор, которым пользуется разработчик; насколько велики его возможности оптимизировать код; насколько перспективно его дальнейшее развитие в ногу со временем. Это все и даже больше имеет значение при разработке сегодняшнего софта. Я сделал свой выбор и не жалею.

А по поводу "очевидно", возможно, это простой пример, но когда сидишь дома, пытаешься разобраться в серьезном коде такие вот примочки тормозят процесс бывает на час-два, а то и день выпадает, например, ты используешь простую проверку на ноль, а число знаковое, оно пустое, но знак выставлен, вроде все нормально, но проверка не проходит, пока найдешь это место, потеряешь время, выясняется - просто програмер решил соптимизировать, он же не думал, что знак - тоже бит. Вот такие вот пироги бывают... Так что, зрите в корень! 

Вот, сам же говоришь оптимизация второстепенный вопорос, ну так возьми пару компиляторов и посмотри на код по-дефолту:

увидишь там операцию div   Компилятор сам ничего не знает, если не укажешь. Конечно, если пишешь под Вин калькулятор или тетрис, то можешь положиться на компилер и не знать, что у тебя творится в коде. Да и не нужно это все знать. Но когда начнешь писать, к примеру, драйвер какого-нибудь девайса, то поймешь что компилятор не панацея и не такой он "всезнающий". Весь код будет устлан вставками optimize: off/optimize: on


Если над проектом будут работать люди, которые задумываются над операциями &,|,%,  и при проверке целого на четность используют деление, то ни о каком срабатывании и речи быть не может. 

Так, налицо конфликт поколений   Может, хватит спорить?
Код типа x&1 - это не оптимизация, а привычка (со времен, когда компьютеры были большими и медленными, а компиляторы - не такими умными): думаешь "взять остаток от деления на 2", а руки сами пишут "&1". И чего ради перучиваться? Чтобы молодые "высокоуровневые" програмисты не напрягались? Так и им полезно знать кое-что о битах... В конце концов, дело вкуса.

А уж бездарный и излишне замудренный код можно написать и без всякого ассемблера. Сейчас это даже "проще", с шаблонами и TMP: смотришь битый час на код из полутора сотен шаблонных классов, пока поймешь, что аффтар просто излишне увлекается TMP.
 

GremlinProg, 
Ну-уу, если тебя вводят вступор такие операции, как  х&1 или (!(id+1)), то что же ты пишешь?   

Это сообщение отредактировал(а) bel_nikita - 24.7.2006, 14:43

GremlinProg, во первых на "ты" мы не переходили.

Во вторых если к этому делу уже серьёзно подходить, то правильно будет писать:

if is_even(x)
{
...
}

Поскольку оценивая операцию х%2 можно именно узнать, какому значению равен остаток от деления.
То что ответ 0 означает деление нацело - уже оптимизатия программиста (и по Вашей теории).
(как видим со всем можно перестарться)

Добавлено @ 14:46 
Вообще, всё зависит от определения.
Один определяет чётность отсутсвием остатка при делении на число 2, другой результатом булевой операции & переменной с числом 1.
Кто из этих двух больший проффессионал - на Вам судить.   

Неохота спорить, да и не нужно  мне это.
По DDK - это вообще отдельная тема, зря ты её трогаешь, нет еще полноценного компилятора для разработки драйверов. Могу только посоветовать хорошую книжку Солдатова Программирование драйверов Windows. Изд. 2-е, перераб. и доп. — М.: ООО "Бином-Пресс", 2004 г. — 480 с: ил. Здесь он очень хорошо расписал, что можно, а что нельзя.

Похоже ты не понял, о чем я говорил. 

Млин, а создал то простую тему с простым вопросом, возникшем в результате торможения после тяжелого вечера!
Ну вы молодцЫ конечно, начали за здравие, закончили за упокой!

ЗЫ: если вам интерестно мое мнение, хоть я в етом я уже оч сильно сомневаюсь, так вот, если вам интерестно мое мнение - то



намного красивше и читаеться с ходу, а вот вариант с & заставил на секундочку тормознуть 
Может голосование устроим? 

Earnest, похоже вы правы, согласен. Именно об этом я и говорю: время - деньги, но голова-то одна на плечах и она изредка раскалывается от излишней рьяности перспективных программистов доказать свою значимость, превосходство, показать как можно больше из того, что он знает. Это конечно не плохо, только девелопер не должен особо переживать по поводу подтверждения своей квалификации. Быть может дело в гармонах?

Добавлено @ 15:04 
Nuzur, программирование - это искусство, в нем тоже должна быть красота. 

хоть кто-то понял, о чем я битый час говорю. Молодец, садись, пять, давай зачетку )  

Это сообщение отредактировал(а) GremlinProg - 24.7.2006, 15:08

  

А я DDK и не трогаю. Причем тут DDK и книжка?   Профессионалы(про коих ты тут упомянул) пишут не только под Windows'ом и VC 7.1   

Профессия в первую очередь подтверждается временем, это я и имел в виду под словом "профессионал".


похоже, ты вообще ни чего не трогаешь, только шум поднимаешь.


про это речи не было , а книжку я посоветовал потому, что в нех понятным языком разъяснены особенности разработки драйверов конкретно в VS и конкретно для Windows. По моему я ни кого не дезинформировал. 

Да господа, как сказал Nuzur, начали за здравие, а закончили за упокой. Вы здесь обсуждаете разные привычки написания кода. Кому-то проще и понятнее писать x&1, кому-то x%2. Не вижу смысла этого спора, всё равно все останутся при своём мнении.


Красота дело относительное. Кому-то нравится больше x%2, кому-то x&1  . 


Код прежде всего должен быть понятным, а эффективность это дело тоже относительное  . Иногда проще поставить рядом ещё один ящик и пусть себе считает. То, что сегодня  кажется медленным завтра уже может не иметь значения. Оптимизация (ручная) нужна там, где она действительно нужна   (системное программирование, математические расчёты или там где она важна для работы программы), а не где попало.      

Это сообщение отредактировал(а) ptr - 24.7.2006, 15:39

Именно, ptr. Вот ведь нашли мировую проблему, о чем спорить, да еще и на личности переходить! 

GremlinProg, я понимаю, что ты хотел сказать: только ведь нет абсолютного критерия: что русскому красиво, то немцу смерть.
(Это я ни в коем случае не намекаю на место жительства sergej.z, просто пословица такая...   ) 
Т.е. один программист увидит трехэажный boost::bind и скажет "вау!", а другой скажет: "убить бы гада, который это написал". Да что там говорить: чужой код, в котором приходится разбираться, почти всегда раздражает: не алгоритмом, так именами, не именами так расстановкой скобочек... Не надо злится, надо просто сказать себе: "что же делать, не все же такие умные как я, пишут как могут, и на том спасибо..."   

Модераторы перенесите тему в релизиозные войны пожалуйста  

Не вижу ничего плохого в спорах. На то он и форум. (Переубедите меня)
Вот пример, что можно вдоволь поспорить (к тому же "на религиозную тему"), каждому остаться при своём мнении абсолютно не переходя никакие рамки приличия и остаться друзьями.
http://forum.vingrad.ru/index.php?showtopic=35267


Ну это уже жизнь и эволюция темы. Одному человеку она не подвластна  .(Если за рамки приличия не выходит)
Узнал ответ на свой вопрос? Вот и отлично! А во что она превратится после этого - решают её участники.

 

Earnest, согласен )
...тогда я из того числа, кто скажет

разумеется, у stl смои минусы, но есть и плюсы, тем не менее.
Видишь, по большому счету не в красоте дело, поддержу ptr:


разобрать код можно всегда, вопрос сходится только ко времени, которое приходится убивать на это неблагодарное дело. А вообще, в этом плане я не замечал у нас ни каких институтов: учат в основном как писать код, но совершенно не учат как правильно писать код. Вот буржуи - молодцы, они-то уже давно применяют стереотипы командной разработки. Вот, например Фредерик П.Брукс, со своим "Мифический человеко-месяц" какого года книжка, а сколько было споров по поводу статьи "Серебряной пули нет", и когда!!! 1987год. А сколько еще таких книг: "Экстремальное программиррование", "Рефакторинг"... И все это нацелено главным образом на то, чтобы можно было в конкретно детерминировать работу девелопера, и можно было его заменить или добавить в группу, дабы увеличить профессиональную мощь. Мало того, книгами и статьями дело не обошлось, написали не мало софта "для правильного программирования", те же Small Talk, но там жава. На других языках тоже какие-то есть. Бери, пользуйся. Сейчас и в россии тоже в плане софта есть разработки. Только в обучении специалистов дело похоже так и не движется. Печально. Ввели курсы по защите - круто, а что защищать, писать-то еще не научились. 

Не.. не возьмусь   Хотя насчет полезности таких споров - тоже вопрос спорный...
Ну разве что, если удовольствие от процесса получаешь... Только пусть некоторые (не будем говорить кто, хотя это был слоненок   ) спрячут зубы и когти, а то я прямо вижу эту бутылку, в которую они лезут...
Так что, если "в рамках приличий" и "остаться друзьями" - спорьте на здоровье.   
 

Полезность каждый определяет для себя  Кто полезным не считает - не спорит. 

Кони люди смешались  . DDK, STL, SmallTalk, Java, стили, асм, профессионализм и т.д.

Мне кажется,  что ответ дан исчерпывающий. Вопрос прозвучал: "Проверка на чётность, MS VC ++ 6.0". Приведены примеры и пояснения. Что касается быстродействия, так вот при использовании unsigned value % 2, этот самый шестой вставляет инструкцию div будь то релиз или дебаг.

З.Ы.: Что касается человеко-часов, то боже упаси работать с человеком стучащем без рабору по клаве и набирающем 5000 строк кода за 8 часов. Как правило, такой код восприимчив к окружающей среде и погоде   

Ага, только код от этого у них лучше не становится. Да возьми хотя бы примеры с codeproject (ну не все подряд, конечно). Или какой-нибудь, не дай господи, код университетской разработки: просто поражаешься иногда контрасту между красотой и мощностью идеи, и убогостью реализации. Но за идею спасибо. А код мы и сами напишем, чего там. Наверное, это просто разными местами мозга делается.   
Кстати, насчет стереотипов командной разработки: это только сверху, бантик в виде стандартизации описания и т.д. А внутри - дикие по величине кейсы и прочее. За "красоту" кода не платят, плятят за рабочую программу. 

Золотые слова!   + 

Точно, затягивает. Особенно когда перешли к битве за красоту - ну как тут удержаться  

Это можно сделать только применяя прогрессивный метод "копи-паст". Говорят, индусы так пишут. И ничего, весь мир у них отоваривается.  

Прежде чем пойдёт много буковок, напишу что в исходниках явы встречал компромисный вариант.
вот такой вот примерно

  






Кстати Эти инструкции не эквивалентны. И они возвращают разный результат для отрицательных чисел.







Многие? Это большая часть из прошлого века вероятно.
Вот например есть файл

И вот результат
bcc 5.5. Он не сделал div. 
icl 8.0. Он не сделал div. 
dmc 8.42. Он не сделал div. 
cl из VS2003. не сделал div. 
cl из VC7. не сделал div. 

флаги оптимизации не были выстановлены вообще. компиляторы - не из самых свежих и лучших, а итог... 0 компиляторов сделали деление для получения mod 2. 
(больше компиляторов под виндой у меня нет. 




Брэк. Это уже совсем оффтопик.


  

Это сообщение отредактировал(а) Mayk - 24.7.2006, 17:12

Это уже зависит от мастерства.
Вот, например сайт цита http://citforum.iubip.ru/SE/project/, где одно время были предложены простые правила, на которые опирается сама идея экстремального программирования. Т.е. суть заключается именно в объектно-ориентированном подходе, а материал изложен очень просто: маленькими правилами, которые если даже просто интуитивно применять, приведут к упорядочиванию проекта, в целом, причем не конкретного, а любого проекта. Это наподобие того, что художником не обязательно рождаться, любого можно научить им быть. Сейчас уже не знаю, не заходил, но раньше там большой раздел был, были разделы паттерного программирования, отдельно расписан каждый паттерн и места, где его можно использовать, что-то типа stl, только не ограниченный фантазией самого девелопера.

Добавлено @ 17:27 
Mayk, отнюдь - это первые источники, которые я заметил, в которых явно демонстрируется то, что ты здесь правильно изложил, а по сути подтвердил:
 

Mayk, Ну, раз имеешь столько компиляторов под рукой  , то, пожалуйста, попробуй вот, так :  int main(uinsigned int argc){return argc % 2;}. Думаю, что увидишь div  

Если не влом, еще, вот так, попробуй:

 

Не везде и не всегда, но здесь чуть хуже.

bcc и icl и dmc соптимизировали до and eax, 1  сразу же.

visual clы оконфузились. Правда /O2 и /O1 даже вправило им мозги на место, и в асме появился and eax, 1.



Здесь div появился только в visual c и ТОЛЬКО при /O1 (/О2 и без /O divов не было)

В аттаче сырцы(dmc пришлось пускать через дизасм. для того чтобы легко найти во всём листинге main(), в теле функции были введены константы типа 0x1234 )

Вывод. Оптимизаторы рулят.

ЗЫ. А вообще в современных условиях иногда можно не то что %2 писать, но даже по многу раз читать одни и те же файлы с винта - всё равно они кэшируются ОСей =) 

Присоединённый файл ( Кол-во скачиваний: 3 )
 tests.rar.txt 67,61 Kb

[QUOTE=sergej.z,21.7.2006,  17:42]
"3-е состояние" (высокоимпедансное) означает, что активные устройства (формирующие уровень сигнала на шине) от шины отключены. Какой электрический сигнал в это время будет а шине - одному аллаху известно, но если проц задумает его прочитать, то вполне себе получит какое-то случайное значение. А может быть и не случайное, а заранее определённое - в зависимости от типа логики.

Одновременно 0 и 1 - это вообще нонсенс какой-то. Как может быть одновременно 0.5В и 3В?
Кто-то всегда победит. У процессорных шин архитектуры IBM PC победит 0. Т.е. если одновременно два устройства выдадут на шину - одно 0, а другое 1, то получится 0 (электрически так получается).

Так что как-раз как "микрочип" процессор всегда считает с шины или 0 или 1.
Никакого 3-го состояния он не увидит.
И тем более "одновременно 0 и 1".

Добавлено @ 21:01 
Я тут немного в сторону скажу, ничего? 


"3-е состояние" шины (высокоимпедансное) означает, что активные устройства (формирующие уровень сигнала на шине) от неё отключены. Какой электрический сигнал в это время будет на шине - одному аллаху известно, но если проц задумает его прочитать, то вполне себе получит какое-то случайное значение. А может быть и не случайное, а заранее определённое - в зависимости от типа логики.

Одновременные 0 и 1 - это вообще нонсенс какой-то. Как может быть одновременно 0.5В и 3В?
Кто-то всегда победит. У процессорных шин архитектуры IBM PC победит 0. Т.е. если одновременно два устройства выдадут на шину - одно 0, а другое 1, то получится 0 (электрически так получается).

Так что как-раз как "микрочип" процессор всегда считает с шины или 0 или 1.
Никакого 3-го состояния он не увидит.
И тем более "одновременно 0 и 1".
 

Если бы микрочипы работали по принципу "одному аллаху известно" , вряд ли чтото путное получилось бы. Ошибки они очень часты и логикой значение (как Вы правильно сказали) должна быть определено. Поэтому просто  true/false  В некоторых случаях недостаточно. Поэтому появляются троичнай, четв, итд. логики. 

Получается Bus Error. Включается высокоомное сопротивление. Во всяком случе процессор работать "не замечая" ошибки не будет.

Конечно процессор - более менее отполировання система. Но если Вам доводилось программить на VHDL  Вы понимаете, что послать на бус 1 и 0 одновременно особого труда не составляет и что система работать при этом не будет. И кстати как раз undefined при программировании FPGA учитывается.

 

Вообще же я имел ввиду процессоры, которые основаны не на классической двоичной булевой логике, а на троичной  .

    

Это сообщение отредактировал(а) ptr - 26.7.2006, 13:17

Ну вот например NULL Convention Logic использует троичную логику (NULL всегда побеждает).
Мы конечно немного о разных логиках говорим  

Я это уже понял давно    .


NULL Convention Logic может быть и четырехзначной.  

Это сообщение отредактировал(а) ptr - 26.7.2006, 14:48

"Неопределённое" (высокоимпедансное) состояние шины означает, что устройство, которое может формировать сигнал, отключено от шины.
Но это не значит, что процессор, попытайся он прочитать шину, получит какое-то "неопределённое" значение. У него такое и сохранить-то негде! Он всегда прочитает или 0 или 1.
В архитектуре IBM PC, сдаётся мне, это будет 1, т.к. 0 там - отсутствие напряжения, а в высокоимпедансном состоянии потенциал на шине "подтягивается" резисторами к напряжению питания.

"Одновременный 0 и 1" - это вообще непонятно что. Как вы себе представляете одновременное наличие на проводе, например, 0.5 и 3.5 В?
Даже если два устройства попытаются выдать одновременно 0 или 1, процессор всё-равно прочитает что-то одно, даже если потенциал на шине будет какой-то неопределённый "посередине" между 0 и 1, а скорее всего, в зависимости от архитектуры, какое-то значение "победит": в архитектуре IBM PC "победит" 0.     

Это сообщение отредактировал(а) ZeusAtVingrad - 27.7.2006, 09:53

Имеется в виду не напряжение, а именно логика. То есть определение состояния при одновременном 0 и 1 (логических) сигналах. Что там за напряжение роли не играет. 

В тех постах на которые я отвечал речь как-раз зашла уже о процессоре как чипе, об "аппаратной логике недоступной программисту".
А коли так, то и ответ я сформулировал в этом же ключе.

А откуда в процессоре берётся "одновременный 0 и 1"? Где он его "считывает"? Какой командой, в каком регистре?