OSDev

В злонамеренности (а точнее в целенаправленном намерении отказаться от мобильности, т.е. возможности выполнения простого переноса ОС на другой комп или носитель, возможности использования LiveCD - все это есть, но реализовано через... в том числе и самой MS). А еще в "особенностях" архитектуры, из-за которых отчасти мобильность в последствии и реализовывалась через...

Естественно под "реально необходимым детектом" я подразумевал второе, т.к. первое обычно выполняется в любом случае. Кроме того, думаю, не нужно объяснять, что быстрый поиск может быть реализован и в большой базе, быстрое извлечение отдельных небольших (по сравнению с целым) частей тоже. Я не говорю, что нужно всегда использовать автодетект, а говорю, что такая возможность должна быть штатной и использоваться при необходимости.

Я говорил не про программу установки винды, а про "нормальную" программу установки.

Си не является языком программирования высокого уровня. Он такого же уровня, что и Ассемблер. Тот, кто умеет программировать на Ассемблере без ошибок, тот с таким же успехом напишет программу без ошибок на Си, потому что принципы те же.

На момент появления языка Си, все программисты были ассемблерщиками по определению. Поэтому программированием на Си занимались люди - знатоки Ассемблера с родственной концепцией. В результате на первых порах производился код приемлемого качества. Уверен, что первые программные продукты на Си не были подвержены современным проблемам глупейших ошибок. Основной проблемой являлся скорее сырость самого языка Си. По прошествии длительного времени, когда Си стал заменять Ассемблер, созданием программ всё больше стали заниматься программисты не знающие Ассемблера, не имеющие навыков низкоуровневого программирования - это при том, что Си повсеместно ошибочно назывался языком высокого уровня. В неправильном позиционировании Си и есть катастрофичность его положения. Для умения программировать на Си совершенно необходимо знать Ассемблер, потому что это по большому счёту высокоуровневой Ассемблер. А во всех методических материалах по Си про это нет даже намёка (изза ошибочной классификации языка - как я уже сказал).

Я хочу сказать, что Си является хорошим языком низкого уровня.

У игр проблема не столько с производительностью центральных процессоров, сколько с графикой. Даже самые мощные в этом плане АРМы соответствуют ПКшным видюхам в лучшем случае 6-7-летней давности. Соответственно, графикой уровня Кризиса на АРМовских устройствах пока даже пахнуть не может: не та аппаратная база. А вот с ЦП, в общем-то, особых проблем нет: старшие АРМы (ядра Cortex-A15 и даже более ранние) уже вполне способны тянуть игры вроде Кризиса, был бы подходящий графический процессор... Но в мобильных сегментах подходящей мощности в обозримом будущем не будет: слишком большое энергопотребление у графического процессора, причём объясняемое не уродской архитектурой, как в случае с центральным ИА-32, а спецификой задачи, огромным числом исполнительных блоков (благодаря чему достигается высокая производительность) и т.д. и т.п.

В общем, полностью вытеснить ПК на ИА-32 даже из дома в обозримом будущем АРМу не удастся, но процесс будет идти, причём главным тормозом будет всё ж отсутствие вменяемой ОС.



Жирная архитектура, изначально призванная "убить" ИА-32 в персоналках (откуда и её название), в том числе благодаря относительной лёгкости эмуляции системы команд ИА-32 на ПоверПЦ, что теоретически позволяло использовать ПоверПЦ вместо ИА-32 с минимальными усилиями. Попытка, как известно, провалилась, ну а недостатки процессора (переусложнённость и т.п.) никуда не делись. В общем, постепенно умирает, как и большинство других архитектур.

Из других пока живых "мощных" архитектур (т.е. без всяких там 8- и 16-разрядных) можно упомянуть следующие.

MIPS -- процессор, близкий к классическому RISC (в отличие от современных АРМов, у которых от РИСКа мало что осталось, кроме названия). Давно скорей мертва, чем жива, однако по инерции продолжает довольно широко применяться (ну а что? процессоры выпускаются, ПО создано полно, так чего не использовать, если нет сильных стимулов переходить на что-то иное?).

SPARC -- один из наиболее мощных RISCов, созданный фирмой Sun. Правда, уже давно самые мощные СПАРКи выпускают японцы. Саму Сан недавно купил Оракл. По всей вероятности, довольно быстро сойдёт со сцены: в качестве числодробилок сейчас всё чаще применяются графические процессоры, ну а для обычного центрального слишком сложен и громоздок (одних регистров общего назначения, если склероз не изменяет, 160 штук).

IA-64, они же Itanium -- весьма интересная архитектура, совместо разработанная Интелом и ХулитПаккардом (HP которая). Рассматривалась как "убийца" ИА-32 -- не все ж в Интеле идиоты, и они прекрасно осознают, что ИА-32 плоха. Тем не менее, коммерчески проект оказался неуспешным -- не в последнюю очередь из-за сложности программирования под такую архитектуру и отсутствия эффективных компиляторов. Плюс высокая цена (которая может быть снижена только при массовом выпуске, а его можно достичь, если будет большой спрос, а он возможен, если цена будет невысока... в общем, тупик).

