Разработчики решили использовать особенности зрения и инерционность люминофора и передавать картинку двумя частями с делением на четную и нечетную.
Всю эту "инерционность" и "особенности зрения" я прекрасно наблюдал, когда на амиге включал 640x512 на телевизоре. Всё начинало дико моргать. Спасибо ненадо.
Так вот (это тот момент, которого вы не поняли в моем комментарии), все эти компьютеры не умеют менять четность и нечетность полукадров.
Это вы не поняли, а точнее не в теме. Ни оригинальный спектрум, ни тот же commodore 64 -- никакими подобными извращениями с "полукадрами" не занимались.
Амига могла опционально включать режим с этими "полукадрами" (и всё начинало отвратительно моргать, зато вертикальное разрешение увеличивалось).
ИЧСХ все-все телевизоры прекрасно жрали отсутствие полукадров. Кроме вашего новодельного китаевизора.
Вся эта пляска с дополнительными импульсами развёртки, разными полукадрами и т.д. задумана для одной цели -- чтобы схемы развёртки обычных древнеаналоговых телевизоров чертили лучом строчки одного полукадра между строчками предыдущего. И типа получалось как бы удвоение вертикального разрешения. Для домашних компьютеров таковое нужно не было, следовательно и "полукадры" у них были у (почти) всех -- одинаковые.
Если ваш современный телевизор ниасилил сожрать пал-сигнал без разных полукадров -- ну, значит там китаец намудрил с прошивкой, не понимая всех нюансов. Не показатель.
Все амиги с рождения могли выдавать как одинаковые полукадры (разрешение типа 320x256 или 640x256), так и разные (320x512 и 640x512). Очевидно что в играх скорее первое, а 2ое ну очень уж моргает, даже на статичных картинках, и использовалось редко.
Не знаю, застали ли вы эру тёплых ламповых svga-мониторов. Там тоже зачастую была опция чересстрочной развёртки и моргало всё точно так же противно.
ублюдочное решение, принятое в ущерб производительности.
Это было не "ублюдочное", а скорее всего единственно возможное решение для конкретных разработчиков. Далеко не все заводы и НИИ могли себе позволить заказать производство какой-нибудь новой микросхемы.
Но Зоновский вариант даёт кривую синхру и делает два одинаковых полукадра без деления на чётный/нечётный.
Вы думаете, оригинальный спектрум выдавал разные полукадры? Или, может, оригинальный commodore 64? Ничего подобного. Только Амига так умела, ну на то она и Амига.
Мусора много выкидываем. Много тратим ресурсов, в т.ч. и энергии. Вся индустрия в конечном итоге работает на то, чтобы вкусно покушать, приятно отдохнуть и ещё слетать в отпуск на самолётике. Чтобы удобно было ездить на тачке куда хочешь. Дома свет, отопление, удобное приготовление еды, умные домашние приборы, интернет. В магазинах продукты на любой вкус, инструменты, телефоны, стройматериалы, всё что угодно.
Но это всё ужас как мусорит и загрязняет природу. Потому чтоб быть по-настоящему зелёными, надо жить по-средневековому, ну и численность населения сократить на порядок, а то и два. Ведь так, именно это является конечной целью всяких зеленушных, борящихся то с пластиком, то с АЭС, то с ДВС, то с чем там ещё? Или что, какова их конечная цель?
Ваши высказывания как-то очень специально надо понимать, не так как они написаны. То у вас момент в мощность принципиально не пересчитывается, то скорость не растёт с ростом оборотов, хотя имеется в виду что и то и другое пропорционально растёт.
Не понятно к чему эти гипотетические раауждения о решениях про которых нет полной информации.
Это не гипотетические, а вполне практические рассуждения. Вот прямо то чем я занимаюсь. Гипотетические, и уж точно без вообще какой-либо информации по существу -- у вас.
Вам SIISII несколько раз объяснил что контроль сбоев аппаратуры МФ имелся с самых первых моделей, уверен, что и на компьютерах до МФ это тоже уже имелось. Имелись также и средства востановления от сбоев.
Перефразируя: "talk is cheap. show me your schematics" :)
Если не возможно восстановить выполнение пользовательской или системной задачи, то они завершаются аварийно с последущей обработкой возможности восстановления на уровне прикладной программы или системной.
Уже лучше. Не "всё супер надёжно, никаких сбоев, если что другой процессор впряжётся и продолжит с того же места", а оказывается и упасть может.
Я же в свою очередь продолжаю настаивать, что тотальный контроль сбоев (даже одиночных) невозможнен без +- дублирования всей логики. А это площадь кристалла, потребление.
Кстати, о том как именно программно реализованы откаты (что и когда снапшотится и т.д.) тоже рассказа по существу не было. Вы как специалист по ibm mainframe'ам, уверен, можете об этом замечательно и очень интересно рассказать.
С другой стороны что такое "рандомная логика" сегодня. Это твердотельная микросхема.
В которой 100 миллиардов транзисторов например.
Потом делают карты с многими микросхемами
Вы сейчас точно не про ЕС-1033?
И лишь после этого отгружают.
А потом прилетает ТЗЧ, которой похрену на все тестирования, и флипает состояние одного триггера.
А вот возьму как пример что-то сложнее, чем буфер но проще чем кеш: FIFO. Вот у нас данные, но они защищены чётностью например и мы их не трогаем. Вот сигналы наружу -- входы стробов чтения и записи, выходы сигналов 'full' и 'empty'. Если один из них сломается -- то в FIFO либо запишется чушь, либо прочитается чушь, либо не запишется что надо, либо не прочтётся что надо, либо (и т.д.). Нам их надо защитить, например дублированием (лучше когда сигнал и его инверсная копия). Ещё из блока управления FIFO торчат адреса в блок памяти, адрес чтения и записи. Их тоже хорошо бы защитить, минимум дублированием. Теперь есть собственно управляющая логика: она смотрит на те 4 сигнала выше и генерит адреса для блока памяти. Если эта логика сломается, будет опять см. выше что. Получается, нам ВЕСЬ блок управления памятью при FIFO надо продублировать. Далее ещё можно разобрать, как сделать чтобы в память не писали куда попало (вдруг провода от блока управления до памяти сломаются или в самой памяти дешифратор ряда) и чтоб не читало откуда попало. Тут тоже без некоторого увеличения логики и/или объёма памяти не обойтись.
И так можно рассказать почти обо всём. Откуда и моё утверждение про увеличение количества логики.
Ваши "управляющие сигналы" точно так же будут идти отдельными проводами на "проверку чётности" и другими -- собственно куда надо. И эти другие провода тоже могут сломаться, как и логика за ними. Получается, проверка чётности как у вас не обеспечивает полного контроля.
Если честно, я не знаю лучшего метода для рандомной логики, чем дублирование со сверкой -- если мы стремимся к 100% покрытию на детект одиночного сбоя.
Смотря в каких парах трения. В подшипниках коленвала в ДВС -- да, но актуальным отвод тепла становится на оборотах, близких к максимальным. На ХХ ДВС может без поддона работать длительное время. В трении поршня по цилиндру -- нет, там даже и гидродинамического режима не случается, полусухое трение всегда.
То-то же в ДВС ставят маслосъёмные кольца. Специально лишнее масло убирают, чтоб быстрее сломалось!
По факту, удельные нагрузки в узле поршень-цилиндр достаточно малы для того, чтобы хватало масла, не утёкшего за час, а может быть и за день. Масло липнет к металлу, просто так из узких мест не вытекает. Так что старт-стоп раз в 5 минут на смазанность поршня и его колец, елозящих по цилиндру, влияет примерно никак.
Для обнаружения в передаваемых данных - действительно. Но вот сама управляющая логика по сути кроме как дублированием (или dual rail) никак не защищается.
При обнаружении сбоя происходит прерывание от схем контроля
Обнаружить сбой действительно можно именно так. Но вот у нас есть суперскалярный процессор, в нём могут одновременно выполняться сотни команд. Обнаружен сбой. Если нет информации, где именно -- то довольно нетривиально провернуть весь этот фарш назад для того, чтобы понять, например, сбой произошёл ДО того, как сделали снапшот памяти/процесса/его IO или после. Если сбой примерно совпал по времени с деланием этого снапшота, например.
Наверное можно например сбои управляющей логики разделять на сегменты -- типа вот тут логика коммита команд, а вон там логика шедулера, если сбойнуло там то мы можем ещё дождаться коммита всех операций, иначе засада и т.д. Но собственно тут и происходит радикальное усложение дизайна, когда поверх и так нетривиальной архитектуры суперскалярного ядра ещё натягивается система восстановления (частичного) после сбоя. Ну и в общем это то, что было бы интересно узнать из первых рук, а не только размахивания руками "у нас всё надёжно мамой клянусь, можно шокером в плату и всё продолжит работaть"
Уже лет 15 как в OO/LO конверчу его родные файлы в pdf. А полную совместимость с проприетарными вендорлочными форматами ("просто конвертнуть word файл") вам никто не обещал либо вы её не оплатили.
Я же сюда пришёл не мифотворчеством заниматься а выражать здоровый скептицизм. Тем более что апологетам ибм moneyфреймов, как оказывается, мне ответить нечего, кроме "не убедительно" :)
В чипе CPU есть цепи контроля и используются избыточные коды. Это электроника.
Вот про неё я и спрашиваю. Зачем вы потом ещё 10 абзацев про "конторы саппорта" пишете?
Чтоб просто иметь возможность определить одиночный (не многократный) сбой, все сигналы управления (те, что не шины данных) и логику управления необходимо каким-либо образом дублировать с постоянным сравнением. Если хочется ещё и игнорировать сбой -- троировать с мажорированием. Возможность определения одиночного сбоя не даёт гарантии что заодно и точно узнаем место и момент сбоя и сможем определить, на что он повлиял. Чтоб и это тоже было -- кол-во логики ещё увеличивается. И т.д.
В результате получаем что эти ваши moneyфреймы оказываются неэффективными по площади и по потреблению, т.к. кол-во логики на те же вычисления больше. Но видимо либо богатые конторы имеют возможность платить и х2 прайс за электричество, или на самом деле "жырность" мейнфреймов преувеличена и любой традиционный датацентр средней величины запросто обойдёт по потреблению и производительности любой мейнфрейм.
в 8080 LE не даёт никакого преимущества (но и недостатков тоже). Вот в 6502 даёт преимущество а в 6800 BE даёт недостаток.
Ы? Однотактовый же. Какой-нибудь
lda absбудет 4 такта, 1 на опкод, два на вычитку адреса, один на чтение по тому адресу.Чтобы на него переписать примерно 10% файрфокса. Остальное там до сих пор на C++ :)
Всю эту "инерционность" и "особенности зрения" я прекрасно наблюдал, когда на амиге включал 640x512 на телевизоре. Всё начинало дико моргать. Спасибо ненадо.
Это вы не поняли, а точнее не в теме. Ни оригинальный спектрум, ни тот же commodore 64 -- никакими подобными извращениями с "полукадрами" не занимались.
Амига могла опционально включать режим с этими "полукадрами" (и всё начинало отвратительно моргать, зато вертикальное разрешение увеличивалось).
ИЧСХ все-все телевизоры прекрасно жрали отсутствие полукадров. Кроме вашего новодельного китаевизора.
Вся эта пляска с дополнительными импульсами развёртки, разными полукадрами и т.д. задумана для одной цели -- чтобы схемы развёртки обычных древнеаналоговых телевизоров чертили лучом строчки одного полукадра между строчками предыдущего. И типа получалось как бы удвоение вертикального разрешения. Для домашних компьютеров таковое нужно не было, следовательно и "полукадры" у них были у (почти) всех -- одинаковые.
Если ваш современный телевизор ниасилил сожрать пал-сигнал без разных полукадров -- ну, значит там китаец намудрил с прошивкой, не понимая всех нюансов. Не показатель.
Все амиги с рождения могли выдавать как одинаковые полукадры (разрешение типа 320x256 или 640x256), так и разные (320x512 и 640x512). Очевидно что в играх скорее первое, а 2ое ну очень уж моргает, даже на статичных картинках, и использовалось редко.
Не знаю, застали ли вы эру тёплых ламповых svga-мониторов. Там тоже зачастую была опция чересстрочной развёртки и моргало всё точно так же противно.
Это было не "ублюдочное", а скорее всего единственно возможное решение для конкретных разработчиков. Далеко не все заводы и НИИ могли себе позволить заказать производство какой-нибудь новой микросхемы.
Вы думаете, оригинальный спектрум выдавал разные полукадры? Или, может, оригинальный commodore 64? Ничего подобного. Только Амига так умела, ну на то она и Амига.
Мусора много выкидываем. Много тратим ресурсов, в т.ч. и энергии. Вся индустрия в конечном итоге работает на то, чтобы вкусно покушать, приятно отдохнуть и ещё слетать в отпуск на самолётике. Чтобы удобно было ездить на тачке куда хочешь. Дома свет, отопление, удобное приготовление еды, умные домашние приборы, интернет. В магазинах продукты на любой вкус, инструменты, телефоны, стройматериалы, всё что угодно.
Но это всё ужас как мусорит и загрязняет природу. Потому чтоб быть по-настоящему зелёными, надо жить по-средневековому, ну и численность населения сократить на порядок, а то и два. Ведь так, именно это является конечной целью всяких зеленушных, борящихся то с пластиком, то с АЭС, то с ДВС, то с чем там ещё? Или что, какова их конечная цель?
Ваши высказывания как-то очень специально надо понимать, не так как они написаны. То у вас момент в мощность принципиально не пересчитывается, то скорость не растёт с ростом оборотов, хотя имеется в виду что и то и другое пропорционально растёт.
У вас сцепление проскальзывает.
Это не гипотетические, а вполне практические рассуждения. Вот прямо то чем я занимаюсь. Гипотетические, и уж точно без вообще какой-либо информации по существу -- у вас.
Перефразируя: "talk is cheap. show me your schematics" :)
Уже лучше. Не "всё супер надёжно, никаких сбоев, если что другой процессор впряжётся и продолжит с того же места", а оказывается и упасть может.
Я же в свою очередь продолжаю настаивать, что тотальный контроль сбоев (даже одиночных) невозможнен без +- дублирования всей логики. А это площадь кристалла, потребление.
Кстати, о том как именно программно реализованы откаты (что и когда снапшотится и т.д.) тоже рассказа по существу не было. Вы как специалист по ibm mainframe'ам, уверен, можете об этом замечательно и очень интересно рассказать.
В которой 100 миллиардов транзисторов например.
Вы сейчас точно не про ЕС-1033?
А потом прилетает ТЗЧ, которой похрену на все тестирования, и флипает состояние одного триггера.
А вот возьму как пример что-то сложнее, чем буфер но проще чем кеш: FIFO. Вот у нас данные, но они защищены чётностью например и мы их не трогаем. Вот сигналы наружу -- входы стробов чтения и записи, выходы сигналов 'full' и 'empty'. Если один из них сломается -- то в FIFO либо запишется чушь, либо прочитается чушь, либо не запишется что надо, либо не прочтётся что надо, либо (и т.д.). Нам их надо защитить, например дублированием (лучше когда сигнал и его инверсная копия). Ещё из блока управления FIFO торчат адреса в блок памяти, адрес чтения и записи. Их тоже хорошо бы защитить, минимум дублированием. Теперь есть собственно управляющая логика: она смотрит на те 4 сигнала выше и генерит адреса для блока памяти. Если эта логика сломается, будет опять см. выше что. Получается, нам ВЕСЬ блок управления памятью при FIFO надо продублировать. Далее ещё можно разобрать, как сделать чтобы в память не писали куда попало (вдруг провода от блока управления до памяти сломаются или в самой памяти дешифратор ряда) и чтоб не читало откуда попало. Тут тоже без некоторого увеличения логики и/или объёма памяти не обойтись.
И так можно рассказать почти обо всём. Откуда и моё утверждение про увеличение количества логики.
Ваши "управляющие сигналы" точно так же будут идти отдельными проводами на "проверку чётности" и другими -- собственно куда надо. И эти другие провода тоже могут сломаться, как и логика за ними. Получается, проверка чётности как у вас не обеспечивает полного контроля.
Если честно, я не знаю лучшего метода для рандомной логики, чем дублирование со сверкой -- если мы стремимся к 100% покрытию на детект одиночного сбоя.
Смотря в каких парах трения. В подшипниках коленвала в ДВС -- да, но актуальным отвод тепла становится на оборотах, близких к максимальным. На ХХ ДВС может без поддона работать длительное время. В трении поршня по цилиндру -- нет, там даже и гидродинамического режима не случается, полусухое трение всегда.
То-то же в ДВС ставят маслосъёмные кольца. Специально лишнее масло убирают, чтоб быстрее сломалось!
По факту, удельные нагрузки в узле поршень-цилиндр достаточно малы для того, чтобы хватало масла, не утёкшего за час, а может быть и за день. Масло липнет к металлу, просто так из узких мест не вытекает. Так что старт-стоп раз в 5 минут на смазанность поршня и его колец, елозящих по цилиндру, влияет примерно никак.
Для обнаружения в передаваемых данных - действительно. Но вот сама управляющая логика по сути кроме как дублированием (или dual rail) никак не защищается.
Обнаружить сбой действительно можно именно так. Но вот у нас есть суперскалярный процессор, в нём могут одновременно выполняться сотни команд. Обнаружен сбой. Если нет информации, где именно -- то довольно нетривиально провернуть весь этот фарш назад для того, чтобы понять, например, сбой произошёл ДО того, как сделали снапшот памяти/процесса/его IO или после. Если сбой примерно совпал по времени с деланием этого снапшота, например.
Наверное можно например сбои управляющей логики разделять на сегменты -- типа вот тут логика коммита команд, а вон там логика шедулера, если сбойнуло там то мы можем ещё дождаться коммита всех операций, иначе засада и т.д. Но собственно тут и происходит радикальное усложение дизайна, когда поверх и так нетривиальной архитектуры суперскалярного ядра ещё натягивается система восстановления (частичного) после сбоя. Ну и в общем это то, что было бы интересно узнать из первых рук, а не только размахивания руками "у нас всё надёжно мамой клянусь, можно шокером в плату и всё продолжит работaть"
Естественно. Миф сам себя не поддержит, надо несогласных шпынять.
Уже лет 15 как в OO/LO конверчу его родные файлы в pdf. А полную совместимость с проприетарными вендорлочными форматами ("просто конвертнуть word файл") вам никто не обещал либо вы её не оплатили.
Я же сюда пришёл не мифотворчеством заниматься а выражать здоровый скептицизм. Тем более что апологетам ибм moneyфреймов, как оказывается, мне ответить нечего, кроме "не убедительно" :)
Вот про неё я и спрашиваю. Зачем вы потом ещё 10 абзацев про "конторы саппорта" пишете?
Чтоб просто иметь возможность определить одиночный (не многократный) сбой, все сигналы управления (те, что не шины данных) и логику управления необходимо каким-либо образом дублировать с постоянным сравнением. Если хочется ещё и игнорировать сбой -- троировать с мажорированием. Возможность определения одиночного сбоя не даёт гарантии что заодно и точно узнаем место и момент сбоя и сможем определить, на что он повлиял. Чтоб и это тоже было -- кол-во логики ещё увеличивается. И т.д.
В результате получаем что эти ваши moneyфреймы оказываются неэффективными по площади и по потреблению, т.к. кол-во логики на те же вычисления больше. Но видимо либо богатые конторы имеют возможность платить и х2 прайс за электричество, или на самом деле "жырность" мейнфреймов преувеличена и любой традиционный датацентр средней величины запросто обойдёт по потреблению и производительности любой мейнфрейм.
С какого перепоя дважды-то? В slog идут только синхронные записи.