Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 142
Неужели этого не знают программисты даже в общих чертах?! Это же рассказывают в ВУЗах, нам год объясняли архитектуру x86.
Дружище, далеко не все в вузы ходили. А если серьезно, то очень мало кто знает, к сожалению, большинство людей в профессии — случайные люди.
К сожалению…
Я об этом прочитал в школе — стрельнул у друзей замечательный четырехтомник «Микропроцессор i486. Архитектура и программирование.»
п.с. Картинки все такие знакомые… :)
п.с. Картинки все такие знакомые… :)
единственное, что я узнал в универе во всех подробностях — Pascal/Delphi, на это мы потратили год… а сейчас нам сказали: «всё, ребята, остальное сами учите и разбирайте, самое клёвое мы вам преподали».
Я считаю, в вузе дают некую базу, «словарь терминов», если так можно выразиться, для плодотворного самостоятельного обучения всему необходимому. Это например матан, лин. алгебра, физика, электроника, дискретка и матлогика, теория ЯП и прочие. Согласитесь, самостоятельно это изучить довольно сложно, а иногда и просто лень.
Учусь по специальности «Автоматизация систем управления», ИТ-направление. Все, что написал автор, и гораздо больше, рассказывали в прошлом году (3-ий курс). Учат нормально, учатся херово — это да.
Учусь на специальности «вычислительные машины, системы, комплексы и сети». на 3м курсе год изучается организация ЭВМ и полгода микропроцессорные системы, там об этом очень подробно рассказывается (другое дело как это слушают). А на 4м курсе курсовой проект называется «разработка процессора», тут уж никак не обойтись без организации памяти.
Неужели этого не знают программисты даже в общих чертах?! Это же рассказывают в ВУЗах, нам год объясняли архитектуру x86.
Неплохо еще сюда добавить — в 95% технологий современного программировании все знания, описанные здесь — мусор, который не пригодится.
Неплохо еще сюда добавить — в 95% технологий современного программировании все знания, описанные здесь — мусор, который не пригодится.
Не стоит делать таких категоричных заявлений. Эти знания отнюдь не мусор, а совершенно необходимы в достаточно большом количестве случаев, например в таких индустриях как: AV, (anti)malware development, vulnerability/exploit develompent, про программирование разнообразных микроконтроллеров я уж молчу — это все серьезные сферы IT с серьезными оборотами $$$ и это вовсе не 5% которые не вошли в обозначенные Вами 95% разного рода ООП-щины и всякой дотнетчины. И люди, работающие в данных областях, ежедневно на практике применяют те знания, которые Вы называете мусором. Вообщем все технологии и знания нужны, а если ненужны — они просто отмирают и забываются. Каждому свое — кто-то мышкой елозит в своем фрейворке да методы в классах вызывает, а кому-то в кайф с дебаггерами и дизассемблерами бинарники копать.
Где Вы тут увидели «категоричное заявление»? Это просто констатация фактов, которые мы видим каждый день.
Прогресс не стоит на месте. Физическая модель организации памяти уже давно мало кого интересует, кроме как разработчиков операционных систем. Это совершенно нормально, так и должно быть, так как мы хотим видеть в компьютере удобный в производстве инструмент, а не набор проводков и микросхем.
Сейчас основной мейнстрим производства ПО — верстка сайтов, бизнес-приложения, производство и обработка графического и звукового материала. Программы для этих целей давно пишутся на основе высокоуровневых библиотек и операционных систем, скрывающих (и слава богу) от программиста кучу ненужных деталей. Поэтому я не стал говорить, что знания устройства памяти устаревшей архитектуры x86 стопроцентный мусор — это просто знания, которые уже редко кому нужны. То есть это мусор примерно на 95%, отвлекающий нас от реальности.
Прогресс не стоит на месте. Физическая модель организации памяти уже давно мало кого интересует, кроме как разработчиков операционных систем. Это совершенно нормально, так и должно быть, так как мы хотим видеть в компьютере удобный в производстве инструмент, а не набор проводков и микросхем.
Сейчас основной мейнстрим производства ПО — верстка сайтов, бизнес-приложения, производство и обработка графического и звукового материала. Программы для этих целей давно пишутся на основе высокоуровневых библиотек и операционных систем, скрывающих (и слава богу) от программиста кучу ненужных деталей. Поэтому я не стал говорить, что знания устройства памяти устаревшей архитектуры x86 стопроцентный мусор — это просто знания, которые уже редко кому нужны. То есть это мусор примерно на 95%, отвлекающий нас от реальности.
Я согласен, знал это в подробностях, когда писал лабы на асме, считаю, что в определенный период развития программиста это знать необходимо. А потом можно и забыть, что нужно, то усвоится. И считаю, что без знания ассемблера когда-то, я бы не понял прелесть высокоуровневых технологий и не стал бы программировать на RoR, т.к. не понял бы всей прелести.
Я бы таки добавил ссылку на замечательную статью Ульриха Дреппера (инженер RedHat), где затронуты все основные моменты работы с памятью. Что такое кеш, каким он бывает, какие бывают виды собственно памяти и т. д.
В общем вот: lwn.net/Articles/250967/
В общем вот: lwn.net/Articles/250967/
Так вот оно что…
Меня вообще очень огорчают программисты, которые не знают как работает машина, обычно это программисты Java и прочие php-парни, с квалификацией ниже плинтуса.Java- и PHP-код может запускаться на машинах имеющих архитектуру отличную от x86. Неудивительно что вопросы организации физической памяти в этих языках даже не рассматриваются.
Что уж говорить о высокоуровневых языках типа SQL которые вообще не являются императивными.
На данный момент работа с физической памятью имеет место только в очень узком сегменте ранка разработки ПО.
Нет, вы, конечно, правы. Разработка эффективных программ стоит на порядки дороже, но именно поэтому мы имеем, что имеем: стремительное увеличение мощности железа и программы, которые вроде и быстрее, а вроде и не в те 10 раз.
если во время разработки, скажем, бухгалтерской программы, заниматься вопросами организации памяти вместо оптимизации расчёта счётов-фактур то результат будет на порядок хуже а не лучше.
В каждой области свои требования.
В каждой области свои требования.
Никто не заставляет при разработке бухгалтерской программы заниматься организацией памяти. Но вот как-то получается, что те, кто способен хорошо оптимизировать расчёт счетов-фактур, почему-то ещё знают, как работает железо. Интересная корреляция, правда?
я думаю это неправда. Универсалов очень мало, большинство низкоуровненвых программистов ничего не понимают в бухгалтерии или нормализации баз данных.
Я не универсал. Я глубоко знаю только Java. Но поверхностно интересовался многим. В том числе когда-то под DOS писал программки, переходящие в защищённый режим, включавщие режим SVGA и через VESA что-то красивое рисующие на экране. Вроде с тех пор не забылись хотя бы в общих чертах принципы работы архитектуры x86. А потом ещё алгоритмы, которые мы проходили в курсе «численные методы» реализовывал на Haskell. Моего опыта не хватило бы, чтобы написать драйвер видюхи для Linux или CAS — я не универсал, а Java-программист. Но тем не менее, я считаю, что получил полезный опыт, который полезен мне и как Java-программисту.
я не зря упомянул бухгалтерию и нормализацию БД. Это абсолютно другие области. Странно ожидать от базоданщика познаний в архитектуре x86 если он работает с DB2 под AS/400.
А уж считать программистов из других областей недостаточно квалифицированными только потому что не понимаешь чем они занимаются вообще глупо.
А уж считать программистов из других областей недостаточно квалифицированными только потому что не понимаешь чем они занимаются вообще глупо.
www.joelonsoftware.com/articles/LeakyAbstractions.html
Помимо просто знания Java или PHP, программисту не мешает хотя бы приблизительно ознакомиться с тем, как работает железо, почитать Кнута, SICP, порешать олимпиадные задачи, написать драйвер и т.д.
Помимо просто знания Java или PHP, программисту не мешает хотя бы приблизительно ознакомиться с тем, как работает железо, почитать Кнута, SICP, порешать олимпиадные задачи, написать драйвер и т.д.
А еще кормить ребенка, одевать жену, оплачивать кредит за машину, искать новое жилье. Читать про технологии, которые применяются в решении текущих задач. Да, иногда спать, кушать, и хоть изредка посидеть с удочкой на бережку. Честно, мне ни до Кнута ни до драйверов.
Прошу прощение за лирическое отступление… Не пытаюсь перевешать свою жизнь на кого-то, но ложась спать часто думаю, какую бы книгу почитать и где взять на это время уже порядка 2 лет.
Прошу прощение за лирическое отступление… Не пытаюсь перевешать свою жизнь на кого-то, но ложась спать часто думаю, какую бы книгу почитать и где взять на это время уже порядка 2 лет.
Я бы осторожно заметил, что между пониманием принципа работы указателя и написанием драйверов есть достаточно немалая дистанция. Но в целом верно — расширение кругозора необходимо.
Для таких языков по крайней мере необходимо понимать разницу во времени доступа к кешу/памяти/диску, что такое виртуальная память и как она сбрасывается на диск при нехватке оперативной памяти — это все универсальные вещи, существующие на всех современных платформах.
А статья в любом случае полезна для общей ориентации.
Кстати, про организацию памяти великолепно написал Крис Касперски в книге «Техника оптимизации программ. Эффективное использование памяти». Примерно в ключе этой статьи, только более детально и структурировано (все-таки книга — места больше). Выпущена на русском и на английском.
А статья в любом случае полезна для общей ориентации.
Кстати, про организацию памяти великолепно написал Крис Касперски в книге «Техника оптимизации программ. Эффективное использование памяти». Примерно в ключе этой статьи, только более детально и структурировано (все-таки книга — места больше). Выпущена на русском и на английском.
> Java- и PHP-код может запускаться на машинах имеющих архитектуру отличную от x86. Неудивительно что вопросы организации физической памяти в этих языках даже не рассматриваются.
Что-то я не понял, вы намекаете, что код на Си не может запускаться на архитектурах, отличных от x86 или вообще о чем?
Что-то я не понял, вы намекаете, что код на Си не может запускаться на архитектурах, отличных от x86 или вообще о чем?
Помню в вузе знал, понимал, сдавал. Но потом забыл за ненадобностью.
Прошу прощения за свою темноту… Я как PHP, Java кодер не помню всего этого из лекций универа…
Но объясните, как данная информация может мне пригодится в повседневной работе? Как например кодируя Javascript мне может это пригодится?
А если рассмотреть облачные вычисления? Каким боком, знания о работе с памятью могут пригодится? Или вот я прикручивал платежные системы к сайтику, зачем я должен думать как устроена память?
Прошу понять меня правильно, я не хочу показать через чур глупым. Но я считаю решая повседневные задачи, данная информация мне никаким образом не пригодится, а мозг засорит. И следовательно главный вопрос, ответ на который я не увидел в статье. Зачем мне это нужно знать?
Но объясните, как данная информация может мне пригодится в повседневной работе? Как например кодируя Javascript мне может это пригодится?
А если рассмотреть облачные вычисления? Каким боком, знания о работе с памятью могут пригодится? Или вот я прикручивал платежные системы к сайтику, зачем я должен думать как устроена память?
Прошу понять меня правильно, я не хочу показать через чур глупым. Но я считаю решая повседневные задачи, данная информация мне никаким образом не пригодится, а мозг засорит. И следовательно главный вопрос, ответ на который я не увидел в статье. Зачем мне это нужно знать?
Ну как минимум вопрос об организации памяти в конкретной взятой системе — это пример решения задачи. Обладая знаниями о том, как принято решать задачи из различных областей, гораздо проще решать свои повседневные задачи. Это называется опыт. И, кстати, иногда всё-таки нужно понимать, как работает физика. Например, когда Java-программа, выдающая отчёты по продажам, должна так же научиться печатать стикеры на товары. И тут начинается головная боль с COM-портом, драйверами для принтера этикеток, JNI и прочее. Ну или вот современные СУБД очень и очень отталкиваются от физической организации диска, «пробивая» такую абстракцию, как «файловая система».
Хорошо… не трогаем Java и работу с железом. Возвращаемся к вебу.
Нет у нас СУБД, пользуемся только сторонними сервисами. Каким образом, ь знания об организации и работы с памятью нам пригодятся?
Если честно, меня обидели слова «Меня вообще очень огорчают программисты, которые не знают как работает машина, обычно это программисты Java и прочие php-парни, с квалификацией ниже плинтуса»,
Я не считаю свою квалификацию ниже плинтуса, так как решаю повседневные задачи, за которые получаю деньги, и решение той или иной задачи приносит пользу заказчику. Но более чем за 5 лет я ни разу не столкнулся с работой памяти, да и в разрезе PHP, об этом нет надобности думать. Но от этого моя квалификация остается на уровне ниже плинтуса? Тогда за, что мне платят деньги?
Нет у нас СУБД, пользуемся только сторонними сервисами. Каким образом, ь знания об организации и работы с памятью нам пригодятся?
Если честно, меня обидели слова «Меня вообще очень огорчают программисты, которые не знают как работает машина, обычно это программисты Java и прочие php-парни, с квалификацией ниже плинтуса»,
Я не считаю свою квалификацию ниже плинтуса, так как решаю повседневные задачи, за которые получаю деньги, и решение той или иной задачи приносит пользу заказчику. Но более чем за 5 лет я ни разу не столкнулся с работой памяти, да и в разрезе PHP, об этом нет надобности думать. Но от этого моя квалификация остается на уровне ниже плинтуса? Тогда за, что мне платят деньги?
Да и Java, оказывается, плохим языком стала.
Я тоже не согласен с автором. Если хочешь объяснить что-то, чего другие не знают — объясни, тебя поблагодарят.
Но если при этом называешь свою аудиторию низкосортными тупарями, то особой благодарности ждать не стоит.
Но если при этом называешь свою аудиторию низкосортными тупарями, то особой благодарности ждать не стоит.
Насчет явы — была ирония, конечно я не разделяю языки на хорошие и плохие, все языки на которых пишутся хорошие программы — априори языки хорошие. Поэтому и на яве есть хорошие программы, я не сомневаюсь. Но я вижу тенденцию, что люди выросшие на этой самой яве и ничего более не знающие очень слабые кодеры. И напротив люди, которые знают ассемблер, и умеют работать с указателями в Си/Си++ как правило яву осваивают в тот же день и работают впредь гораздо более продуктивно, чем их коллеги, которые ничего кроме явы не знают.
Ну согласитесь что кроме рисований формочек для бизнес приложений не плохо бы еще чем-то интересоваться почему бы и не организацией памяти?
Ну согласитесь что кроме рисований формочек для бизнес приложений не плохо бы еще чем-то интересоваться почему бы и не организацией памяти?
Да я не спорю, это реально круто. Но согласитесь, что рисованием формочек (в том или ином смысле) Java/JavaScript/Python/PHP и т.д. не ограничены. Расскажите, вам действительно приходится постоянно сталкиваться с настолько низким уровнем, с регистрами процессора, например? Может, расскажете про реальные задачи, интересные примеры кода, чтобы широкая аудитория заинтересовалась, поняла на практике, зачем оно надо. Тут люди неглупые, да и я сам, думаю, не последний дурак, мы бы поняли, вы только расскажите.
Про это я напишу более подробно в след. частях.
Я с этим сталкиваюсь непосредственно, когда программирую на Си. Совершенно стандартная ситуация: я хочу воспользоваться библиотекой от другого языка, для этого мне надо понять, как аргументы функции попадают в стек в каком порядке и тд. И если они передаются не в том порядке, мне надо на ассемблере настрочить какую-нибудь примитивную фиговину, которая эти аргументы поменяет местами. Ну а что касается высокоуровневых языков лишним тоже не будет, понимание как то что вы делаете накладывается на адресное пространство хотя бы в общих чертах.
Я с этим сталкиваюсь непосредственно, когда программирую на Си. Совершенно стандартная ситуация: я хочу воспользоваться библиотекой от другого языка, для этого мне надо понять, как аргументы функции попадают в стек в каком порядке и тд. И если они передаются не в том порядке, мне надо на ассемблере настрочить какую-нибудь примитивную фиговину, которая эти аргументы поменяет местами. Ну а что касается высокоуровневых языков лишним тоже не будет, понимание как то что вы делаете накладывается на адресное пространство хотя бы в общих чертах.
На самом деле, все равно с этим сталкиваешься. Вон я оптимизирую под флеш, а спускается все равно к тому же самому.
А я вот знаю людей, которые зная ассемлер и C/C++, берутся за Java (осваивая ее уже не первый год) и пишут на ней какую-то несусветную галиматью
Нет у нас СУБД, пользуемся только сторонними сервисами. Каким образом, ь знания об организации и работы с памятью нам пригодятся?
Да порой самым неочевидным образом. Порой просто легче принять верное решение, обладая опытом в разных областях. А если, скажем, приложение становится популярным и им начинают пользоваться миллионы пользователей, то остро встаёт вопрос производительности. А тут уже все методы хороши (в том числе и оптимизация на уровне железа). И не надо говорить про дешевизну железа. Железо — это не что-то, что поставили и работает, его тоже надо обслуживать.
Пожимаю плечами. Может, надо просто ироничнее относиться к себе. Я вот тоже пишу на Java и PHP. И что с того?
Ну всегда полезно взглянуть на себя с другой стороны. Поставить под сомнение свою квалификацию.
А вот это уж точно никак не показывает чью-либо квалификацию.
Да порой самым неочевидным образом. Порой просто легче принять верное решение, обладая опытом в разных областях. А если, скажем, приложение становится популярным и им начинают пользоваться миллионы пользователей, то остро встаёт вопрос производительности. А тут уже все методы хороши (в том числе и оптимизация на уровне железа). И не надо говорить про дешевизну железа. Железо — это не что-то, что поставили и работает, его тоже надо обслуживать.
Если честно, меня обидели слова «Меня вообще очень огорчают программисты, которые не знают как работает машина, обычно это программисты Java и прочие php-парни, с квалификацией ниже плинтуса»,
Пожимаю плечами. Может, надо просто ироничнее относиться к себе. Я вот тоже пишу на Java и PHP. И что с того?
Я не считаю свою квалификацию ниже плинтуса, так как решаю повседневные задачи, за которые получаю деньги, и решение той или иной задачи приносит пользу заказчику
Ну всегда полезно взглянуть на себя с другой стороны. Поставить под сомнение свою квалификацию.
Тогда за, что мне платят деньги?
А вот это уж точно никак не показывает чью-либо квалификацию.
Расскажите про ваш пример, раз вы Java/PHP-программист, как у вас «неочевидным образом» получалось применить знания про организацию памяти?
Образ на то и неочевидный, что он неочевиден и для меня. Ну я могу начать последовательность, но до x86 она не доходит. В общем, пишу на Java EE и в БД лезу через JPA. Порой бывает так, что какая-то штука начинает тормозить и выясняется, что ORM выдаёт тормозные запросы. Приходится специально ковырять JPQL и задавать хинты (ORM-специфичные, EclipseLink) так, чтобы получать лучший SQL. Порой вообще приходится выкидывать ORM и работать напрямую через JDBC. Далее, проламывается и просто SQL, ибо запрос тормозит, и непонятно почему. Приходится выполнять EXPLAIN SELECT и думать, почему же планировщик запросов конкретной СУБД (PostgreSQL) не хочет вести себя так, как мне хочется. Ну самый нижний уровень — приходится иногда таблицу проектировать с учётом того, как работает СУБД. Соответственно, тонко настраивать СУБД, планировать периодичность запуска VACUUM и т.п. Думаю, если бы объёмы данных были больше, то пришлось бы ещё больше лезть «вниз», но пока не приходилось.
Всё зависит от области, в которой Вы работаете. Как PHP и Java кодеру такое знание полезно, пожалуй, лишь в рамках общего образования. А я вот, например, пишу программы для автоматизированной обработки рентгеновских изображений в реальном времени, и мне это знание реально требуется в работе. Конечно, на уровень дескрипторов я не опускаюсь, но то, как происходит выборка из оперативной памяти, как работает кэш, отличие 32-х и 64-х битных систем и т.д. — это реально необходимое для меня знание. Со своей стороны, я понятия не имею о PHP и Java… Знаю, что есть такие языки, но не более того.
И вообще — «хороший специалист подобен флюсу — полнота его односторонняя...» (с) Козьма Прутков
И вообще — «хороший специалист подобен флюсу — полнота его односторонняя...» (с) Козьма Прутков
>Но объясните, как данная информация может мне пригодится в повседневной работе
если говорить о Java кодерах, то периодически встречаю «оптимизацию» кода, когда люди пишут не только менее читабельный, но и тормозной код по причинам что им кажется что они делают что-то быстрее, а всё из-за того что нет базовых знаний по таким вещам как память.
PHP'шники обычно о таких вещах и правда не заморачиваются.
если говорить о Java кодерах, то периодически встречаю «оптимизацию» кода, когда люди пишут не только менее читабельный, но и тормозной код по причинам что им кажется что они делают что-то быстрее, а всё из-за того что нет базовых знаний по таким вещам как память.
PHP'шники обычно о таких вещах и правда не заморачиваются.
Предлагаю сохранить закладку так, на всякий случай, а когда понадобится — прочитать!
Программистам на Java нужно знать другую документацию по организации памяти — устройств JVM. Ведь по сути, JVM создана как отдельная платформа поверх любой другой. И надеясь, что разработчики JVM сделали все возможное по учету особенностей конкретной физической платформы, программисту только остается писать оптимальный код под платформу JVM.
На хабре есть неплохие статьи(эта, эта) на тему организации памяти в JVM.
На хабре есть неплохие статьи(эта, эта) на тему организации памяти в JVM.
Стоило бы указать что бит в селекторе TI в первую очередь служит для переключения режима работы микропроцессора (реальный/защищенный). Просто использование GDT вместо LDT и наоборот человеку со стороны ни о чем не говорит.
А так, да приятно было вспомнить как лет 10 назад читал «Ассемблер» В. Юрова :)
А так, да приятно было вспомнить как лет 10 назад читал «Ассемблер» В. Юрова :)
По моему почти все это описано еще в бестселлере Питера Абеля :)
> Меня вообще очень огорчают программисты, которые не знают как работает машина, обычно это программисты Java и прочие php-парни, с квалификацией ниже плинтуса.
Меня очень огорчают программисты, которые не знают, что такое DI, IoC-containers, method interceptions, обычно это программисты C++ и прочие Си-парни, с квалификацией битомешателей в кодинге и с квалификацией ниже плинтуса в промышленной разработке.
> Биты с 15-39 и 56-63 содержат…
...20битное значение от 0-15 и 48-51 бит
В программировании приняты полуоткрытые интервалы вида [left, right), то есть: «… Биты из диапазона [16, 40) и [56, 64)… ...20-битное значение [0, 16) и [48, 52) бит». Если бы вы последовательно придерживались этого соглашения, было бы гораздо меньше путаницы.
> Но без понимания, как устроена память невозможно понять как эти самые переменные хранятся в памяти.
Но вышеизложенное — не «понимание», это низкоуровневые детали реализации конкретной архитектуры (которая является нагромождением нелепых исторических казусов; legacy, одним словом). Если нужны именно они, то лучше брать предложенные выше статьи Ульриха. Если нужно общее понимание, то битовые структуры селекторов и дескрипторов совершенно избыточны. Их знание имеет к программированию такое же отношение, что и знание первых 100 цифр числа пи — к математике.
Меня очень огорчают программисты, которые не знают, что такое DI, IoC-containers, method interceptions, обычно это программисты C++ и прочие Си-парни, с квалификацией битомешателей в кодинге и с квалификацией ниже плинтуса в промышленной разработке.
> Биты с 15-39 и 56-63 содержат…
...20битное значение от 0-15 и 48-51 бит
В программировании приняты полуоткрытые интервалы вида [left, right), то есть: «… Биты из диапазона [16, 40) и [56, 64)… ...20-битное значение [0, 16) и [48, 52) бит». Если бы вы последовательно придерживались этого соглашения, было бы гораздо меньше путаницы.
> Но без понимания, как устроена память невозможно понять как эти самые переменные хранятся в памяти.
Но вышеизложенное — не «понимание», это низкоуровневые детали реализации конкретной архитектуры (которая является нагромождением нелепых исторических казусов; legacy, одним словом). Если нужны именно они, то лучше брать предложенные выше статьи Ульриха. Если нужно общее понимание, то битовые структуры селекторов и дескрипторов совершенно избыточны. Их знание имеет к программированию такое же отношение, что и знание первых 100 цифр числа пи — к математике.
жаль плюсануть не могу, очень грамотно ответил.
Меня очень огорчают программисты, которые не знают, что такое DI, IoC-containers, method interceptions, обычно это программисты C++ и прочие Си-парни, с квалификацией битомешателей в кодинге и с квалификацией ниже плинтуса в промышленной разработке.
Полностью поддерживаю! А ещё меня огорчают программисты, который не различают контекстно-зависимой и контекстно-свободной грамматик, которые удивлённо мигают, видя запись O(n^3) или не понимают, что типизация бывает статической и динамической а так же строгой и нестрогой.
Вы хотите сказать, что знаете абсолютно все в программировании, начиная от написания драйверов и заканчивая облачными вычислениями, и совершенно справедливая критика Qbit неуместна? Я точно так же не согласен с мнением, высказанным автором в начале статьи. Такие сведения, которые напрямую не применяются, весьма часто забываются за простой ненадобностью.
Абсолютно всего не знаю. Но вот, скажем, вопрос о типизации языка программирования, на котором я пишу, меня сильно волнует, ибо я знаю, к чему выбор того или иного языка может привести и как с этим потом бороться. А вот без понимания того, что такое асимптотическая сложность, я бы вообще за клавиатуру не пускал. Я никогда не залезал в этих вопросах в дебри, но общее представление получил. Хотя бы из тех же блогов, которые читаю любопытства ради. Подобные вот статьи как раз и пишутся для людей, работающих в совершенно другой области, чтобы они могли получить общее представление — специалистам они ничего нового не рассказывают. Думаю, так же и людям, программирующим микроконтроллеры, будет очень полезно почитать что-нибудь про веб-программирование.
Предположим что вы програмист на Java, делаете сложные десктопные приложения.
Какие знания из этого списка вам не нужны, что они забудутся за ненадобностью:
— базовые алгоритмы/структуры данных
— как работает железо
— устройство ОС, с которой работаете
— парадигмы программирования
— паттерны программирования
— опыт промышленной разработки
Проблема ведь в том что у большинства программистов отсутствует нормальная база, а не какие-то детали по написанию драйверов или облачные вычисления.
Какие знания из этого списка вам не нужны, что они забудутся за ненадобностью:
— базовые алгоритмы/структуры данных
— как работает железо
— устройство ОС, с которой работаете
— парадигмы программирования
— паттерны программирования
— опыт промышленной разработки
Проблема ведь в том что у большинства программистов отсутствует нормальная база, а не какие-то детали по написанию драйверов или облачные вычисления.
Абсолютно точно подметили.
> Абсолютно точно подметили.
Смешали всё в кучу.
Если вкратце и грубо (прошу обратить внимание эту оговорку!), то знания можно разделить на
1) те, что используются постоянно (и потому важны)
2) те, что не используются постоянно, и тем не менее важны (ввиду их фундаментальности)
3) те что и не используются на практике, и не важны (ввиду их сиюминутности, преходящести, узкоспециализированности)
Почти всё, что перечислил nunit, относится к первому типу.
То, что перечислил konsoletyper — в основном ко второму. Алгебру, логику, проблемы вычислимости, основания математики, теорию языков и грамматик, анализ, хитрые структуры данных и алгоритмы, etc, редко приходится использовать на практике. И тем не менее считаю важным для себя, и для окружающих программистов (просто мне приятно находится в обществе компетентных людей, не ограниченных рамками повседневных обязанностей) изучение этих и других фундаментальных вещей. Они содержат более или менее базовые идеи, которые никуда не денутся со сменой моды, доминирующих технологий, etc.
Почти всё, о чём написали вы, относится к третьему типу. И оно бы ничего (ведь есть люди, которым на практике нужны битовые форматы дескрипторов, заголовкгов TCP/IP-пакетов, etc), если бы не сквозящий в посте снобизм, относительно «C++-программистов», «знающих, как устроена матрица», и «Java-программистов», которые «just code monkeys».
По моему скромному опыту (я в прошлом разработчик на C++, ныне на .NET, то есть, обобщённый «Java-программист» в контексте статьи) .NET-разработчик с опытом N лет в среднем более квалифицирован, чем C++-разработчик с опытом тех же N лет. Как бы парадоксально это ни звучало для плюсистов. Пока последний решает на C++ проблемы, которые больше ни в одном языке так изящно не решаются (но при этом и не возникают), первый сталкивается с бОльшим разнообразием паттернов, архитектурных подходов, идиом и концепций. Имхо.
Смешали всё в кучу.
Если вкратце и грубо (прошу обратить внимание эту оговорку!), то знания можно разделить на
1) те, что используются постоянно (и потому важны)
2) те, что не используются постоянно, и тем не менее важны (ввиду их фундаментальности)
3) те что и не используются на практике, и не важны (ввиду их сиюминутности, преходящести, узкоспециализированности)
Почти всё, что перечислил nunit, относится к первому типу.
То, что перечислил konsoletyper — в основном ко второму. Алгебру, логику, проблемы вычислимости, основания математики, теорию языков и грамматик, анализ, хитрые структуры данных и алгоритмы, etc, редко приходится использовать на практике. И тем не менее считаю важным для себя, и для окружающих программистов (просто мне приятно находится в обществе компетентных людей, не ограниченных рамками повседневных обязанностей) изучение этих и других фундаментальных вещей. Они содержат более или менее базовые идеи, которые никуда не денутся со сменой моды, доминирующих технологий, etc.
Почти всё, о чём написали вы, относится к третьему типу. И оно бы ничего (ведь есть люди, которым на практике нужны битовые форматы дескрипторов, заголовкгов TCP/IP-пакетов, etc), если бы не сквозящий в посте снобизм, относительно «C++-программистов», «знающих, как устроена матрица», и «Java-программистов», которые «just code monkeys».
По моему скромному опыту (я в прошлом разработчик на C++, ныне на .NET, то есть, обобщённый «Java-программист» в контексте статьи) .NET-разработчик с опытом N лет в среднем более квалифицирован, чем C++-разработчик с опытом тех же N лет. Как бы парадоксально это ни звучало для плюсистов. Пока последний решает на C++ проблемы, которые больше ни в одном языке так изящно не решаются (но при этом и не возникают), первый сталкивается с бОльшим разнообразием паттернов, архитектурных подходов, идиом и концепций. Имхо.
Я вообще не программист, я беспристрастен к языкам, я уже писал что хороший язык это тот на котором пишутся хорошие программы.
Но программисты не знающие ничего кроме явы у меня вызывают подозрения, потому что большинство людей которых я принимал на работу были очень плохими программистами и они все знали только яву.
Насчет математики я с вами согласен это самое важное что должно интересовать человека, но я все таки убежден, что программист должен знать и машину, он должен иметь представление о том как она работает на том низком уровне. Простите, но я не представляю хорошего программиста, который бы не знал что такое стек, это нонсенс.
Но программисты не знающие ничего кроме явы у меня вызывают подозрения, потому что большинство людей которых я принимал на работу были очень плохими программистами и они все знали только яву.
Насчет математики я с вами согласен это самое важное что должно интересовать человека, но я все таки убежден, что программист должен знать и машину, он должен иметь представление о том как она работает на том низком уровне. Простите, но я не представляю хорошего программиста, который бы не знал что такое стек, это нонсенс.
> я уже писал что хороший язык это тот на котором пишутся хорошие программы.
Так как хорошую программу можно написать почти на любом языке, то это значит, что почти все языки — хорошие? Извините, мне не подходит такое определение хорошего языка, так как вводимое понятие бессодержательно, выхолощено, бесполезно. Типа: назовём зелубым любой цвет (кроме, быть может, оттенка жёлтого).
> большинство людей которых я принимал на работу были очень плохими программистами и они все знали только яву.
«После» (и «вместе») — не значит «вследствие». Все люди, которые 150 лет назад ели огурцы, уже умерли. Значит ли это, что огурцы ядовиты?
> Простите, но я не представляю хорошего программиста, который бы не знал что такое стек, это нонсенс.
Понятие стека — объективно хорошая придумка, очень важная и обязательная к пониманию. Понятие разных конвенций вызова и порядка размещения аргументов функций на стеке — это артефакт борьбы отсроконечников с тупоконечниками, ничего принципиального или общеценного в этом нет совершенно.
Так как хорошую программу можно написать почти на любом языке, то это значит, что почти все языки — хорошие? Извините, мне не подходит такое определение хорошего языка, так как вводимое понятие бессодержательно, выхолощено, бесполезно. Типа: назовём зелубым любой цвет (кроме, быть может, оттенка жёлтого).
> большинство людей которых я принимал на работу были очень плохими программистами и они все знали только яву.
«После» (и «вместе») — не значит «вследствие». Все люди, которые 150 лет назад ели огурцы, уже умерли. Значит ли это, что огурцы ядовиты?
> Простите, но я не представляю хорошего программиста, который бы не знал что такое стек, это нонсенс.
Понятие стека — объективно хорошая придумка, очень важная и обязательная к пониманию. Понятие разных конвенций вызова и порядка размещения аргументов функций на стеке — это артефакт борьбы отсроконечников с тупоконечниками, ничего принципиального или общеценного в этом нет совершенно.
> которые не знают, что такое DI, IoC-containers, method interceptions...
Спасибо. Пошёл гуглить, вычитал много нового для себя. Буду копать глубже.
Спасибо. Пошёл гуглить, вычитал много нового для себя. Буду копать глубже.
Статья хорошая, годная, полезна для прочтения каждому, кто этого не знал, чтобы примерно понять как это все работает и забыть 95% написанного за ненадобностью. Только не понятно предвзятое отношения к Java и прочим php-парням (среди которых бывают и php-девушки), которым это нужно только с общеобразовательной точки зрения и абсолютно не поможет в работе. Вот в такой форме оно для приемлемлемо, а вместо прочтения специализированной литературы, в принципе косвенно затрагивающей их область действия, т.к. в своих языках они напрямую с этим не сталкиваются, лучше почитать что-то для них актуальное.
>Рассмотрим адресное пространство программного режима 32 битного процессора (для 64 бит все по аналогии)
Ой ли? Что-то я с вами не совсем согласен.
Ой ли? Что-то я с вами не совсем согласен.
Раз уж тут пошло обсуждение на тему «нужны ли мне эти знания на практике, если я Java-программист?», то выскажу и свою точку зрения. По-моему говорить и «мне это не нужно, это мусор, если я это не использую каждый день», и «вы ни на что не годное быдло, если не знаете, что *Регистр ESP содержит адрес вершины стека*» неверно. С одной стороны, знать, что такую-то задачу решили таким-то образом полезно, это так или иначе осядет в вашем «опыте». С другой стороны, действительно, ну зачем держать все это в голове, если работу с памятью за меня выполняет JVM и сборщик мусора? Ведь высокоуровневые языки программирования и придуманы для того, чтобы упростить жизнь программиста, упростить портирование программы, упростить работу с памятью, опять же! Хочется еще сказать в защиту «первой стороны», что почти все, чему меня учили в ВУЗе мне не нужно в работе, зато все эти задачи и дикие математические выкладки _очень прокачали мне мозг_, и именно за это я благодарен своему ВУЗу. Я помню, как в общем-то туго шло понимание прямой работы с указателями, написание руками стеков, деревьев и т.д. и мне ни разу в работе не пришлось реализовывать ничего такого, но эти знания и опыт я никак не могу назвать мусором.
Главное, чтобы голова работала (и в ней было с чем работать и от чего отталкиваться), для всего остального есть гугл)
P.S. А автор, имхо, не прав в своих неосторожных выпадах в сторону «прочих php-парней», ну не красиво это. К тому же знать все и на таком уровне — невозможно. Очень хочется в язвительной форме выдать что-нибудь эдакое в ответ, да что толку. За статью спасибо!)
Главное, чтобы голова работала (и в ней было с чем работать и от чего отталкиваться), для всего остального есть гугл)
P.S. А автор, имхо, не прав в своих неосторожных выпадах в сторону «прочих php-парней», ну не красиво это. К тому же знать все и на таком уровне — невозможно. Очень хочется в язвительной форме выдать что-нибудь эдакое в ответ, да что толку. За статью спасибо!)
Если я обидел кого-то, тогда я прошу прощения у всех пхп-парней скопом, это был просто собирательный образ, шутки ради.
А вообще вы поняли мою мысль, работа с указателями развивает мозги так, что вы можете и на яве, да хоть на бейсике писать лучше, тех людей которые не способны понять работу указателей.
Вот есть неплохая статья на тему почему бесполезные знания ассемблера или указателей оказываются в итоге не бесполезными, статья очень короткая, но на мой взгляд очень емкая и по делу.
habrahabr.ru/blogs/java/122665/
А вообще вы поняли мою мысль, работа с указателями развивает мозги так, что вы можете и на яве, да хоть на бейсике писать лучше, тех людей которые не способны понять работу указателей.
Вот есть неплохая статья на тему почему бесполезные знания ассемблера или указателей оказываются в итоге не бесполезными, статья очень короткая, но на мой взгляд очень емкая и по делу.
habrahabr.ru/blogs/java/122665/
Как-то тут совсем примитивненько… Вот эта картинка (с поправкой на существование виртуализации) мне нравится больше:
> Меня вообще очень огорчают программисты, которые не знают как работает машина
Ага, а автослесарей огорчают гонщики, которые не знают как клапана поменять, скрипичных мастеров огорчает Ростропович, не знающий основ приготовления лака для инструмента, а админов бесят пользователи, не понимающие командную строку. Это список можно продолжать бесконечно. По-моему, давно прошли те времена, когда программист был универсалом от драйверов до разработки интерфейса. Объемы знаний и технологий растут в геометрической прогрессии и нужно сосредотачиваться на том, что действительно нужно. Если есть свободное время и желание, то почитать теорию о том как работает железо бывает весьма занятно, но уж никак это не является обязательным. Сегодня балом правит специализация и это очень хорошо: будем иметь поменьше UI придуманных системщиком или самописных CMS разработанных дизайнерами
Ага, а автослесарей огорчают гонщики, которые не знают как клапана поменять, скрипичных мастеров огорчает Ростропович, не знающий основ приготовления лака для инструмента, а админов бесят пользователи, не понимающие командную строку. Это список можно продолжать бесконечно. По-моему, давно прошли те времена, когда программист был универсалом от драйверов до разработки интерфейса. Объемы знаний и технологий растут в геометрической прогрессии и нужно сосредотачиваться на том, что действительно нужно. Если есть свободное время и желание, то почитать теорию о том как работает железо бывает весьма занятно, но уж никак это не является обязательным. Сегодня балом правит специализация и это очень хорошо: будем иметь поменьше UI придуманных системщиком или самописных CMS разработанных дизайнерами
по содержанию статьи:
— Мне казалось, что стек относится скорее к procedure calling conventions, а чем к памяти как таковой. То есть это из другой оперы, и если приводите в пример push/pop, то расскажите зачем это надо.
— в чем практическое применение структуры дескриптора (с указанием битов) и всех тех деталей которые приведены в статье? Оптимизация производительности? Анализ крэш дампов? или зачем это?
— если говорить о памяти более интересно было бы почитать об алгоритмах используемых при трансляции physical<-> virtual на x86, а не о структурах данных.
В целом, как то не очень понятно, что хотел донести автор. Я вот не программист вообще, но полез на сайт интела и там гораздо понятней написано что и зачем:
www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-1-2a-2b-3a-3b-manual.html
— Мне казалось, что стек относится скорее к procedure calling conventions, а чем к памяти как таковой. То есть это из другой оперы, и если приводите в пример push/pop, то расскажите зачем это надо.
— в чем практическое применение структуры дескриптора (с указанием битов) и всех тех деталей которые приведены в статье? Оптимизация производительности? Анализ крэш дампов? или зачем это?
— если говорить о памяти более интересно было бы почитать об алгоритмах используемых при трансляции physical<-> virtual на x86, а не о структурах данных.
В целом, как то не очень понятно, что хотел донести автор. Я вот не программист вообще, но полез на сайт интела и там гораздо понятней написано что и зачем:
www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-1-2a-2b-3a-3b-manual.html
Вы совершенно правильно написали и ваш комментарий по делу, и я собственно хотел во второй части поговорить о calling conventions, и о других практических делах, но как можно говорить об этом не рассказав сперва как устроена память? Что такое стек и тд. А сегмент стека это и есть память. Я люблю последовательность и не могу объяснять одну тему не объяснив другую. И да на интелле замечательная документация о чем я вначале уже написал, она хорошо написана и хорошо проиллюстрирована. Но люди не знающие языка просили меня рассказать им по-русски. Собственно поэтому я и решил написать это.
Если бы эти PHP-программисты знали, как работает PHP… Я думаю, большинство из них не смогут предсказать, что выведет вот этот код:
И вряд ли объяснят, почему он так работает.
<?php
$a = array( 1, 2, 3 );
unset( $a[2] );
$a[] = 4;
var_dump( $a );
И вряд ли объяснят, почему он так работает.
И сразу, приведите практическое применении данного кода? Либо, реальный кусок кода из реального проекта.
Иначе, углубляясь в академизм, мы не придем к очевидном выводу.
Иначе, углубляясь в академизм, мы не придем к очевидном выводу.
На практике подобное используется в заполнении массива дочерними элементами с одновременным перебором по этому массиву. Вместо рекурсии.
примерно таким образом.
<?php
$list = getList();
for( $i=0; $i<sizeof( $list ); $i++ )
{
$element = $list[$i];
if( $element['childsToDisplay'] ) foreach( $element['childsToDisplay'] as $child )
$list[] = $child;
if( $element['doNotDisplay'] )
unset( $list[$i] );
}
for( $i=0; $i<sizeof( $list ); $i++ )
{
display( $i. $list[$i] ); // тут будут нотисы, если я правильно помню. Ну и пропущенные строки.
}
?>
примерно таким образом.
А что неочевидного в данном коде?
вроде просто пример.
[0] => 1
[1] => 2
[3] => 4
Там же хеш-таблица фактически, и нужна переиндексация таблицы, ибо индексы сохраняются даже с обнулением ячейки.
Нет?
[0] => 1
[1] => 2
[3] => 4
Там же хеш-таблица фактически, и нужна переиндексация таблицы, ибо индексы сохраняются даже с обнулением ячейки.
Нет?
Всё так. Только вот сколько людей понимают, что это хеш-таблица и что счётчик не изменяется при удалении ячейки?
ТЫСЯЧИ!!! Для этого же надо, подумать страшно, прочитать документацию.
ну я Сишник, мне потроха популярных структур/алгоритмов знакомы :)
без 'a жить трудно, а стандарта как для плюсов — нет, поэтому томик Кнута — и вперёд писать код)
а среди php'шников действительно не думаю что многие об этом задумывались, ибо такие тонкие нюансы редко встречаются в повседневной работе.
без 'a жить трудно, а стандарта как для плюсов — нет, поэтому томик Кнута — и вперёд писать код)
а среди php'шников действительно не думаю что многие об этом задумывались, ибо такие тонкие нюансы редко встречаются в повседневной работе.
Да ни разу это не тонкий нюанс, что вы в самом деле. Меня глубина пафоса аж поразила, а оказалось, все на полном серьезе.
Если бы программисты почаще задумывались как работает машина, код бы не содержал такого:
или даже такого:
А вот железячники сделали правильно, что пустая ячейка памяти эквивалентна инструкции nop.
Кто виноват? То ли авторы компилятора, то ли авторы программы на Це, история умалчивает :)
ROM:055E ; Micro delay
ROM:055E
ROM:055E Delay_??: ; CODE XREF: sub_ROM_298+4p
ROM:055E ; sub_ROM_2A2+4p ...
ROM:055E nop
ROM:0560 nop
ROM:0562 nop
ROM:0564 nop
ROM:0566 nop
ROM:0568 decfsz WREG, w, ACCESS
ROM:056A bra Delay_?? ; Micro delay
ROM:056C return 0
ROM:056C ; End of function Delay_??или даже такого:
ROM:056E unk_ROM_56E res 1 ; CODE XREF: ROM:STARTp
ROM:056F res 1
ROM:0570 res 1
и еще 780 байт NOP-ов
ROM:087F res 1
ROM:0880 ; ---------------------------------------------------------------------------
ROM:0880 movlw 73 ; 's' ; Initialisation?
ROM:0882 movwf OSCCON, ACCESS
А вот железячники сделали правильно, что пустая ячейка памяти эквивалентна инструкции nop.
Кто виноват? То ли авторы компилятора, то ли авторы программы на Це, история умалчивает :)
В данном случае — непрошитая ячейка в памяти программ, для флеш памяти все биты имеют значение 1.
Дело не в том, чем отличается прошитый и не прошитый NOP, а том что точка входа в подпрограмму и тело подпрограммы разделены кучей байт пустого места.
PS. NOP в программе компилируется как 0x00, а вот дешифратор команд считает NOP-ом как 0x00 так и 0xFF.
PS. NOP в программе компилируется как 0x00, а вот дешифратор команд считает NOP-ом как 0x00 так и 0xFF.
Наверное у них были на то причины. Для меня, например, было странно видеть такое в качестве части функции копирования области памяти до 255 байт. (это какая-то ява компилированая кажется, не помню как проект называется). Но оно вроде как должно быстрее выполняться, разворачивание цикла и все такое.
Вы знаете, этот java-компилятор — индус, он породил код достойный помойки. 126 операций, относительные смещения. Тогда как уже в 80286 уже была специальная команда для пересылки строк — MOVS.
Все, что надо было сделать:
и все что было, начиная с DS:SI до DS:[SI+ecx*4], быстро переедет по адресу начиная с ES:DI.
Не нужно слепо восторгаться всем, что делают авторитетные бородатые дядьки, даже с бейджиком «разработчик компилятора» на груди — они тоже не прочь говнеца написать.
Все, что надо было сделать:
mov ecx, 64 ; задать кол-во копируемых двойных слов
cld ; флаг направления - в сторону больших адресов
movsd ; скопировать строку двойными двойными словами за раз
и все что было, начиная с DS:SI до DS:[SI+ecx*4], быстро переедет по адресу начиная с ES:DI.
Не нужно слепо восторгаться всем, что делают авторитетные бородатые дядьки, даже с бейджиком «разработчик компилятора» на груди — они тоже не прочь говнеца написать.
Это не восхищение. Это недоумение. Я искренне хотел бы понять зачем так сделали и чем при этом руководствовались. А ссылку вы, наверное, хотели дать сюда?
Мне тоже непонятно. Может ради универсальности какой-то чтобы было проще портировать на другие архитектуры банальной заменой команд? Но тогда этот код будет везде неважнецки работать.
Действительно, ссылка должна быть на develab.narod.ru/asm/v10.htm
Я не то скопировал. Спасибо.
Действительно, ссылка должна быть на develab.narod.ru/asm/v10.htm
Я не то скопировал. Спасибо.
> Это команда (с префиксом rep) относилась к оптимизации по размеру, и при этом медленно работала.
> Важно понимать, что rep — это арифметика+условный переход, что сказывается на скорости работы.
Но при этом все действия происходят «совсем» внутри процессора, тут даже переход (изменение CS:IP) не нужно. Очень странно, чтобы это работало медленнее.
Впрочем, многое зависит от конкретной модели.
> Да, в вашем примере забыт «rep», иначе код не сработает.
Спасибо, забыл указать — последний раз прогал на ассемблере 15 лет назад :)
> Важно понимать, что rep — это арифметика+условный переход, что сказывается на скорости работы.
Но при этом все действия происходят «совсем» внутри процессора, тут даже переход (изменение CS:IP) не нужно. Очень странно, чтобы это работало медленнее.
Впрочем, многое зависит от конкретной модели.
> Да, в вашем примере забыт «rep», иначе код не сработает.
Спасибо, забыл указать — последний раз прогал на ассемблере 15 лет назад :)
Простите мой французский, но нахуя козе баян?
Если в девелопменте было больше людей, которые хоть чуть-чуть в курсе, что такое менеджмент и почему люди в средние века придумали вообще разделение труда, то думаю, не ныли бы щас про некий «кадровый голод».
Каждый должен делать то, что надо на своём уровне, а не лезть в устройство атомов, нейтрино и прочего, которые к тому же чуть ли Эйнштейна не опровергают.
Если в девелопменте было больше людей, которые хоть чуть-чуть в курсе, что такое менеджмент и почему люди в средние века придумали вообще разделение труда, то думаю, не ныли бы щас про некий «кадровый голод».
Каждый должен делать то, что надо на своём уровне, а не лезть в устройство атомов, нейтрино и прочего, которые к тому же чуть ли Эйнштейна не опровергают.
Комментарии автора зря минусуете — это очень и очень классно понимать как оно там очень близко к железу происходит. Конечно до фанатизма (абсурда) доводить не надо.
Такие вещи всегда загоняют люди, которые давно не программируют сами или близки к окончанию. Обычно эти опытные ребята имеют годы за плечами, но, увы, те навыки, что они получили, программируя на ассемблере в начале 90-х, уже никому никогда не понадобятся. И когда они пишут так скомкано, не пытаясь объяснить суть этих определений на пальцах мальцам, а вы… делываются (мягко говоря) перед ними — это показывает лишь то, что эти парни сильно комплексуют из-за того, что эта инфа больше никому не нужна. Они, поверьте, умные ребята, но просто расстроились. Это жизнь, здесь каждый будет у обочины, рано или поздно.
Такую объемную и сложную тему как архитектура x86 бесполезно выдавать на Хабре в виде небольших и поверхностных постов. Ваш же вообще на мой взгляд имеет отрицательную полезность, потому что он сумбурен, довольно конкретен, но при этом не объясняет абсолютно ничего.
— Ребята, адреса, которыми вы оперируете в программе, сначала сегментно преобразуются в линейное представление, затем странично — в физическое. Важно помнить и понимать, как это происходит.
— Что за мазохисты это напридумывали?!
— Ребята, адреса, которыми вы оперируете в программе, сначала сегментно преобразуются в линейное представление, затем странично — в физическое. Важно помнить и понимать, как это происходит.
— Что за мазохисты это напридумывали?!
Непонятно, кому может пригодиться эта статья.
Работа x86 уже отлично описана на www.wasm.ru
Прикладному программисту знать про GTD, LDT и прочие тонкости реального режима x86, не обязательно.
Работа x86 уже отлично описана на www.wasm.ru
Прикладному программисту знать про GTD, LDT и прочие тонкости реального режима x86, не обязательно.
ещё со времён моего детства и изучения асма, я задавался вопросом почему до сих пор тянут этот батхерт с экономией битов, «тесными» дескрипторами и прочей ерундой 80х годов?
Логический адрес --> Линейный (виртуальный)--> Физический
линейный адрес=Базовый адрес сегмента(на картинке это начало сегмента) + смещение
Я конечно не претендую на индивидуальность, но добавить стоит:
1) Логический адрес (его принято называть исполнительным\эффективным-EA-executive address) получается путем сложения трех 16-разрядных полей -смещение (displacement), базовых регистров (bx & bp) и индексных регистров (si & di). Это наши способы адресации.
2) Линейный адрес получается путем сложения предварительно сдвинутого на 4 бита влево адреса сегмента (получается вроде ******** ******** 0000 итого 20 бит) и полученного ранее эффективного адреса.
линейный адрес=Базовый адрес сегмента(на картинке это начало сегмента) + смещение
Я конечно не претендую на индивидуальность, но добавить стоит:
1) Логический адрес (его принято называть исполнительным\эффективным-EA-executive address) получается путем сложения трех 16-разрядных полей -смещение (displacement), базовых регистров (bx & bp) и индексных регистров (si & di). Это наши способы адресации.
2) Линейный адрес получается путем сложения предварительно сдвинутого на 4 бита влево адреса сегмента (получается вроде ******** ******** 0000 итого 20 бит) и полученного ранее эффективного адреса.
А в чем смысл статьи? Все это (и даже более подробно) можно прочитать в учебнике по ассемблеру, коих не мало на русском языке и, наверняка, в оцифрованном виде.
Большое спасибо за статью, как раз необходимо было узнать данную информацию.
Статья супер! Но насколько я знаю, EFLAGS 32-битный регистр. FLAGS, расширением над которым и является EFLAGS, как раз таки 16-битный
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация памяти