zArchitecture -- IBMовская наследница System/360, анонсированной ещё в 1964 году. До сих пор жива и умирать вроде как не собирается. Несмотря на почтенный возраст (вот уж кто живее всех живых, если смотреть на этот критерий!) и многочисленные расширения архитектуры (в том числе "переезд" на 64 бита -- несколько десятилетий эти машины были только 32-разрядными), до сих пор сохраняет приличную "стройность" и бинарную совместимость с прикладным (но не системным) кодом образца середины 1960-х годов. Поставить дома можно, если имеется пара сотен тысяч лишних баксов :)

Пожалуй, на этом всё. Остальные архитектуры либо умерли (например, прекрасный VAX-11 или мотороловские микропроцессоры, которые технически вчистую обходили интеловские в 1980-х годах), либо очень специализированы и малоизвестны, а посему не представляют какого-либо интереса для подавляющего большинства ИТ-специалистов.



Откуда такая уверенность? Агентурные сведения? :)



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

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



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



Ещё одна порция идиотизма. К моменту появления языка Си (т.е. где-то 1971-73 год) уже не меньше 15 лет существовали языки высокого уровня. В частности, математические программы писались на Фортране и Алголе, экономические -- на Коболе, появился и первый универсальный язык -- ПЛ/1 (на котором была написана ОС Multics, впервые выпущенная в свет в 1969 году, т.е. за несколько лет до появления Си).



Опять бред. Количество ошибок при прочих равных (в частности, при одном и том же языке программирования) зависит от профессионализма разработчиков. В 1970-х их уровень квалификации был во много раз выше, чем сейчас -- их самих просто было много меньше, а сама работа -- сложней (не умели компутеры думать за человека, не было графических оболочек, ну а чтоб пропихнуться через командную строку, всё ж некий минимальный IQ требуется). По той же самой причине основная масса программ на Паскале/Дельфях -- жуткий быдлокод: их же пишут школьники или студенты, которые используют эти языки в процессе обучения, т.е. не имея ещё сколько-нибудь приличной квалификации. Отсюда и легенда, что на Дельфях только быдлокодить можно...



Бред. Огромное число ошибок в Унихе и его программах стало всплывать в 1980-е годы с появлением первых вирусов и червяков. Причина почти всегда была одна и та же: переполнение буфера из-за непредусмотрительности разработчиков и ненадёжности Си и его библиотеки.

SII, раньше все были ассемблерщиками, даже те кто программировал на других языках низкого уровня, таких как PL/1 и Си. Да, с этой точки зрения можно сказать, что раньше програмисты были квалифицированнее (об этом я тоже хотел сказать). Точнее, они были больше подготовлены для программирования на данных языках низкого уровня.

Разница между Ассемблером и Си только в том, что первый является машинным языком, а второй как бы эсперанто языком. Но это не принципиальная разница. Существует такой язык C-- который это показывает. Тут можно даже привести языки человеческого общения - нельзя сказать, какой язык более "высокоуровневой", русский или английский.


В википедии датой создания IP значится 1981 год, значит всё не совсем так, как Вам кажется :) Впрочем, Вы можете внести в wikipedia.net исправления и комментарии.

Снова бред. Принципиальная разница между ассемблером и абсолютно всеми другими языками -- в прямом отражении архитектуры процессора в первом и в сокрытии -- в других. Это -- единственная принцпиальная разница между языками низкого уровня (машинным кодом и ассемблером) и языками высокого уровня (всеми остальными).


В википедии датой создания IP значится 1981 год, значит всё не совсем так, как Вам кажется :) Впрочем, Вы можете внести в wikipedia.net исправления и пояснения.[/quote]

Почитали б повнимательней, что ли, а не бежали б сразу чушь писать... http://en.wikipedia.org/wiki/TCP/IP, раздел History. Пара цитат:



Перевести на русский, или сами справитесь?

Си конечно не низкоуровневый язык, но я кажется понимаю, что хотел сказать Himik. Разработчики Си преследовали цель сделать язык, сочетающий в себе возможности высокоуровневых языков и мощность ассемблера. В Си сам синтаксис языка часто подсказывает, как должна выглядеть та или иная команда на ассемблере. В языках, подобных Паскалю, таких подсказок нет вообще. В лучшем случае там срабатывает оптимизатор компилятора, в худшем генерируется крайне неэффективный код. Т.е. действительно, программируя на Си, желательно (хотя и не обязательно) знать ассемблер. А местами своеобразный синтаксис Си - это не просто результат фантазии его разработчиков, но еще и желания сделать команды, аналогичные ассемблерным (как по эффективности, так и по принципам записи), чего сейчас многие не понимают, поэтому и используют Си неправильно. Конечно синтаксис Си далеко не идеален (про Си++ я вообще молчу). Мне к примеру тоже не нравится столь малая разница между & и &&, но с другой стороны связь между этими операциями все-таки есть, использовать слово в качестве знака не желательно (тогда придется писать операнд(ы) через пробел: "and a"), а подходящих символов на роль знаков не так уж и много.

