Насчёт устарелости и недостаточной конкурентоспособности правильно лишь отчасти. Да, для смартфонов или топовых ПК процы, производимые на имеющихся у нас мощностях (и даже на оборудовании, появление которого в ближайшие несколько лет фантастикой не является), будут совершенно никакими, если их сравнивать с западными или китайскими. Однако реальный рынок намного шире. Скажем, на некоторых моих разработках стоят микроконтроллеры с ядрами ARM, выполненные по "дубовым" технологиям (от 65 нм и хуже); понятно, что такое мы производить в состоянии -- и оно реально востребовано. Зачем МК, управляющему, скажем, силовыми приводами, сверхтонкие технологические нормы и сверхнизкое потребление? Использование отечественных МК в таких задачах сильно ограничено как раз их заоблачной ценой по сравнению с буржуйско-китайскими, а отнюдь не техническими характеристиками (ну, ещё практической доставабельностью, если ты не из оборонки, но тут государство тоже вполне может сыграть положительную роль).
По моему опыту, самый лучший СМовский терминал был, особенно в плане клавиатуры.
Ну и поправка к "общим словам" статьи: в СМ ЭВМ входили не только аналоги PDP-11, но и аналоги HP21xx, которые автор упоминает только в рамках АСВТ: СМ-1 и СМ-2 -- это как раз HP21xx, а не PDP-11.
Существовавшие тогда ЭВМ (прежде всего ENIAC) работали в диалоговом режиме: заранее сформированные входные данные передавались в компьютер, который обрабатывал их и выдавал готоввый результат.
Такой режим -- не диалоговый, а пакетный. В диалоговом режиме машина как раз ждёт реакции человека, отвечает на неё, опять ждёт и т.д., а не обрабатывает заранее подготовленные данные. Авиатренажёр, по сути, -- это как раз диалоговый режим, просто ввод человека осуществляется не через клавиатуру/мышь/сенсорный экран и т.п., а через органы управления самолётом или их имитацию (джойстик, например).
Угу. Поэтому предлагать подобное решение можно лишь в случае, если оговорена необязательная переносимость и прочие возможные ограничения или их отсутствие. У меня, исходя из начала этой статьи, сложилось впечатление, что неявно сформулированная задача заключалась в вводе строк исключительно стандартными средствами библиотеки языка.
Но такое решение уже будет непереносимым, так как полагается на наличие у ОС такой возможности. А её может и не быть -- скажем, если программе придётся работать на микроконтроллере, где виртуальной памяти в принципе не существует.
В дельфях не просто шустро -- иногда в сотни раз шустрей, чем на сях... Плюс там достаточно надёжная типизация (и отсутствие надёжности и си), и модули, а не дурные инклуды... Собсно, главный недостаток -- что пошли по пути копирования функционала жабы/сишарпа, а не с++ (убогие генерики вместо полноценных шаблонов, например).
Я вот под голое железо на С++ пишу. И постоянно его... ругаю тихими словами (но чистый Це ещё хуже: те же самые проблемы, только ещё и функционал убогий).
1) Физика сама по себе к реальному миру привязана, ибо ему и посвящена, а математика абстрактна. 2) С физикой начинают знакомиться ещё в школе, причём раньше, чем с "серьёзной" математикой. Поэтому, вводя в старших классах производные с интегралами, правильней было бы их применять на примере уже знакомой ученикам механики (например, решение задач, связанных с равноускоренным движением). 3) В вузах проблема менее острая, поскольку учатся уже взрослые люди, но даже и там не следует одно давать в полном отрыве от другого. Скажем, знакомишься с той же ТОЭ, решаешь уравнения сначала "по-школьному", а потом знакомишься со "взрослыми" способами, в т.ч. как системы уравнений решаются на ЭВМ. Или начинаешь изучать обработку сигналов, знакомишься с тем, что это вообще такое и для чего нужно -- и сразу вот тебе математический аппарат, который для этого применяется (а не сначала математику, которая хз для чего нужна, и лишь потом...)
С моей точки зрения, что в школе, что в технических вузах математику нужно давать не "сферическую в вакууме", а в рамках физики и других дисциплин, где она реально применяется -- чтобы сразу было видно, для чего это нужно, и чтобы сразу применять изученные математические вещи для реальных задач.
Ну дык это не только вузовская беда. Многие ли старшеклассники понимают, какого хрена они должны учить всякие логарифмы и прочие производные с интегралами и для чего оно вообще может быть использовано? (не говоря о том, что 90% школьников это действительно не нужно)
Кстати, о Протеусе. Он по-прежнему не способен корректно моделировать логические элементы, если один из входов в неопределённом состоянии, но выход можно определить из второго входа? (скажем, двухвходовый элемент И: если на одном входе 0, то на выходе будет 0, но раньше Протеус давал на выходе неопределённое значение, если второй вход был в неопределённом -- из-за чего, в частности, в нём невозможно было сделать обычный RS-триггер, чтоб он работал всегда, как работает в реальных схемах). Я-то сам им не пользуюсь, если и моделирую, то на HDL, а не на схемном уровне
Да толком, похоже, нигде не описывается. Есть литература по "верхнему уровню", так сказать -- из каких больших кусков всё это может состоять и как оно взаимодействует и т.д. и т.п.; есть литература "нижнего уровня" -- логические элементы и прочая, на чём всё это строится. А вот в середине -- как взять кучку логических элементов и сделать из них компутер -- вряд ли что найдётся. Лично я изучал по реальным схемам реальных машин и по книгам, реальным же машинам посвящённым. Сейчас вот, пользуясь тем, что в тырнетах есть схема проца от СМ-1420 (с которого я, собственно, начинал изучение этого дела -- году эдак в 86-87), решил его себе слепить с небольшими оптимизациями, но сохраняя общую логику работы. Но в нём ~650 микросхем малой и средней степени интеграции; разобраться с устройством вполне реально, но потребует определённых усилий, конечно (плюс, поскольку он реализует систему команд PDP-11, надо с ней тоже знакомым быть).
А это надо, во-первых, уже считать задержки и всё такое прочее, а во-вторых, возможно, делать полноценную печатную плату, причём, возможно, многослойную (если выяснится, что где-то уже обязательно выдерживать импедансы).
Но краткий ответ: нет :) Недаром частоты наших ЕСок были много-много ниже. У ЕС-1130, последней действительно серийной машины, время такта было 160 нс. У самых скоростных -- что-то вроде 80 нс, т.е., грубо говоря, 12 МГц. "У них", т.е. у IBM на примерно таком же технологическом уровне (их конец 1970-начало 1980-х) -- примерно то же самое или чуть быстрее.
Компиляторы такое генерят постоянно при выключенной оптимизации, да и при включённой иногда бывает :) Понятно, что в Вашем случае портирование какого-нить там гцц не грозит, но если брать в общем и целом...
APL -- язык программирования будущего для программистской техники прошлого. Открывает новую эру для любителей кодирования (с) не помню кто
Насчёт устарелости и недостаточной конкурентоспособности правильно лишь отчасти. Да, для смартфонов или топовых ПК процы, производимые на имеющихся у нас мощностях (и даже на оборудовании, появление которого в ближайшие несколько лет фантастикой не является), будут совершенно никакими, если их сравнивать с западными или китайскими. Однако реальный рынок намного шире. Скажем, на некоторых моих разработках стоят микроконтроллеры с ядрами ARM, выполненные по "дубовым" технологиям (от 65 нм и хуже); понятно, что такое мы производить в состоянии -- и оно реально востребовано. Зачем МК, управляющему, скажем, силовыми приводами, сверхтонкие технологические нормы и сверхнизкое потребление? Использование отечественных МК в таких задачах сильно ограничено как раз их заоблачной ценой по сравнению с буржуйско-китайскими, а отнюдь не техническими характеристиками (ну, ещё практической доставабельностью, если ты не из оборонки, но тут государство тоже вполне может сыграть положительную роль).
Маньяк этот Ivan -- прям как я (и, кстати, тоже Иван) :) Вполне может быть, стащу в будущем его решение для себя.
По моему опыту, самый лучший СМовский терминал был, особенно в плане клавиатуры.
Ну и поправка к "общим словам" статьи: в СМ ЭВМ входили не только аналоги PDP-11, но и аналоги HP21xx, которые автор упоминает только в рамках АСВТ: СМ-1 и СМ-2 -- это как раз HP21xx, а не PDP-11.
Мы играли. На 80386DX-33 окно уменьшать не приходилось, на SX-25 (или даже 20, не помню) -- там да, приходилось.
Первый DOOM благополучно работал на 80386.
Существовавшие тогда ЭВМ (прежде всего ENIAC) работали в диалоговом режиме: заранее сформированные входные данные передавались в компьютер, который обрабатывал их и выдавал готоввый результат.Такой режим -- не диалоговый, а пакетный. В диалоговом режиме машина как раз ждёт реакции человека, отвечает на неё, опять ждёт и т.д., а не обрабатывает заранее подготовленные данные. Авиатренажёр, по сути, -- это как раз диалоговый режим, просто ввод человека осуществляется не через клавиатуру/мышь/сенсорный экран и т.п., а через органы управления самолётом или их имитацию (джойстик, например).
Ну и очепятка в слое "готоввый" :)
Угу. Поэтому предлагать подобное решение можно лишь в случае, если оговорена необязательная переносимость и прочие возможные ограничения или их отсутствие. У меня, исходя из начала этой статьи, сложилось впечатление, что неявно сформулированная задача заключалась в вводе строк исключительно стандартными средствами библиотеки языка.
Но такое решение уже будет непереносимым, так как полагается на наличие у ОС такой возможности. А её может и не быть -- скажем, если программе придётся работать на микроконтроллере, где виртуальной памяти в принципе не существует.
В дельфях не просто шустро -- иногда в сотни раз шустрей, чем на сях... Плюс там достаточно надёжная типизация (и отсутствие надёжности и си), и модули, а не дурные инклуды... Собсно, главный недостаток -- что пошли по пути копирования функционала жабы/сишарпа, а не с++ (убогие генерики вместо полноценных шаблонов, например).
Я вот под голое железо на С++ пишу. И постоянно его... ругаю тихими словами (но чистый Це ещё хуже: те же самые проблемы, только ещё и функционал убогий).
1) Физика сама по себе к реальному миру привязана, ибо ему и посвящена, а математика абстрактна. 2) С физикой начинают знакомиться ещё в школе, причём раньше, чем с "серьёзной" математикой. Поэтому, вводя в старших классах производные с интегралами, правильней было бы их применять на примере уже знакомой ученикам механики (например, решение задач, связанных с равноускоренным движением). 3) В вузах проблема менее острая, поскольку учатся уже взрослые люди, но даже и там не следует одно давать в полном отрыве от другого. Скажем, знакомишься с той же ТОЭ, решаешь уравнения сначала "по-школьному", а потом знакомишься со "взрослыми" способами, в т.ч. как системы уравнений решаются на ЭВМ. Или начинаешь изучать обработку сигналов, знакомишься с тем, что это вообще такое и для чего нужно -- и сразу вот тебе математический аппарат, который для этого применяется (а не сначала математику, которая хз для чего нужна, и лишь потом...)
С моей точки зрения, что в школе, что в технических вузах математику нужно давать не "сферическую в вакууме", а в рамках физики и других дисциплин, где она реально применяется -- чтобы сразу было видно, для чего это нужно, и чтобы сразу применять изученные математические вещи для реальных задач.
Ну дык это не только вузовская беда. Многие ли старшеклассники понимают, какого хрена они должны учить всякие логарифмы и прочие производные с интегралами и для чего оно вообще может быть использовано? (не говоря о том, что 90% школьников это действительно не нужно)
Кстати, о Протеусе. Он по-прежнему не способен корректно моделировать логические элементы, если один из входов в неопределённом состоянии, но выход можно определить из второго входа? (скажем, двухвходовый элемент И: если на одном входе 0, то на выходе будет 0, но раньше Протеус давал на выходе неопределённое значение, если второй вход был в неопределённом -- из-за чего, в частности, в нём невозможно было сделать обычный RS-триггер, чтоб он работал всегда, как работает в реальных схемах). Я-то сам им не пользуюсь, если и моделирую, то на HDL, а не на схемном уровне
Да толком, похоже, нигде не описывается. Есть литература по "верхнему уровню", так сказать -- из каких больших кусков всё это может состоять и как оно взаимодействует и т.д. и т.п.; есть литература "нижнего уровня" -- логические элементы и прочая, на чём всё это строится. А вот в середине -- как взять кучку логических элементов и сделать из них компутер -- вряд ли что найдётся. Лично я изучал по реальным схемам реальных машин и по книгам, реальным же машинам посвящённым. Сейчас вот, пользуясь тем, что в тырнетах есть схема проца от СМ-1420 (с которого я, собственно, начинал изучение этого дела -- году эдак в 86-87), решил его себе слепить с небольшими оптимизациями, но сохраняя общую логику работы. Но в нём ~650 микросхем малой и средней степени интеграции; разобраться с устройством вполне реально, но потребует определённых усилий, конечно (плюс, поскольку он реализует систему команд PDP-11, надо с ней тоже знакомым быть).
Не достигнете Вы такой частоты на 1533 серии, если речь не об отдельной микросхеме (скажем, триггере), а о достаточно сложной конструкции в целом.
А это надо, во-первых, уже считать задержки и всё такое прочее, а во-вторых, возможно, делать полноценную печатную плату, причём, возможно, многослойную (если выяснится, что где-то уже обязательно выдерживать импедансы).
Но краткий ответ: нет :) Недаром частоты наших ЕСок были много-много ниже. У ЕС-1130, последней действительно серийной машины, время такта было 160 нс. У самых скоростных -- что-то вроде 80 нс, т.е., грубо говоря, 12 МГц. "У них", т.е. у IBM на примерно таком же технологическом уровне (их конец 1970-начало 1980-х) -- примерно то же самое или чуть быстрее.
Предлагаю просто расстрелять всех :) Был бы человек -- а статья найдётся, как известно, так чего мелочиться?
Компиляторы такое генерят постоянно при выключенной оптимизации, да и при включённой иногда бывает :) Понятно, что в Вашем случае портирование какого-нить там гцц не грозит, но если брать в общем и целом...