Приветствую в это нелегкое время. Я продолжаю цикл статей для предпринимателей и несколько следующих хочу посвятить краеугольному камню любого IT проекта или продукта — команде.
12 619 просмотров
Специфика IT
В отличие от многих сфер бизнеса, где “чем главнее, тем круче”, IT больше похож на медицину. Линейный разработчик, как и практикующий врач в частной клинике, может получать огромные деньги, значительно выше менеджмента.
Спрос на хороших специалистов очень высок. В IT не компания выбирает из ряда сотрудников, а сотрудник из ряда компаний. Следовательно, человек не будет бояться уйти, если его что-то не устраивает.
За последние годы доля крутых специалистов на рынке сильно уменьшилась. Еще 10 лет назад разработчиками и аналитиками становились только получившие профильное техническое образование и имеющие так называемую “базу”. Но с развитием онлайн-курсов и снижением порога входа в профессию за счет появления новых технологий на рынке с каждым днем становится все больше новичков, не имеющих опыта коммерческой разработки, которые хотят космические зарплаты.
Что такое команды и их параметры? — Уроки Python #1 | Космо
Все эти аспекты необходимо будет учитывать как при формировании своей команды, так и при работе со сторонней компанией.
Структура команды
В IT очень много вариантов построения связей в командах, и нет единого правильного рецепта. Структура зависит от рынка, типа продукта, стадии его развития и многого другого. Кому-то необходимы собственные юристы, отделы продаж и поддержки, но есть и компании из 5ти человек, работающие с такими гигантами как Meta.
Поэтому я решил выбрать наиболее популярный тип продукта — облачный сервис, имеющий сайт и мобильное приложение. Также сделаю допущение, что продажи автоматизированы. Тогда мы получим следующую верхнеуровневую структуру.
Во главе продукта стоит Product manager или Product owner. Разница есть, но для нас она не существенная. Он работает с рынком, общается с пользователями и инвесторами, определяет вектор развития продукта, генерирует гипотезы и пользовательские истории, приоритезирует их и много другое. Если упростить, он на основе данных решает, какие потребности и в каком порядке необходимо закрыть.
Например, он видит, что большое количество пользователей добавляют товары в корзину, но не покупают. Его задача — самостоятельно или, подключая команду, сформулировать гипотезы по увеличению конверсии и выбрать из них самые приоритетные на данный момент. Далее он передает их команде разработки (development team), которая поочередно их тестирует на части аудитории. Если результаты положительные, изменения внедряются на всех пользователей.
Marketing team отвечает за позиционирование продукта и привлечение пользователей. Support team — команда клиентской поддержки, отвечающая на вопросы пользователей. На старте продукта вам будет достаточно одного маркетолога, а клиентской поддержкой могут заниматься продакт и проджект менеджеры, получая при этом очень ценную обратную связь. Поэтому я не буду разбирать эти направления и сконцентрируюсь на команде разработки.
Разработка игр | Какие Профессии Существуют в геймдев — Что делают разработчики игр
Development team
Не стоит пугаться большому количеству человек. Целью схемы я ставил показать структуру команды, а не ее размер. Вполне реально, когда каждая из веток заканчивается на лиде, то есть все направление закрывает один специалист.
Project manager
Проектный менеджер отвечает за реализацию определенного функционала в рамках согласованных сроков и бюджета.
Он определяет методологию разработки, налаживает процессы в команде, составляет план разработки и многое другое. То есть решает, что именно (как закрывать потребность), как и когда делать. Получив от продакта гипотезу по корзине, он отправит ее аналитику на детализацию, затем подключит дизайнера и разработчиков для оценки. Если продакт посчитает реализацию целесообразной, ПМ добавит ее в план для последующей реализации, внесет это все в график работ, проконтролирует выполнение, а после завершения тестирования сдаст задачу, в результате чего на сайте и в мобильном приложении появятся изменения.
Аналитики бывают разные: бизнес-аналитики общего профиля; аналитики, специализирующиеся на конкретной области(логистике, медицине, …) и системные аналитики, чья деятельность подразумевает наличие компетенций разработчика и архитектора.
Бизнес-аналитики составляют бОльшую часть всех аналитиков в рамках стартапов, поэтому разберу именно их. Компетенции БА я разделяю на две больших области: продуктовая аналитика и формирование требований.
О продуктовой аналитике, которую необходимо провести до начала реализации, я писал в прошлых двух статьях: Есть идея IT-продукта. Что делать дальше? и Зачем нужен MVP. Помимо описанных там анализа ЦА, конкурентов и рынка, проведения проблемных и решенческих интервью, арсенал продуктового аналитика включает в себя большой спектр инструментов, позволяющих находить точки роста. Итогом этой части работы становятся пользовательские истории — формулировки вида “как покупатель, я хочу фильтровать товары, чтобы выбирать только среди релевантных” с различными дополнениями и ограничениями вроде названий фильтров или максимально рентабельной стоимости разработки. Это своего рода условия задачи.
Когда пользовательские истории сформированы, то есть понятно, какие потребности нужно закрыть, аналитик переходит к поиску решений. Использовать сторонний сервис или реализовать самим, делать эффективнее, но дороже и дольше или упростить, уменьшив стоимость и сроки и тд. Определив вариант реализации, проконсультировавшись с лидами других направлений, он приступает к его проработке: детализирует требования, проверяет их на полноту(все аспекты учтены) и непротиворечивость с уже реализованным функционалом. В итоге получается ТЗ.
Получив задачу по детализации требований к онлайн-оплате, он должен изучить эквайринги и платежные сервисы, представленные на рынке на соответствие заявленным требованиям, отбросить явно проигрышные и предоставить результаты для выбора продакту, ПМу и клиенту. Когда те выберут конкретный сервис, учтя условия самого сервиса, стоимость интеграции, качество документации и т.д., он должен детализировать требования для интеграции с конкретным сервисом, в результате чего будет получена задача для дизайнеров и разработчиков.
У лидов в каждом из направлений есть ряд дополнительных свойств. Они обладают всей информацией в рамках своего направления, что позволяет консультировать лидов других направлений, ПМа и продакта.
Лиды определяют “правила игры” в своем отделе: какие инструменты, подходы, технологии и тд будут использоваться. Если каждый сотрудник в направлении будет делать по-своему, об эффективности можно забыть.
Они выступают в роли менторов и координаторов для своей команды. Почти в любом проекте есть простые задачи, неэффективно сажать на них опытного специалиста. Лид отдаст такую задачу новичку, проконтролирует ход ее выполнения и качество результата. В итоге качество останется неизменным, зато клиент сэкономит деньги, а новичок получит опыт и в следующий раз сделает подобную задачу быстрее.
Веб или мобильный дизайнер не “рисует картиночки”, как часто думают об этой профессии. Это в большей степени техническая позиция, чем творческая. Его ключевая задача — проектирование и дальнейшее улучшение пользовательского опыта при взаимодействии с продуктом, где “красота” сама по себе не имеет лидирующих позиций.
Работу дизайнера можно условно разделить на 3 части:
- Проектирование интерфейса на основе пользовательского опыта с целью оптимизации пользовательских путей и упрощения обучения. Иными словами, за какой количество действий пользователь сможет достичь цели, а также какова вероятность ошибки на этом пути из-за неправильной интерпретации интерфейса.
- Разработка пользовательского интерфейса. Этот пункт подразумевает стилистику продукта: цвета, шрифты и т.д. Их грамотная композиция расставляет акценты, упрощает поиск объектов в рамках отображаемого на экране, а значит и улучшает продуктовые метрики.
- Третьей, но не менее важной задачей являются техника и качество реализации самих макетов. В этом помогает дизайн-система. Это определенные правила разработки макетов, которые упрощают и ускоряют работу с макетами для самих дизайнеров и разработчиков, уменьшают количество ошибок и делают интерфейс целостным, а значит экономят бюджет и уменьшают сроки реализации.
Фактически, техлид — это технический директор на конкретном проекте или продукте. В его зоне ответственности верхнеуровневые вопросы разработки: используемые технологии, архитектура проекта, управление всеми направлениями разработки и тестированием. Также он является мостом между разработчиками и не разработчиками и должен балансировать между качеством реализации и эффективностью достижения бизнес-целей.
Техлидами становятся очень опытные разработчики, имеющие развитые коммуникативные навыки. Фактически это второй ПМ, только с другими хард-скилами.
Принцип работы приложений
Перед тем как переходить к зонам ответственности разработки, необходимо на элементарном уровне понять принцип работы веб или мобильного приложения.
Клиент — веб или мобильное приложение — эта та часть, которую видит пользователь. Например, пользователь интернет-магазина, находясь в разделе кроссовки, выбрал в фильтре по бренду Nike. Тогда клиент посылает запрос на сервер, говоря “пришли мне все кроссовки Nike”.
Сервер получает и обрабатывает этот запрос: команда проекта заранее определила, что пользователям должны показывать только товары, которые есть в наличии. Сервер обращается к базе данных, которая формально может быть как на этом, так и на другом сервере: “пришли мне все кроссовки с брендом Nike, которые есть в наличии”. В ответ сервер получает список товаров, но, если отправить все сразу, страница у пользователя может грузиться очень долго. Поэтому на сервере товары дробятся на страницы, а на клиент приходит ответ: “Всего нашлось 147 товаров, я разделил их на 8 страниц по 20 товаров, держи первые 20”. В итоге у пользователя отображаются первые 20 кроссовок Nike.
Большое приложение может иметь множество серверов и баз данных, но описанные выше принципы будут неизменны.
Front-end developers
В простонародье, фронты. Это направление разработчиков отвечает за клиентскую часть веб-приложения, то есть то, что вы видите в браузере. Он получает макеты от дизайнеров, верстает их (размечает на элементы и задает им свойства), пишет логику, которая выполняется в браузере, обменивается данными с сервером и адаптирует сайт под разные браузеры и разрешения.
В процессе работы он больше всего взаимодействует с дизайнерами по вопросу макетов и с серверными разработчиками(back-end developers) по обмену данными.
Mobile developers
Суть работы мобильного разработчика очень похожа на работу фронта, только вместо браузеров он ориентируется на требования операционные системы и устройства. Фронты, конечно, тоже учитывают их, но мобильные разработчики значительно сильнее от них зависят.
Мобильных разработчиков по используемым технологиям можно разделить на нативных и кроссплатформенных. Первые пишут приложения для конкретной ОС(iOS или Android), вторые сразу под обе.
Еще одним важным отличием мобильной разработки от веба является публикация приложений в сторах. Опубликовать свой сайт максимально просто: нужно только сервер и домен. Он может быть сколь угодно ужасно написан или вообще представлять собой пустую страницу — никаких ограничений! Мобильное приложение, в свою очередь, должно пройти проверку в сторах.
Оно должно содержать описание, скриншоты, быть достаточно высокого качества и быть полезным(приложение, где будет только фото вашего котика, забракуют). Эти проверки еще на несколько дней отложат долгожданный запуск.
Back-end developers
Бэки отвечают за серверную часть приложения и базу данных. Они пишут код, обрабатывающий запросы от фронта, делают запросы к базе, настраивают серверы и тд.
Тестировщики бывают ручные и автоматические. Ручные сами протыкивают все сценарии, автоматические пишут код, который проверяет код самого приложения.
Итоговая цель любого тестировщика — обеспечить высокое качество продукта.
Для этого они пишут тест-кейсы (последовательность действий при тестировании и ожидаемые результаты), проверяют приложение в разных браузерах и на разных устройствах, описывают найденные баги и передают команде, а в конце проверяют исправления.
Важно понимать, что проверить абсолютно все невозможно. Поэтому тестировщику важно правильно определять область применения усилий, чтобы достичь требуемого уровня качества за меньшее время.
Помимо работы с багами тестировщики также могут анализировать пользовательский опыт при работе в приложении на предмет его улучшения.
Заключение
Как вы видите, команда проекта состоит из большого числа специалистов в разных областях. На небольших проектах количество человек в одном направлении обычно не превышает 2-3 человек, и проседание любого из них сильно ухудшит итоговый результат команды. Это делает рекрутинг одним из важнейших факторов успеха.
В следующей статье я разберу, в каких случаях лучше собрать команду самому, а когда обращаться к сторонней. Если статья была вам полезна, буду благодарен за лайк и подписку. Всем мир, до скорых встреч✌
Источник: vc.ru
СИСТЕМА КОМАНД ЭВМ И СПОСОБЫ ОБРАЩЕНИЯ К ДАННЫМ
Важной составной частью архитектуры ЭВМ является система команд. Несмотря на большое число разновидностей ЭВМ, на самом низком («машинном») уровне они имеют много общего. Система команд любой ЭВМ обязательно содержит следующие группы команд обработки информации.
1. Команды передачи данных (перепись), копирующие информациюиз одного места в другое.
2. Арифметические операции, которым фактически обязана своим названием вычислительная техника. Конечно, доля вычислительных действий в современном компьютере заметно уменьшилась, но они по-прежнему играют в программах важную роль. Отметим, что к основным арифметическим действиям обычно относятся сложение и вычитание (последнее в конечном счете чаще всего тем или иным способом также сводится к сложению). Что касается умножения и деления, то они во многих ЭВМ выполняются по специальным программам.
3. Логические операции, позволяющие компьютеру анализировать обрабатываемую информацию. Простейшими примерами могут служить сравнение, а также известные логические операции И, ИЛИ, НЕ (инверсия). Кроме того к ним часто добавляются анализ отдельных битов кода, их сброс и установка.
4. Сдвиги двоичного кода влево и вправо. Для доказательства важности этой группы команд достаточно вспомнить правило умножения столбиком: каждое последующее произведение записывается в такой схеме со сдвигом на одну цифру влево. В некоторых частных случаях умножение и деление вообще может быть заменено сдвигом (вспомните, что дописав или убрав ноль справа, т.е. фактически осуществляя сдвиг десятичного числа, можно увеличить или уменьшить его в 10 раз).
5. Команды ввода и вывода информации для обмена с внешними устройствами. В некоторых ЭВМ внешние устройства являются специальными служебными адресами памяти, поэтому ввод и вывод осуществляется с помощью команд переписи.
6. Команды управления, реализующие нелинейные алгоритмы. Сюда прежде всего следует отнести условный и безусловный переход, а также команды обращения к подпрограмме (переход с возвратом). Некоторые ЭВМ имеют специальные команды для организации циклов, но это не обязательно: цикл может быть сведен к той или иной комбинации условного и безусловного переходов. Часто к этой же группе команд относят немногочисленные операции по управлению процессором -типа «останов» или НОП («нет операции»). Иногда их выделяют в особую группу.
С ростом сложности устройства процессора увеличивается и число команд, анализирующих состояние управляющих битов и воздействующих на них. Здесь для примера можно назвать биты режима работы процессора и биты управления механизмами прерываний от внешних устройств.
В последнее время все большую роль в наборе команд играют команды для преобразования из одного формата данных в другой (например, из 8-битного в 16-битный и т.п.), которые заметно упрощают обработку данных разного типа, но в принципе могут быть заменены последовательностью из нескольких более простых команд.
Рассматриваясистему команд, нельзя не упомянуть о двух современных взаимно конкурирующих направлениях в ее построении: компьютер с полным набором команд CISC (Complex Instruction Set Computer) и с ограниченным набором — RISC (Reduced Instruction Set Computer). Разделение возникло из-за того, что основную часть времени компьютеру приходится выполнять небольшую часть из своего набора команд, остальные же используются эпизодически (в одной из популярных статей это в шутку сформулировано в виде следующей наглядной аналогии: «20% населения выпивают 80% пива»). Таким образом, если существенно ограничить набор операций до наиболее простых и коротких, зато тщательно оптимизировать их, получится достаточно эффективная и быстродействующая RISC-машина. Правда за скорость придется платить необходимостью программной реализации «отброшенных» команд, но часто эта плата бывает оправданной: например, для научных расчетов или машинной графики быстродействие существенно важнее проблем программирования. Подробнее вопросы, связанные с системой команд современных микропроцессоров, будут рассмотрены ниже в этой главе.
Подводя итог, еще раз подчеркнем, что основной набор команд довольно слабо изменился в ходе бурной эволюции ЭВМ. В то же время способы указания адреса расположения информации в памяти претерпели значительное изменение и заслуживают особого рассмотрения.
Команда ЭВМ обычно состоит из двух частей — операционной и адресной. Операционная часть (иначе она еще называется кодом операции — КОП) указывает, какое действие необходимо выполнить с информацией. Адресная часть описывает, где используемая информация хранится. У нескольких немногочисленных команд управления работой машины адресная часть может отсутствовать, например, в команде останова; операционная часть имеется, всегда.
Код операции можно представить себе как некоторый условный номер в общем списке системы команд. В основном этот список построен в соответствии с определенными внутренними закономерностями, хотя они не всегда очевидны.
Адресная часть обладает значительно большим разнообразием и ее следует рассмотреть подробнее.
Прежде всего отметим, что команды могут быть одно-, двух- и трехадресные в зависимости от числа участвующих в них операндов.
Первые ЭВМ имели наиболее простую и наглядную трехадресную систему команд. Например: взять числа из адресов памяти А1 и А2, сложить их и сумму поместить в адрес A3. Если для операции требовалось меньшее число адресов, то лишние просто не использовались. Скажем, в операции переписи указывались лишь ячейки источника и приемника информации А1 и A3, а содержимое А2 не имело никакого значения.
Трехадресная команда легко расшифровывалась и была удобна в использовании, но с ростом объемов ОЗУ ее длина становилась непомерно большой. Действительно, длина команды складывается из длины трех адресов и кода операции.
Отсюда следует, например, что для скромного ОЗУ из 1024 ячеек только для записи адресной части одной команды требуется 3*10 = 30 двоичных разрядов, что для технической реализации не очень удобно. Поэтому появились двухадресные машины, длина команды в которых сокращалась за счет исключения адреса записи результата. В таких ЭВМ результат операции оставался в специальном регистре (сумматоре) и был пригоден для использования в последующих вычислениях. В некоторых машинах результат записывался вместо одного из операндов.
Дальнейшее упрощение команды привело к созданию одноадресных машин. Рассмотрим систему команд такой ЭВМ на конкретном простом примере. Пусть надо сложить числа, хранящиеся в ячейках с адресами ОЗУ А1 и А2, а сумму поместить в ячейку с адресом A3. Для решения этой задачи одноадресной машине потребуется выполнить три команды:
• извлечь содержимое ячейки А1 в сумматор;
• сложить сумматор с числом из А2;
• записать результат из сумматора в A3.
Может показаться, что одноадресной машине для решения задачи потребуется втрое больше команд, чем трехадресной. На самом деле это не всегда так. Попробуйте самостоятельно спланировать программу вычисления выражения А5 = (А1 + А2)*АЗ/А4 и вы обнаружите, что потребуется три трехадресных команды и всего пять одноадресных. Таким образом, одноадресная машина в чем-то даже эффективнее, так как она не производит ненужной записи в память промежуточных результатов.
Ради полноты изложения следует сказать о возможности реализации безадресной (нуль-адресной) машины, использующей особый способ организации памяти -стек. Понимание принципов устройства такой машины потребовало бы некоторых достаточно подробных разъяснений. Сейчас безадресные ЭВМ практически не применяются. Поэтому ограничимся лишь упоминанием того факта, что устроенная подобным образом система команд лежала в основе некоторых программируемых микрокалькуляторов (например, типа «БЗ-21» и «БЗ-34» и им подобных).
До сих пор в описании структуры машинной команды мы пользовались интуитивным понятием об адресе информации. Рассмотрим теперь вопрос об адресации элементов ОЗУ более подробно и строго. Наиболее просто была организована память в ЭВМ первых двух поколений. Она состояла из отдельных ячеек, содержимое каждой из которых считывалось или записывалось как единое целое.
Каждая ячейка памяти имела свой номер, который и получил название адреса. Очевидно, что адреса соседних ячеек ОЗУ являются последовательными целыми числами, т.е. отличаются на единицу. В рассматриваемых ЭВМ использовались данные только одного типа (вещественные числа), причем их длина равнялась длине машинной команды и совпадала с разрядностью памяти и всех остальных устройств машины. Для примера укажем, что ячейка типичной ЭВМ второго поколения состояла из 36 двоичных разрядов.
Очень часто программа предназначалась для обработки по одним и тем же формулам определенного количества содержимого последовательно расположенных ячеек (в языках высокого уровня такого рода структуры получили впоследствии название массивов). В ЭВМ первых двух поколении были предусмотрены особые механизмы циклической обработки массивов информации.
С этой целью в машинных командах помимо обычных адресов можно было использовать модифицируемые, у которых специальный управляющий бит был установлен в единицу. К помеченным таким образом модифицируемым адресам при выполнении команды прибавлялось значение из специальных индексных ячеек. Меняя содержимое индексных ячеек, можно было получать доступ к различным элементам массива. Особо подчеркнем, что формирование результирующего адреса осуществлялось в УУ в момент исполнения команды, поэтому исходная команда в ОЗУ сохранялась без изменений.
Описанный механизм модификации адресов существенно упрощал написание циклических программ, таких как нахождение суммы последовательных ячеек ОЗУ, копирование отдельных участков памяти и т.п.
В ЭВМ третьего поколения идеология построения памяти существенно изменилась: минимальная порция информации для обмена с ОЗУ была установлена равной 8 двоичных разрядов, т.е. один байт. Стало возможным обрабатывать несколько типов данных: символы текста (1 байт), целые числа (2 байта), вещественные числа обычной или двойной точности (4 или 8 байт соответственно).
В связи с этим была введена новая условная единица измерения информации — машинное слово. Оно равнялось 4 байтам и соответствовало длине стандартного вещественного числа. Все объемы информации начали измеряться в единицах, кратных слову: двойное слово, полуслово и т.п.
Естественно, что адрес (номер ячейки ОЗУ) в машинах с байтовой организацией стал относится к отдельному байту; байты памяти имеют возрастающие на единицу номера. Слово состоит из нескольких последовательно расположенных байтов. В качестве адреса слова удобно принимать адрес одного из образующих его байтов (обычно используется младший байт, имеющий наименьший номер). Таким образом, адреса слов меняются уже не через единицу; их приращение зависит от длины машинного слова в байтах и равняется четырем.
Размер машинного слова был, по-видимому, выбран исходя из форматов обрабатываемой информации, а не в связи с разрядностью каких-либо устройств. Для подтверждения этого приведем несколько фактов о типичных ЭВМ третьего поколения из семейства ЕС. Арифметико-логическое устройство модели «ЕС-1022» имело 16 двоичных разрядов, «ЕС-1033» — 32 разряда, а «ЕС-1050» — 64 разряда. В то же время за одно обращение к оперативной памяти в «ЕС-1022» и «ЕС-1033» выбиралось 4 байта, в «ЕС-1050» — 8 байт (а в «ЕС-1045» — 16 байт). Таким образом, разнообразие цифр свидетельствует, что 32 разряда (4 байта) не являлись каким-то технически выделенным объемом информации.
В машинах третьего поколения появились иеще несколько особенностей: разная длина команд в зависимости от способа адресации данных, наличие специальной сверхоперативной регистровой памяти, вычисление эффективного адреса ОЗУ как суммы нескольких регистров и т.п. Все это получило дальнейшее развитие в компьютерах четвертого поколения, для которых разрядность микропроцессора стала одной из важнейших характеристик. Рассмотрение особенностейстроения памяти ЭВМ четвертого поколения отложим до следующего раздела.
Контрольные вопросы
1. Что такое архитектура ЭВМ? Сформулируйте определение и расшифруйте его.
2. Проведите аналогию между архитектурой ЭВМ и обыденным понятием архитектуры. Что общего и в чем различие?
3. Что общего и в чем различие между понятиями «внутреннее устройство ЭВМ»
и «архитектура ЭВМ»?
4. Что такое семейство ЭВМ? Приведите примеры.
5. Объясните, в чем состоит принцип программной совместимости. Что такое совместимость снизу вверх (поясните на примере одного из известных вам семейств)?
6. Имеют ли отношение к понятию «архитектура» следующие факты:
а) в компьютере применяются микросхемы динамического (или статического) ОЗУ?
б) компьютер имеет расширенную память?
в) компьютер имеет (не имеет) общую шину, по которой передается информация между его устройствами?
г) в процессоре INTEL 80386 к системе команд добавлено по сравнению с INTEL 80286 несколько новых?
д) объем памяти новой модели ЭВМ увеличен вдвое?
8. Чем обусловлено в ЭВМ широкое применение двоичной системы?
9. Можно ли. посмотрев на содержимое отдельно взятой ячейки памяти, определить, какая информация в ней записана: число, команда, символы?
10. Из каких основных рлов состоит ЭВМ?
11. Что такое счетчик команд и какую роль он играет?
12. Что такое магистраль (шина)?
13. Какие преимущества имеет магистральная структура ЭВМ?
14. Что представляет собой контроллер внешнего устройстваи какую роль он играет в процессе обмена информацией?
15. Какую роль играет в компьютере видеопамять?
16. Оцените необходимый объем видеопамяти для следующихрежимов:
а) текстовый режим (24 строки по 80 символов);
б) графический черно-белый режим при размере экрана 640х200 точек;
в) 16- цветный режим при том же размере экрана.
17. Что такое режим прямого доступа к памяти?
18 Как называется элементарная составляющаямашинной команды? От чего может зависеть скорость выполнения команды?
19. Опишите основные этапы выполнения машинной команды. Особое внимание
обратите на роль счетчика команд.
20. Что такое конвейерная обработка команд и какие преимущества она имеет?
21. Какие основные операции входят в состав системы команд любой ЭВМ?
Кратко охарактеризуйте каждою из названных групп.
22. Объясните, почему возможно создать компьютер с уменьшенным (неполным)
набором команд и что это дает.
23. Из каких частей состоит команда ЭВМ? Кратко охарактеризуйте их назначение.
24. Чем различаются одно-, двух- и трехадресные команды?
25. Что такое адрес ОЗУ?
26. Как можно использовать одну и ту же команду для работы с несколькими
последовательно расположенными ячейками?
27. Укажите отличия в устройстве памяти ЭВМ третьего поколения по сравнению с двумя предыдущими.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Иллюстрированный самоучитель по теории операционных систем
Команда центрального процессора состоит из кода операции и одного или нескольких операндов (объектов, над которыми совершается операция). В зависимости от числа операндов, команды делятся на безадресные (не имеющие операндов или имеющие неявно указанные), одноадресные (производящие операцию над одним объектом или одним явно и одним или несколькими неявно указанными), двух- и трехадресные. Встречаются архитектуры, в которых есть команды и с большим числом операндов, но это экзотика.
Примеры безадресных команд без операнда:
- NOP – No OPeration, отсутствие операции.
- HALT – Остановка процессора
Примеры безадресных команд с неявно указанными операндами:
- RETURN – Возврат из подпрограммы. Выталкивает из стека адрес возврата и помещает его в счетчик команд.
- WDR – WatchDog Reset, сброс сторожевого таймера микроконтроллера.
- ADD – Вытолкнуть из стека два значения, сложить их и протолкнуть результат в стек.
- SCS – Skip if Carry Set, пропустить следующую команду, если бит переноса в слове состояния установлен.
Примеры одноадресных команд с одним операндом:
- INC x – INCrement, добавить к операнду 1 и сохранить результат по тому же адресу.
- TST х TeST – Установить в слове состояния флаги знака и равенства нулю в соответствии со значением операнда.
Примеры одноадресных команд с неявным операндом:
- ADD x [, Асс] – Сложить операнд с аккумулятором и сохранить результат в аккумуляторе.
- PUSH х – Протолкнуть значение операнда в стек.
- CALL x – Вызов подпрограммы, сохраняет адрес следующей команды в стеке и передает управление по указанному адресу.
- BNEQ х – Передает управление по указанному адресу, если в слове состояния установлен флаг равенства нулю.
Примеры двух- и трехадресных команд:
- MOVE x, у – Присвоить значение объекта х объекту у.
- ADD x, у – Сложить х и у, поместить результат в у.
- ADD x, у, z – Сложить х и у и поместить результат в z.
DIV х, у, z, w – выполняет деление х на у, помещает частное в z, а остаток – в w.
INDEX b, I, h, s, i, a – Вычисляет адрес элемента массива, расположенного по адресу b, с нижней и верхней границами индекса I и b соответственно и размером элемента s.
Операнд i – индекс элемента, а – место, куда следует поместить вычисленный адрес.
Количество адресов иногда используют и для общей характеристики системы команд. Двухадресной называют систему команд, в которой команды имеют максимум два операнда, трехадресной – максимум три. Нередко, впрочем, вместо максимального количества операндов, адресность системы команд определяют по количеству операндов у наиболее «ходовых» команд – сложения и вычитания. Таким образом, VAX, из системы команд которого взяты примеры четырех – и шестиадресных команд, часто относят к трехадресным архитектурам.
Одноадресные системы команд обычно используют в качестве неявно заданного операнда выделенный регистр, так называемый аккумулятор, или стек. Такие архитектуры называют, соответственно, аккумуляторными и стековыми.
Одноадресную аккумуляторную архитектуру имеют микроконтроллеры семейства PIC фирмы Microchip. Большинство современных процессоров имеют двух – и трехадресные системы команд.
На примере стековой команды ADD мы видели, что многие из команд стековой архитектуры могут обойтись вообще без явно указанных операндов, однако команды проталкивания значений переменных в стек и выталкивания их оттуда все-таки необходимы, поэтому все стековые архитектуры одно-, а не безадресные.
Стеки привлекательны, во-первых, тем, что не нуждающиеся в операндах команды могут иметь очень короткий код операции (как правило, достаточно одного байта) и, во-вторых, тем, что работающая с ними программа представляет собой арифметическое выражение, записанное в обратной польской нотации – когда мы сначала пишем операнды, а потом знак операции. Например, операция а+b в этой записи выглядит как ab+ (в программе – push a; push b; add;).
Задача преобразования привычных нам арифметических выражений в обратную польскую запись легко формализуется, поэтому стековые процессоры долгое время позиционировались как «ориентированные на языки высокого уровня». Позже, впрочем, выяснилось, что более сложная логика разбора арифметических выражений позволяет проводить разного рода оптимизации (сокращать введенные лишь для удобства записи переменные, заменять выражения, которые всегда дают одно и то же значение, на константы, выносить повторяющиеся вычисления из тела цикла и т. д.).
Аппаратно реализованные стековые архитектуры – в наше время редкость. Из относительно современных процессоров, имевших коммерческий успех, можно назвать Transputer фирмы Inmos (в настоящее время эти микропроцессоры выпускаются фирмой SGC-Thomson).
Шире всего стековая архитектура распространена в байт-кодах или, как это еще называют, системах команд виртуальных машин. Байт-код – это промежуточное представление программы, используемое интерпретатором, чтобы избежать лексического и синтаксического анализа программы на этапе исполнения. Исполнение байт-кода осуществляется не процессором, а программой-интерпретатором. Таким образом, реализуются многие современные языки программирования – многочисленные диалекты языка BASIC, Lisp, SmallTalk, Fort (этот язык любопытен тем, что сам имеет стековый синтаксис), наконец Java.
Некоторые реализации интерпретаторов этих языков используют так называемую JIT-компиляцию (Just In Time, точно в момент исполнения), когда перед исполнением байт-код компилируется в систему команд физического процессора. Такая технология позволяет достичь для «интерпретируемых» программ производительности, не уступающей производительности компилированного кода.
Первым промышленным применением JIT-компиляции была система AS/400 фирмы IBM. В настоящее время JIT широко используется в реализациях Java. JIT-компиляция привлекательна тем, что позволяет исполнять один и тот же код на разнообразных процессорах без потерь (или почти без потерь) скорости.
Источник: samoychiteli.ru