Позволю себе открыть новую тему сомнительного содержания. Она не претендует на информативность и полезность. Поэтому я и назвал её соответствующе. Фундамент: Работая с эмулятором Bochs я несколько раз ловил себя на мысли, почему полноценно нельзя наблюдать за ходом продвижения загадочного на данный момент процесса? Вот возьмём в пример фильм "Солярис", "Отраки во вселенной" и т.п. советской киноиндустрии. Как там изображены ЭВМ? Большое табло с кучей мигающих цветных квадратиков-индикаторов загадочных процессов... Опора: Как и в любой радиотехнике, где в узлах имеются контрольные точки с осцилографируемыми формами, способствующие облегчению отладки. Нечто подобное следовало бы давно ввести и в программном обеспечении. Долгое время указатель курсора в графическом режиме был всегда программной реализацией. Сейчас я слышал о аппаратной поддержке графического указателя современными видеокартами. Что означает, графический указатель перестал быть игрушкой... Набросок: Идеально было бы иметь в пространстве портов компьютерной системы несколько опциональных регистров. Скажем, ещё в первых IBM PC-XT в те порты можно было бы оперативно записывать прогресс чтения с дискеты и текущий индекс дорожки / сбойного сектора. В среде DOS архиваторы могли бы туда вписывать прогресс сжатия файлов и т.д. Иными словами, холостые порты, значение которых могло интерпретироваться как операционной системой, так и самой аппаратурой в будущем. Скажем, видеокарта сама инспектирует их значения и тихо выводит прямо на монитор его процессором в виде OSD... Опционально конечно. При отладке вычислительных систем, процент функций отладчика мог бы взять сам процессор монитора более-менее продвинутого. В худшем случае, моргать 5-8-ю светодиодами на лицевой панели или имитировать прогресс-бар. То же самое можно сказать о клавиатуре. Почему передняя её часть не может иметь линейку-индикатор в качестве прогресс бара? Дорого? Помилуйте! Читал я про Dendy, где разработчики съэкономили на одной микросхеме памяти, чтобы удешевить конструкцию на пару процентов стоимости. Во что это вылилось, знают все. Как и в случае с проблемой 2000. Но вот в наше же время можно делать по стандарту клавиатуры с секретными тумблерами, портом под джойстик Sega/PSX, ИК-глазком. Чтобы не надо было паять к LPT всякую дрянь для подключения джойстка. Или паять к COM-порту приёмник ИК-сигналов от ПДУ. Что за секретные тумблеры в клавиатуре? Скажем, пошёл я по делам на 5 минут, а компьютер важно занят. Шёлк тумблером на дне клавиатуре и всё. Нет, клавиатура не отключается. Но системный драйвер переходит в режим шпиона и пишет в лог все нажатия на клавиши. Вдруг там кот лапами прошёл или годовалый ребёнок похлопал по всем клавишам! А если ребёнок поиграть хочет? Ставить всякие I hate this key и прочую мерзость я не хочу. Шёлк тумблером и клавиатура реагирует лишь на стрелки и пробел. Пусть малыш веселиться без ущерба мне! А джойстик? Воткнул прямо в клавиатуру, настроил драйвер и всё. Можешь хоть кодом Браилья набирать конспект! А можешь и в Тетрис джойстиком играть. Ведь пространство скэн-кода ничем не ограниченно! Можно подключить ещё сотню клавиш хоть джойстиков, хоть ПДУ, хоть дублировать обычные клавиши... Вот грузится винда в Bochs и ждёшь, ждёшь. Хоть бы индикатор был бы, порт, по которому Bochs знал бы, что программа сейчас делает, чтобы пользователя держать в курсе событий... Эх, не продумали аппаратную и теоритическую программную сторону машин.
видел как-то на выставке теплый ламповый переключатель-преемник, который на каждое событие грел душу и радовал глаз. вот это я понимаю - патент.
Paguo_86PK "загадочный в данный момент процесс" вы можете наблюдать только, максимум, очень очень поверхностно. а в подавляющем большинстве случаев, вы его не заметите. вот скажите, что, никто до ньютона не видел падающих яблок? или не било от сухой шерсти током еще троглодитов? нефик делать. бош же эмулирует проц и все остальное полностью. те это интерпретатор. захотите - сделаете, что вы там себе хотите.
Вы не совсем поняли меня. Смотрите, на кейсе есть единственный оперативный индикатор активности HDD-контроллера. А на клавиатуре - 3 индикатора состояния регистров клавиатуры. Тем самым, 4 индикатора загадочных процессов - ответы на вопросы: 1) А идёт ли доступ сейчас к диску или программа висит и 2) В каком регистре я сейчас начну печатать и не завис ли компьютер вообще? 3) На старых машинах была ещё турбо-индикация частоты процессора. Или забыли уже? Я же просто подумал, что не плохо бы несколько развернуть загадочность. Скажем, вместо красного светодиода одного - несколько в круг. Идёт доступ - они иллюзорно вертятся. А если система повисла - тупо горят. Ясна суть? Тут загадочность процесса проясняется! Не надо гадать и прислушиваться к винту... Бош наворотить - раз плюнуть. Я же говорю о коренной поддержке таких фич ещё на заре компьютеров. Вот допустим я сейчас конструирую свою систему. В данной позиции я позабочусь о проекции прогрессивности доступа к диску ещё на уровне драйвера, хотя на материнской плате никаких интерфейсов ставить не буду. Но в Data sheet укажу что-то типо "Текущее состояние управляющего драйвера жёсткого диска проецируется на служебную ячейку по вектору ###. Разработчики программного обеспечения или оборудования могут инспектировать и использовать данные по своему усмотрению..." Иными словами. Вот в DOS по вектору 0040:xxxx расположена область служебных переменных. В Bochs или даже самопальной ISA-карточкой как нефиг делать отображать их содержимое хоть на семисегментный индикатор в железе, хоть графикой эмулятора. Но!!! Проблема в том, что ни в DOS, ни в *nix-подобных системах нету вообще таких ячеек, где оперативно можно железом/эмулятором прочесть состояние системы. Нету ни устного правила, ни письменного, что любой архиватор должен оперативно вписывать прогресс-информацию в ячейку XXX. А кто читать и интерпретировать будет её, эмулятор/система или даже контроллер мыши с "секундомером" на её корпусе - это решит пользователь или разработчик железа... Понятно теперь о чём я?
IHMO. Это тема. К примеру отладка. Распихать по портам содержимое регистров. Написать для этого драйвер и пусть выводит на LCD, а его вывести на панель. Прога висит, видно где ...
Paguo_86PK По поводу аппартного курсора вы заблуждаетесь - он был всегда, просто он был негибкий. Второй похожий случай - в 286 была аппаратная поддержка виртуальной памяти, но она оказалась неудобной и использовали чисто программную реализацию. И это ответ на ваш вопрос - некоторые вещи лучше не делать аппаратно, т.к. программная реализация более гибкая. Одному надо пять лампочек, другому семь - придется в хард ставить микропроцессор и колодку под световую панель. Да и аппаратное с виду - это тоже программное. Даже единственной лампой харда мигает микропроцессор по ПРОГРАММЕ и естественно лампа напрямую не связана с реальным обменом проводами! Т.ч. ваше предложение - это иллюзия чистой воды и как многие ваши иллюзии - от незнания.
Paguo_86PK А во что, кстати? Про "Денди" я не в курсе, у меня его не было. Знаю только, что на "Фамикомах" не вся хирагана в кодовую таблицу влезла и от этого японский народ сурово пострадал.
Здесь и с помощью гугла можно легко найти о недостатках. А так. Помните в Basic PC-XT были директивы MOTOR ON и MOTOR OFF, а на фотографии материнки в книге "Современный компьютер" середины 80-ых, помимо клавиатурного коннектора рядом был ещё к магнитофону. Будь он сейчас, можно было и его задействовать в моддинге или отладке...
Paguo_86PK И зачем бы он был нужен сейчас? Или это абстракность на дополнительные интерфейсы? LPT есть даже сейчас, например. Действуйте.
Paguo_86PK У вас очень странные взгляды. Если есть что-то в железе, то это не значит, что это будут поддерживать программно, особенно свистелки/пирделки. IBM PC это открытая архитектура, в которой никто не будет заставлять делать свистелки/пирделки. И возвращайтесь уже из прошлого, сейчас рулят быстрые последовательные шины, а не магнитофоны. ^)
Ну причём здесь это!? Суть темы совсем в другом. Напомню... В DOS могли бы иметься служебные ячейки, куда записывается о текущем состоянии процесса. И будь-то TSR-программа или самопалный девайс мог бы непосредственно отображать это состояние хоть на экран, хоть в тапочки... Вот в Windows по вектору FS:[0] записывается адрес try {} catch конструкций, чтобы система не убивала программу сразу, а давала ей шанс исправиться. Однако во время отладки приходится самому резервировать ячейки и смотреть, где и как падает. Вот нету там всяких FS:[4] и т.д. векторов, куда можно тупо записать адрес строки с названием действия, чтобы отладчик не просто отображал место ошибки, а ещё и некоторые сведения. А то вот приходится порою пошагово тестить и ещё придумывать всякие ухищрения, чтобы пропустить тысячу итерраций. И даже визуальные механизмы студий не позволяют достичь должного удобства. (Если вы более-менее опытный программист, вспомните пару другую случаев, когда матюкались на средства отладки от MS до Olly Debugger). Подчёркиваю: Нету ни устных, ни письменных соглашений о стандартизаций языка или карты служебных ячеек в щекотливых ситуаций.
Paguo_86PK Не понял. Помимо места ошибки отладчик показывает всё что надо: регистры, call stack, содержимое памяти.
Aspire Ну вот, всю малину обломал.. PS: Простите за оффтоп. Думаю никто не доживет до идеального компьютера. Лучше займите "место под солнцем".
А что тут понимать? Откат стэка и т.д... Во всей литературе описаны приёмы и т.д. Помните, как Эдисон изобретал лампочку? "Я нашёл тысячу неправильных способов. Осталось найти один верный"... На мой взгляд, разработчики систем не больно утруждали себя отладочными изысками и рядовому программисту приходится принимать имеющияся способы как должное. Вот вы и представить не можете иного способа отладки. Но это же не значит, что его не может быть! Просто кругом зациклились и используют один из тысяч неверных способов. Помните афоризм "Всё что ни делается, всё к лучшему. Но делается это наихудшим из способов". Вот и мы в отладки используем один из тысяч худших способов, но из всех выбрали самый лучший и удобный. Но лучший среди худших не означает же что он будет и лучшим среди хороших. Просто хороших не ишут!