Здравствуйте, dmz, Вы писали:
DK>>Надо юзать OpenGL и усё будет просто DK>>См. glfw: http://glfw.sourceforge.net dmz>Где был ваш OpenGL в 1994 году?
Там же, где DirectX с его предшественником, даже ближе
DK>>А с этими 0x13 люди такой бурды понаписали. Мало кто додумывался сделать антифлик и WaitForBlank. dmz>Все кто делал — игрушки — додумывались, не беспокойтесь.
Не все...
dmz>Я не знаю, что вы именно имеете ввиду под dmz>WaitForBlank,
Отсутствие рваности изображения и фликер, если плохая буферизация.
dmz>но что бы подождать обратного хода надо было повесить обработчик на прерывание.
Я в курсе.
dmz>То есть одним вызовом функции было не отделаться, это совершенно точно.
Ну оно то и понятно. Но, нам, зелени, не понять дедов, молившихся на прерывания...
dmz>А насчет бурды — вы напишите игрушку, равную по playability StarControl II. Потом говорите за бурду.
Вот, начинаем уже меряться длиной...
dmz>Ну да, там не 0x13, там был x-mode, но разница небольшая.
Понаделали, понимаешь, этих ХЭ-модей, ни с чем не совместимых...
Вспомнить только тогдашних разработчиков.
Запускаешь сейчас игру конца 80х — начала 90х, и игра, тебя за дурака считает, спрашивает, на каком порту у тебя аудиокарточка сидит, сколько памяти на ней, спрашивает прерывания видюшки, марку чипсета...
Ну, блин, долболомы же были...
Ну неужели нельзя у карточки у самой спросить, на каком она прерывании сидит и какие фичи поддерживает?
dmz>А совершенно гениальная по графике Another World — 640x480x16, но как это выглядело...
Да...
И сахар, говорите, слаще был, и водка крепчее...
Здравствуйте, McSeem2, Вы писали:
MS>Воот. О том и речь. Создай миллион файлов размером 1 байт.
А зачем? Для хранения миллиона записей размером 1 байт надо использовать БД, а не отдельные файлы.
MS> Сколько места понадобится? Но у нас, как правило, нет потребности в миллионе файлов по 1 байту, а вот потребность в миллионе объектов в памяти — есть. И чтобы каждый объект имел возможность расширяться без реаллокаций.
И тем не менее уже сейчас проблема мелких объектов решена. Точно так же как решена она в современных SQL серверах.
MS>Я до сих пор не могу толком сформулировать одну свою мысль, хотя суть ее кажется простой. Для примера — в текстовом режиме нафиг не уперся графический курсор.
Это ты зря, это ты забыл что такое текстовый курсор. Дискретность его такова, что дерганье просто убивает и легко при быстром перемещении его потерять.
AVK>>Но заниматься этим на современных компах, когда функциональная сложность фофанного януса выше чем сложности многих тогдашних больших коммерческих систем? Выглядит как неумная забава.
MS>Согласен. Но кто все это обеспечивает?
Целая масса технологий — удобная IDE, большая поддержка со стороны рантайма, мощная стандартная библиотека, и много много других вещей. То, что некоторые считают извратом и искусственным усложнением программы.
MS>О как! Прямо-таки апокалипсис! Но кто-то же должен программировать те самые контроллеры и изобретать GC и JIT?! Или оно само?
Должен. Но потребность программистов в подобных вещах кардинально меньше, нежели прикладников. Да и железяки становятся все интеллектуальнее, что точно так же уменьшает объем тупого кодирования и необходимость знания архитектуры конкретного чипа. Если раньше для эффективного использования графического процессора надо было писать под каждый свой код с учетом специфики, то теперь зависимость стала намного меньше и конкретные порты видеочипа волнуют только программеров производителя этого самого чипа.
MS> Теоретически, я не исключаю и такого варианта, что само... MS>Навеяло диалог из Пелевина, Поколение "П"
Не люблю Пелевина.
MS>>>Именно он и является ключевым. Можно и на C++ сделать модель, гарантирующую освобождение ненужной памяти,
AVK>>Нельзя. Не существует способа запретить на С++ прямую работу с указателями.
MS>Об том и речь! Прямая работа с указателями по большому счету не мешает автоматическому удалению.
Я специально употребляю слово "гарантированное".
MS> А вот чему она точно мешает — так это сохранению целостности данных при перемещении объектов в памяти.
Здравствуйте, DJ KARIES, Вы писали:
DK>А с этими 0x13 люди такой бурды понаписали. Мало кто додумывался сделать антифлик и WaitForBlank. DK>Да и 320x200x8BPPx60Hz, мягко говоря, сейчас отстой.
Но как иногда приятно созерцать красивую картинку в разрешении 320x240x8...
Ностальгия...
Хотя у меня общение с PC-компом (AMD_K6-2 450Mhz, 32Mb) началось летом 2000-го...
И прогал я первые недели на бейсиковском скрипте Corel7.
Безо всяких инетов и книжек.
Здравствуйте, McSeem2, Вы писали:
MS>Наверное, ты прав. Ассемблер хорош лишь тем, что позволяет заглянуть под капот и наглядно увидеть, как двигаются поршни и клапаны, когда чего вспыхивает и толкает...
Вопрос в том насколько нужно заглядывать.
MS> Не уверен, что это так уж нужно современному водителю "моторова возидла"... Но еще раз повторю свою мысль — кто-то же должен придумывать новые клапана! Или оно само?
А те кто придумывают их и так прекрасно знают что им нужно изучать без наших с тобой советов. И они это делают, причем целенаправленно, а не для общего интереса.
MS>>Согласен. Но кто все это обеспечивает?
AVK>Целая масса технологий — удобная IDE, большая поддержка со стороны рантайма, мощная стандартная библиотека, и много много других вещей. То, что некоторые считают извратом и искусственным усложнением программы.
Слова "кто" и "что" в русском языке похожи, но все-таки несут разный смысл. Хоть ты и не любишь Пелевина, но ответил точно в его стиле. Дзен!
Андрей, думаю, что я понял твою точку зрения и это мне тоже в чем-то помогло.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, AndrewVK, Вы писали:
AVK>А те кто придумывают их и так прекрасно знают что им нужно изучать без наших с тобой советов. И они это делают, причем целенаправленно, а не для общего интереса.
И я тоже делаю "не для общего интереса". Но кто из нового поколения будет придумывать новые JIT'ы, если не будет курсов по ассемблеру и C++? Как такие специалисты будут возникать? Сами собой, как плесень? В общем-то возможно...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Неплохая мысль! Особенно в свете модной науки о квантовых компьютерах и кубитах (надо ввести новый термин, из Кин-Дза-Дзы, КюБайт).
Представляю: сидит программист, колбасит какрй-нибудь javascript, и мысленно представляет, как его программа вызывает срабатывание p-n переходов на своем компьютере, как движутся электроны в соответствии с их корпускулярно-волновой двойственностью... А программа что-то не работает. Программер открывает справочник по физике, читает его, чиатет... И тут на него находит прозрение: "А-а-а-а-а! Тупица! Я же не учел соотношение неопределенностей Гейзенберга!" Быстро исправляет ошибку в программе (забыл переменную проинициализировать) и в мыслях благодарит своего преподавателя по физике...
P.S.: это у меня просто настроение веселое, а так я согласен, что каждый программист обязан хотя бы примерно знать устройство компьютера, а также не задумываясь отвечать, на вопрос "Кто такой Фон Нейман?"
Здравствуйте, LaptevVV, Вы писали:
LVV>В общем я на этой дипломной работе еще и макробемш освоил — он на меня произвел неизгладимое впечатление... Вообще, мне видимо, здорово повезло, что я начинал писать программы на уровне команд машины — это здорово способствовало формированию алгоритмического мышления... Ведь любую формулу приходилось раскладывать по полочкам. и команды писать в нужном порядке, ибо компьютер о приоритетах операций ничего не знает... И это сразу как-то вправляло мозги в нужную сторону. Вот теперь думаю — а не начать ли мне ту же методику применять к студентам?
Хорошо бы. PDP-11/70 -- идеальная машина дла тренировки настоящих хакеров. Но начинать следует с элементарного введения в схемотехнику.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, AndrewVK, Вы писали:
AVK>>ИМХО не стоит. Все эти знания о ассемблерах PDP-11, Z-80, 8080, x86, системах команд VLIW и прочая на практике почти невостребованны. Птица (ПТЦА) пожалуй даже полезнее будет.
MS>Тут дело не только в ассемблере. На мой консервативный взгляд, обязательно надо посвящять прежде всего в фундаментальные понятия, как то — дополнительный код, адресация, плавающая точка, последовательность операций. Конкретный ассемблер здесь ни при чем — можно взять, к примеру MSIL или любой другой псевдокод.
Да, все это у нас есть в курсе Организация ЭВМ и систем. Но по учебному плану — на втором курсе — после языков высокого уровня... Вот я и думаю — а не переставить ли мне порядок дисциплин...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Программированию на других языках нас учили прямо скажем, в основном теоретически... Хотя мы изучали Фортран — тогда еще фортран 4, PL-1 — была тогда замечательная книга Лепина-Дмитрюкова. А еще Олюнин-Фролов. Даже Кобол, помнится, сдавали... Он мне потом сильно пригодился...
Алгол у нас тоже был. Но самое неизгладимое впечатление на меня произвел Алгол-68. Естественно, в 74-м году в Узбекистане трансляторов не было Только что в издательстве Мир вышла книжка "Неформальное введение в Алгол-68". Наш препод — зав кафедрой — по специальности механик-упругист — вел семинары. Кадому дали тему и нужно было сделать доклад — написав свои примеры... Помнится, я сначала нифига не понял... Но в какой-то момент вдруг опять пришло озарение — я вдруг сразу увидел необыкновенную красоту и стройность этого языка... С этого момента я мог объяснить (и написать!) любую программу на Алголе-68 прям сразу — не нужно было заглядывать в книжку. Особое впечатление произвело то, что можно было в программе определять совсем НОВЫЕ операции, задавая даже новое сочетание символов. Именно это свойство потребовало от ВанВейнГардена изобрести двухуровневые грамматики — надо же было еще и строгую типизацию соблюсти. И еще очень стройная система ввода-вывода — прообраз потоков. В общем, на уровне монстра PL/1 это выглядело потрясающе!!!!
PL/1 — это как тогда модно было говорит — язык-оболочка, вобравший в себя все, что можно было собрать из Фортрана, Кобола и алгола. Да еще и оператор ON был очень интересен — прообраз исключений, который позволял писать событийно управляемые программы. А система типов — это кошмар!!!! Там работали неявные преобразования, поэтому иногда ТАКОЕ получалось! Программист писал программу, вооружившись пониманием, что он — "сапер на минном поле". Динамическая память — тоже была. А уж система ввода-вывода — это надо было видеть! Все средства оси были непосредственно встроены в язык — собственно, поэтому он и не нашел такого распространения на других платформах.
В противоположность этому алгол-68 производил впечатление удивительно красивого кристалла, в котором каждая грань на месте, и ничего ни убавить, ни прибавить — невозможно! Нарушается удивительная стройность, присущая этому языку...
В 1975 году я окончил универ и 11 сентября поступил на работу в Институт Кибернетики. На 110 рублей оклада Но проработал я там недолго — всего год, и мне удалось (а я был молодым специалистом и ОБЯЗАН был отработать 3 года ПО РАСПРЕДЕЛЕНИЮ!) свалить в геологический институт, где работа была интересная и платили побольше. Там как раз я и вплотную на практике познакомился с серией M20 — модель М-222. Задача была такая: на магнитной ленте была оцифрованная фотография земной поверхности, полученная со спутника... Одна точка — один символ. Яркость, естественно задавалась кодом от 0 до 255. И я должен был эту ленту читать и выводить на АЦПУ любой фрагмент. Причем, точки разной яркости, естественно, должны были выводится разными символами. Темные — буквой Ж или Ш, а светлые — точкой (.) или там точкой с запятой... Символов, естественно, было меньше. чем 255 — приходилось яркость масштабировать... Так что разные портреты, которые тогда модно было печатать на компьютере (Христос, Бриджит Бордо, Монна Лиза и множество других) — это детские игрушки по сравнению с реальной задачей.
Писал я как раз в системе ИС-2, и здорово ее тогда освоил. Она на меня произвела очень хорошее впечатление — пишешь алгоритм в кодах, не задумываясь о реальном распределении адресов, назначая по ходу дела условные. А система сама при загрузке заботится о реальном распеделении памяти. Памяти было много — 8192 ячейки по 45 разрядов. Сюда помещалось все — ис ситема ИС-2, и моя программа.
Я добился результата — программа печатала любой фрагмент оцифрованной фотографии, перематывая ленту к нужному байту (хотя тогда это были еще не байты ) Но результат, естественно, надо было доводить с точки зрения изображения. И потом предполагалось навеситть элементы ИИ — распознавание разломов коры. например — в таких местах залегают полезные ископаемые... Но не сложилось... Пошел я работать на кабельный завод в отдел АСУ — но об этом позже...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, McSeem2, Вы писали:
MS>говоря, надо обязательно прорабатывать теорию. Например, один мой приятель с прикладной математики ННГУ (Нижний Новгород) чуть ли не целый семестр гоняет народ по базовым структурам данных — именно таким, как числа с плавающей точкой (кстати, на Фортране). У него студенты проходят "первичную обработку", закладку фундамента. Далее уже идут конкретные языки и прикладные направления (если Вове Савину не сдал, дальше тебе в программировании делать нечего).
Не давилось мне у Вашего приятеля учиться. Видно он не с ВМК -- фортран на нашем факультете не преподают. Хотя наверное зря -- было тут несколько дипломных работ, для которых требовалось реализовать какой-то алгоритм. Мои сокурсники реализации этих алгоритмов находили, но к их великому несчастью были на фортране. Поэтому мне приходилось выступать в роли переводчика.
MS>Мне было гораздо проще, поскольку я имел представление о схемотехнике и о том, что же происходит на уровне ниже ассемблера. Не уверен, что надо уходить в такие дебри, но то, что эти знания были для меня полезными — это неоспоримый факт. Другое дело — надо быть реалистом и соотношениие стоимость/качество вряд-ли будет оптимальным, если начинать с электроники и схемотехники.
А нам в школе про "цифровую логику" рассказывали -- на уроках информатики схемы всякие рисовали по таблице истинности. Тока кроме меня, ну может быть еще пары человек, их никто не понимал. А на хрена? Всем поиграть бы... А мне это было интересно, потому что читал журнал "радио", да и сам паял всякие ненужные штукенции. До сих пор под диваном лежит куча этого добра -- выбросить жалко...
... << RSDN@Home 1.1.4 beta 3 rev. 241>>
"Бог не терпит голой сингулярности" -- Роджер Пенроуз
Здравствуйте, McSeem2, Вы писали:
MS>И я тоже делаю "не для общего интереса". Но кто из нового поколения будет придумывать новые JIT'ы, если не будет курсов по ассемблеру и C++?
Попробую еще раз пояснить свою мысль. Наличие некоего предмета в обязательной программе не есть обязательное требование для его использования в профессиональной деятельности. К примеру вряд ли где есть специальный предмет, посавященный архитектуре видеочипов, однако их разрабатывают. Вобще, с точки зрения обучения все знания делятся на общие и специальные. Общие важно знать каждому, специальные только тем, кому это надо в его деятельности. Так вот — ассемблер давно скатился в нишу знаний специальных. Нужно человеку писать кодогенераторы в нативный код — он изучит нативный ассемблер. Понадобится работа с IL в дотнете — изучит IL. Но если не понадобится, то он спокойно обойдется без этих знаний.
Здравствуйте, Mamut, Вы писали:
M>[]
M>А можно ма-а-аленькую просьбу
M>Можно последующие части называть "Часть-1", "Часть-2" и т.д., а то я их нахожу с трудом — в основном, по большому количеству проставленных оценок
Хорошо. Вечером продолжу — это будет уже часть 4?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Mamut, Вы писали:
M>>[]
M>>А можно ма-а-аленькую просьбу
M>>Можно последующие части называть "Часть-1", "Часть-2" и т.д., а то я их нахожу с трудом — в основном, по большому количеству проставленных оценок LVV>Хорошо. Вечером продолжу — это будет уже часть 4?
Итак продолжаем...
Пошел я работать на Кабельный завод в отдел АСУ. Начальником отдела был один из выпускников нашего же универа — я его встречал там. Интересно, что тогда тоже было. как сейчас: я в первый же день писал программу — что-то вроде тестового задания. На Коболе-32! Был такой компьютер Минск-32 — продолжение серии Минск. Год это уже был 77, и на ассемблере в АСУ, конечно никто не писал (хотя я ради интереса потом попробовал — нормально!). Вполне был уже хороший комп, с консолью оператора — это была пишмаш Консул И ося имелась — до 4 программ одновременно можно было запускать... С перфокарт, естественно... Лентопротяжки были уже вполне ЕСовские и их было 4-8 штук. Были даже диски!!!!!
А задачи писали на Коболе-32 — была такая русскоязычная версия кобола. Программа состояла из секций: секция данных, секция действий (она по-другому называлась — я не помню сейчас). В секциях были параграфы. Можно было выполнить любой параграф как подпрограмму. Кобол отличался многословием... Ориентирован он был, конечно, на обработку больших массивов данных, и операторы там были заточены на это... Например, был такой оператор сортировать ... со сменой катушек... Имелось ввиду катушки на лентопротяжке.
И вот я сел писать программу на этом коболе... Хорошо, что я с ним был знаком — в универе знакомились! Короче, я написал ее за один день — на бумаге, естественно... Но когда я в конце рабочего дня принес ее и показал начальнику — он чуть со стула не упал! Ты, говорит, писал раньше? Нет, первый раз... Ну, говорит, много я видел программистов, но чтоб вот так за 1 (!!!!!) день на КОБОЛЕ (!!!!!!) программу написали, да еще без явных ляпов! Короче, меня взяли... И началось!!! АСУ есть АСУ — с вечера (после окончания рабочего дня в 18.00) дежурная смена начинала гнать задачи на завтрашний день...
Обычно сначала гнали простые задачи, а ближе к полуночи ставили "тяжелые" сортировки на лентах... А когда начинали считать зарплату — это вообще неделю АСУ на ушах стоял... Я тогда осознал, насколько важны, во-первых, архитектура системы, и во-вторых, контроль ввода ... Это из-за зарплаты, поскольку сделана она была, как я сейчас понимаю, через абсолютную задницу (прошу прощения у модератора).
Там же на кабельном я познакомился с еще одним видом программистской работы — сопровождением кода, который писал другой программист — это было что-то! Как же я тогда плевался! Ну, материться я не умею, но если б умел — обложил бы и код, и автора, которая сидела тут же рядом, во столько этажей, во сколько поднять смог бы! Это дало мне понимание, что в программе должна быть какая-то структура ( не забывайте, что это было всего на 2-3 год после окончания универа!).
Я там за год вырос до малень кого начальника — стал начальником типа производственного сектора — над всеми операторами. С нехилой зарплатой в 170р + 40% премии! Это на 3 год после института. Но проработал недолго — не выдержал быть постоянно крайним. Но тогда я понял. что некоторые работы женщины выполняют неизмеримо лучше мужчин. Когда у меня была женская ночная смена — они заканчивали всю работу часа в 2 ночи и спокойно ложились спать до примерно 7, когда выпускали небольшие остаточки... А мужики вечно опаздывали — просто хорошо известную работу. даже сложную, но известную, женщины делают лучше... Мужики лучше там, где есть новье какое-нить...
В общем, ушел я с Минска-32 и с кабельного завода обратно в Институт Кибернетики, но в другое подразделение. И вот там-то и начал писать на ЕС — заврта утром напишу...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Был такой компьютер Минск-32 — продолжение серии Минск. Год это уже был 77, и на ассемблере в АСУ, конечно никто не писал (хотя я ради интереса потом попробовал — нормально!). Вполне был уже хороший комп, с консолью оператора — это была пишмаш Консул И ося имелась — до 4 программ одновременно можно было запускать... С перфокарт, естественно... Лентопротяжки были уже вполне ЕСовские и их было 4-8 штук. Были даже диски!!!!!
У нас этот Минск-32 демонтировали только в 85-м году и заменили на подержанную ЕС-1034. Временно, года на полтора, потом планировали поставить новый комп неимоверной мощности ЕС-1066, но эти времена так и не наступили... Так что Минск-32 я только видел, новых "операторов ЭВМ" для него уже не требовалось и новых программ не писалось.
LVV>Обычно сначала гнали простые задачи, а ближе к полуночи ставили "тяжелые" сортировки на лентах... А когда начинали считать зарплату — это вообще неделю АСУ на ушах стоял... Я тогда осознал, насколько важны, во-первых, архитектура системы, и во-вторых, контроль ввода ...
Не помню, как у нас назывались устройства ввода, но на них работал целый отдел, ОВИ — отдел ввода информации. Информация поступала с метеостанций и постов. Пост представлял собой небольшую будку и несколько измерительных приборов — термометр, барометр, "осадкомер", "ветроспидометр". Некий ДядяВася, начальник поста, несколько раз в сутки снимал показания и записывал их на специальных бланках. Ставил свою подпись и печать. Эти бланки специальной государственной курьеской почтой отправлялись к нам. Было несколько сотен постов по всей области. Метеостанции были помощнее и были оснащены телетайпом. После чего информацию надо было вбить, по ней считалось много разной статистики. Точность данных была весьма важна, поэтому отдел ввода работал в две или три руки. У каждой барышни был маленький монитор, типа 20x12 символов и клавиатура с цифрами (буквы были не нужны). Одна и та же информация вводилась три раза, после чего верифицировалась (тройной ввод позволял выполнять автоматическую верификацию). Это считалось достаточным обеспечением надежности данных. Иногда использовалось лишь двойное дублирование, но это считалось недостаточно надежным.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Не помню, как у нас назывались устройства ввода, но на них работал целый отдел, ОВИ — отдел ввода информации. Информация поступала с метеостанций и постов. Пост представлял собой небольшую будку и несколько измерительных приборов — термометр, барометр, "осадкомер", "ветроспидометр". Некий ДядяВася, начальник поста, несколько раз в сутки снимал показания и записывал их на специальных бланках. Ставил свою подпись и печать. Эти бланки специальной государственной курьеской почтой отправлялись к нам. Было несколько сотен постов по всей области. Метеостанции были помощнее и были оснащены телетайпом. После чего информацию надо было вбить, по ней считалось много разной статистики. Точность данных была весьма важна, поэтому отдел ввода работал в две или три руки. У каждой барышни был маленький монитор, типа 20x12 символов и клавиатура с цифрами (буквы были не нужны). Одна и та же информация вводилась три раза, после чего верифицировалась (тройной ввод позволял выполнять автоматическую верификацию). Это считалось достаточным обеспечением надежности данных. Иногда использовалось лишь двойное дублирование, но это считалось недостаточно надежным.
У нас в Ташкенте был институт, который назывался САРНИГМИ Это СреднеАзиатский Региональный Научно-Исследовательский ГидроМетеорологический Институт — во как! Таких в мире — всего 16, 4 из них — в СССР. Один из них — в Ташкенте... В те времена там стояла сосем интересная машина, видимо из военных. Называлась Весна! Дисков на ней не было, былои только барабаны — очень хорошее и быстрое устройство прямого доступа, но тогда, конечно, ограниченной емкости и не сменяемое — ну как винчестер сейчас.
Модемы — шкафы тоже были, в расписании работы машины было выделено специальное время (несколько раз в день) когда она работала только на прием информации и запись ее на ленты. Расчет погоды начинали гнать, начиная с полуночи, поскольку к утру — к 6 часам все должно быть посчитано и готово к отправке в нужные места...
А по поводу ввода информации в АСУ тоже могу сказать, что у нас тоже был специальный отдел, который этим занимался... Например, задача по учету готовой продукции обычно начиналась с того, что поступающую информацию набивали на перфокарты. Для контроля, естественно, набивали два разных оператора. А потом этот двойной комплект уже вводился программой на ленту и программа выбрасывала все несовпадения. Далее были корректировки — опять двойной ввод... И так до тех пор, пока, вся информация в правильном виде не попадала на ленту. И только потом начинался обсчет и вывод ведомостей.
Второй способ контроля — контрольные суммы — стал применяться. когда перфоввод заменили на ввод сразу на магнитные ленты — были такие устройства. Человек набирал так же, как на перфораторе, но запись шла прям на ленту. Контрольная сумма считалась самим устройством. А чеоловек должен был ввести посчитанную независимо для сравнения. Это тоже было еще то удовольствие. На наших советстких машинах это как-то не очень прижилось, а вот на серии СМ-1420 (pdp-11) был такой период, когда такой ввод активно использовался.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Перейдя на работу обратно в институт кибернетики, я впервые столкнулся с ЕС ЭВМ. Тогда там стояла ЕС-1020, которую довольно быстро заменили на ЕС-1022. Работали мы на PL-1, писали программы для Гражданской обороны Узбекистана. Задания были примерно такими: Даются координаты на карте некоего удара — химического, ядерного или бактериологического; задаются скорость и направление ветра — надо расчитать облако. И не только расчитать, но и напечатать (опять на АЦПУ!) это самое облако, смасшабировав относительно карты! То есть опять пересчет из кртографических координать в целые, причем, облако может быть "широким" — шире полосы бумаги, поэтому надо было печатать его полосками! Особенный кайф получался. когда облако длинное, а по ширине не влезает 1-2 символа — получалось практически чистая полоса бумаги, которую мы использовали для написания следующих программ, или просто для печати андеграудной литературы!
Режим работы был отчужденный — мы сдавали вечером колоды перфокарт в ВЦ, а утром забирали распечатки с результатами работы. Представляете, если в программе была простая опечатка, ты наутро получал кучу синтаксических ошибок!?
Да и режимность была: после сдачи программы в эксплуатацию любые изменения в ней делались по акту! Акт гласил, что из колоды изъято столько то перфокарт, номера такие-то, а добавлено столько то перфолкарт — новые номера такие-то.
Вот была жизнь, блин!
Работали мы тогда в оси ДОС ЕС. Задание оформлялось с помощью упрощкенного варианта операторов JCL Job, EXEC, DD и у меня не оставило особых следов в памяти. Вот когда я перешел в соседний отдел, и там мы уже начали работать в ОС ЕС, это уже как-то отложилось. Отдел занимался разработкой задач, оптимизирующих расход ресурсов в городских сетях: тепловых, водопроводных, канализации и так далее...
Постановку задач делало отдельное подразделение, которое выпускало по каждой задаче документ. Этот документ попадал в сектор программмирования и наш начальник уже распределял, кто будет писать. Начальник был в программировании — не очень компетентен, поэтому задачи попадали в руки почти случайным образом. Помню смешной случай: разработчица, занимающаяся постановкой какой-то задачи по канализационной сети, принесла ГИПу (Главный Инженер Проекта) документ, в названии которого неосторожно написала слово "расход". ГИП был мужик остроумный и не преминул тут же ее поддеть: расход чего? Фекальных вод что ли? Ты уж напиши! Бедная не знала, что лепетать в ответ...
Режим работы на компьютере у нас опять был индивидуальный — ма арендовали время в статистическом управлении и заказывали время еженедельно. Причем, можно было работать и днем. Тут я довольно быстро освоил работу с библиотеками и перестал таскать колоды — только корректировку. У компа был пульт оператора — это была все та же пишмаш Koнсул, выпускаемая в ГДР. Ох и трещал же он, когда сообщения печатал!
Программист работал на компе как оператор тоже. И должен сказать, язык оператора, и язык управления заданиями — это были две большие разницы. Job Control Language состоял фактически из трех команд Job, Exec, DD (Data Definition — кажется). Но каждый из операторов JCL включал огромное количество параметров. Особенно это касалось DD, в котором прописывалось все, касающееся набора данных на дисках.
Из командыы Exec (ехец, как мы ее называли) можно было передать информацию в программу из поля Parm. Считалось, что программист, который может написать программу получения этой информации — а писать надо было на ассемблере — очень хороший спец. Могу гордиться, что в соревновании с комендой, разработавшей СУБД ИНЕС-2 (а это коллектив под управлением Михаила Донскова — одного из создателей Каиссы, первой шахматной программы-чемпиона) я вышел победителем. У них в системе Инес-2 программа получения информации из поля Parm содержала 43 команды, а мне удалось уложиться в 42! И короче я уже больше нигде не видел.
На этой работе я довольно хорошо освоил PL-1. Патался использовать препроцессор — была у этого языка такая фишка. В качестве операторов использовались те же операторы, но спереди стоял знак % можно было писать даже процедуры — и все это в рамках того же языка, не изучая новых конструкций. Пытался я использовать и оператор On, но быстро понял, что задачи несколько не те.
Но более всего мне запомнилоась моя попытка использовать списки для обработки входной информации. Так как количество входа было неизвестно заранее (и проектировщики ничего вразумительного сообщить по этому поводу не могли) я решил организовать на входе односвязный список. Я смог его реализовать и отладить (учтите, что нам ничего подобного в универе не читали — просто не было таких преподов, и книжек еще было мало — но я именно по литературе сработал).
Но испытав на практике все прелести управления динамической памятью я для себя решил, что больше НИКОГДА в асучной задаче динамику использовать не буду — себе дороже! Так и держусь до сих пор...
Ну, а в 1981 году я перешел на другую работу и тут уже попал на дисплеи — расскажу завтра.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>У них в системе Инес-2 программа получения информации из поля Parm содержала 42 команды, а мне удалось уложиться в 42! И короче я уже больше нигде не видел.
Пардон! У них было 43, а у меня — 42.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