P.S. Давайте жить дружно!

Так Си почти и не скрывает архитектуру процессора. Изначально поддерживались даже разнотипные модели памяти и типы указателей. Просто он не содержит полного набора процессорных команд, и всего-то. Архитектура процессора скрывается только в C#.


Сам знаешь, что версии 0...3 это совсем другой IP, который и IP-то не назывался. Для сравнения смотри
http://tools.ietf.org/html/rfc791

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



Это утверждение однозначно неверно во всех случаях, кроме прямой трансляции из исходного кода на языке высокого уровня в машинный код или ассемблер, что на практике применяется очень редко из-за плохого качества результата (ведь транслятор тогда не может выполнить даже простейшие оптимизации вроде выноса операций из цикла). Если же трансляция не прямая (а сейчас это всегда так, да и в 1970-е годы и даже раньше -- тоже), качество кода, порождаемого транслятором "обычного" языка высокого уровня (а и Паскаль, и Си, и основная масса других языков являются "обычными", не содержащими неких труднокомпилируемых конструкций), будет зависеть исключительно от качества транслятора, но никак не от самого языка. При разборе исходной программы в любом случае получается некое внутреннее представление, принципиально не отличающееся для разных исходных языков, и кодогенерация ведётся уже на основе этого внутреннего представления. В частности, именно по этой причине GCC даёт абсолютно одинаковый код для алгоритмически одной и той же программы, написанной на Си или на Аде: соответствующий фронт-энд переводит исходный текст, написанный на этих языках, во внутреннее представление, а вся остальная обработка ведётся уже только с внутренним представлением программы.



На самом деле, единственное, что приходит в голову из такого "желания", если оно действительно имело место -- это возможность постинкремента или преддекремента индекса при обращении к элементам массива:



Если предположить, что в регистр R0 занесён адрес первого/следующего за последним элемента массива m, а в регистр R1 -- значение переменной b, и что элементы массива имеют размер слово (2 байта), то каждый из этих операторов может быть переведён в одну инструкцию PDP-11:



Никаких других подобных оптимизаций средствами самого языка высокого уровня для PDP-11 сделать невозможно. В частности, не прокатит оптимизация для кода вида:





Написание операндов через пробел повышает читабельность программы: пробелы просто выделяют отдельные элементы выражения, благодаря чему запись не сливается в сплошную строку. Что-нибудь вроде a=b+c воспринимается сложней, чем a = b + c, ну а чем сложней выражение, тем сильней будет эта разница. В общем, с этим аргументом согласиться не могу. А вот что случайная описка (& вместо && или наоборот) приводит к ошибке, в принципе не обнаруживаемой транслятором -- это для меня является настолько существенным недостатком, что я, будь моя воля, запретил бы использование Си законодательно :) (Собственно, "у них" так и сделано для систем, требующих высокой надёжности, но только в государственной сфере, т.е. в армии; навязать эти же правила коммерческим компаниям правительство Штатов не может: стоимость программистов на Аде в разы больше, чем на Сях, поскольку первых мало, а вся индустрия образования заточена на штамповку быдлокодеров. Вот когда какая-нибудь АЭС взлетит на воздух из-за подобной ошибки, тогда возьмутся за ум... может быть). А ведь это -- не единственная проблема сей...

Другое дело, что и на Паскале, и на Аде можно написать абсолютно нечитабельную и ненадёжную программу: с этим спорить глупо. Но всё ж лучше использовать язык, который мешает делать ошибки, чем поощряет их совершать... (Кстати говоря, примером нечитабельной программы на Паскале является компилятор Фри Паскаля: такое впечатление, что ставить те же пробелы его создателям религия не позволяет. Противоположным примером является написанный на Си++ графдвижок Orge: хотя я и не знаток этого языка, но те исходники, что смотрел для интереса, понимал почти без затруднений; возникла лишь пара вопросов, связанных с тонкими моментами реализации ООП в Си++).

Бред, бред и ещё раз бред. Где в Си отражение такого важнейшего элемента архитектуры процессора, как регистры общего назначения, регистры флагов и управляющие регистры? Не говоря о том, что в Си вообще нет никакого набора процессорных команд, ну а сей набор -- не что иное, как 70% архитектуры. Тонкий намёк: операция присваивания = -- это не эквивалент команды MOV, хотя вроде тоже что-то куда-то пересылает.



Спецификация версии 4 возникла не из воздуха, а из всего предыдущего опыта, накопленного при создании протоколов предыдущих версий. Соответственно, и сети появились не с появлением версии 4, а немножко раньше (первые -- так вообще ещё в 1960-х годах, когда ни о каком TCP/IP и речи не было). Так что снова мимо.