Комментарии 49
Центральный процессор имел цикл выполнения микрокоманд в 170 нс (5,88 МГц).[4]
Команды Q-Code могли выполняться со скоростью до 1 млн команд в секунду.
Немаленькая скорость для тех лет...
Интересная статья, спасибо!
И кстати эта ссылка Xerox Alto также очень интересная... Те самые времена, когда в индустрии еще была оптимизация и не было "избыточных требований к железу" в угоду "развития бизнеса"...
Я если честно «те самые времена» не застал (не настолько старый), но замечу что ни Xerox ни Perq не были доступны массовому потребителю даже близко, их использовали ученые‑исследователи, архитекторы и инженеры‑проектировщики — техническая элита тех лет.
А что касается бизнеса, так компания создавшая Perq достаточно быстро прогорела, не выдержав конкуренции с американскими компаниями и была продана вместе со всеми наработками.
Обратите внимание на версию 5с в найденном документе по разработке — это фактически самый конец существования компании, поскольку 5я версия так и осталась невыпущенной.
В качестве бонуса будет компилятор Pascal из далеких 70х.
По мере поступления COBOL, Asembler, PL/1, Fortran, Pascal это сильно нас напрягало. Странно все это - это ПО еще до сих пор кому -то надо.
PERQ был интересный проект, небольшое дополнение, типа про корни -
примерно в середине 70х стало понятно, что для разработки VLSI необходимы графические рабочие станции в огромном количестве, желательно недорогие, т.е. то что Sun и Silicon Graphics в массовом количестве производили в 80х, графические станции типа IBM 2250 были, но стоили супер дорого, darpa поддерживала эти проекты (как и создание сети) одновременно в нескольких местах на конкурсной основе, в том числе MIT, Stanford, и Carnegie Mellon, где проект назывался SPICE, типа Scientific Personal Environment, типа Xerox Apollo только дешевле, это и был PERQ, в Stanford тем временем работали над Stanford University Terminal (=SUN), который получился дешевле и лучше + использовал UNIX (BSD), в 1981 PERQ заинтересовалась ICL и начала производство в UK, сначала с Accent OC, позже MPOS, и UNIX, в середине 80х стало ясно, что соревнование с SUN в общем проиграно, в 1985 работы закрылись, хотя позже были неудачные попытки продолжить
ps
первая хорошая книга про VLSI - "Introduction to VLSI" Conway, Mead (1979), тоже имеет прямое отношение к этим работам
Причем в качестве основного языка разработки в Perq выступает Pascal:
А что тогда эмулятор написан на C#, а не на Delphi/Lazarus?
Автор был недостаточно идейным видимо.
Если серьезно, то я бы радовался что такое вообще есть в природе — невероятная удача сделать такой эмулятор для машины из 1970х, беклог с описанием шагов и процесса создания автор не выкладывал, но я видел подобное для станции Xerox, так что представляю сколько там было сложной работы.
когда я пишу на ASM 6502 то вспомогательно пишу на C# и даже не представляю зачем бы мне писать на ассемблере для x86. Мне кажется выбор языка для написания эмулятора никак не связан с эмулируемой платформой.
А я бы на современном Object Pascal (Delphi или Lazarus) этот эмулятор реализовал, так сказать отдать дань уважения к изначальным разработчикам. Тем более по ссылке на гитхаб кое какие кода на древнем Паскале имеются.
А я не уважаю все языки, где для присваивания нужно писать :=, это как программирование через дырочку в заборе.
PS: вы же понимаете насколько это глупо? я 7 лет писал на Бейсике, 5 лет на Clipper/FoxPro, 10 на Делфи, в промежутках был ассемблер и C, а потом и питон, но когда попал за C# я понял - это мой идеальный ЯП. Он буквально такой как я хочу чтобы был язык высокого уровня. Ты не успеваешь подумать что бы тебе такое реализовать чтобы было удобно, а майки уже всё запихали и тебе нужно только написать a.b() и смотреть на результат. У питона масса своих плюшек, но для меня это настолько вырвиглазный синтаксис, что у меня глаза кровоточат.
На вкус и цвет как говорится. А мне наоборот C# не нравится, не буду писать по каким причинам, это займёт уйму времени. Мой идеальный ЯП это С++.
я на с++ в 90-е писал, недавно решил проверить сколько времени и кода нужно чтобы переписать простую утилиту консольную на с++ с С#, оказалось что дольше на 40% и код на 50% длиннее Так что для меня это оптимальный выбор, когда концентрируешься на самой программе а не на том, как реализовать простейшие вещи.
ну и как по мне - нет плохих языков, просто для разных задач разный инструмент.
Справедливости ради C++ уже тоже далеко не тот что был в 90е, помимо появления библиотек вроде Boost развивается и сам стандарт.
Вот для примера код на современном C++ 17 одного сетевого фреймворка, который я портировал с Linux на FreeBSD в прошлом году.
Его объем вполне сопоставим с версией на С#.
просто для разных задач разный инструмент.
В этом то и дело. С++ является во многих областях разработки де-факто отраслевым стандартом, например, разработка DAW и VST, там уж извините ни C# ни Delphi тем более прочее "программирование с презервативом" типа Python и Java не используется.
меня мало заботит где там с++ чем является, я ответил человеку, который сказал "фи" о С# не понимая как раз этого.
я пишу на ассемблере, так что ваш с++ для меня точно такое же программирование с презервативом.
Представляю, сколько строк на асме займёт реализация простого класса с конструктором, деструктором, парой виртуальных методов и несколькими приватными членами. ))) Гемор ещё тот.
P.S. Вот С/С++ ну никак "программированием с презервативом" назвать нельзя, да даже тот же Object Pascal, если на то уж пошло. Как никак указатели имеются, память выделяется/освобождается "вручную" (хотя сейчас в С++ smart pointers имеются) и код выполняется без всяких "презервативов" в виде CLR для C# и JVM для Java.
вы мне очень напоминаете религиозного фанатика
Представляю, сколько строк на асме займёт реализация простого класса
а какая разница если в моей ассемблерной религии фанатизм не принимает другие языки, а все кто пользуется надстройками над ассемблером - проклинаются на веки вечные.
Вот С/С++ ну никак "программированием с презервативом" назвать нельзя
Это просто слова еретика, которого обманул дьявол.
а какая разница если в моей ассемблерной религии фанатизм не принимает другие языки, а все кто пользуется надстройками над ассемблером - проклинаются на веки вечные.
А сразу в машинном коде слабо писать?
P.S. Мне ещё в институте помнится асм весь мозг вынес. В те времена изучали его для отечественного проца К580ВМ80...
В Delphi (Object Pascal) тоже есть смарт принтеры, а помимо этого, ещё с давних времён имеется механизм владения и нотификации об уничтожении
смарт принтеры
О!!! Это как? 😳
Если имелось в виду умные указатели, то как таковых в фабричной поставке "из коробки" их нет. Есть некоторые реализации от энтузиастов, например это. Однако в официальной документации на сайте embarcadero о smart pointers ничего нет.
На Delphi они реализуются буквально в 10 строк, на любой вкус и цвет. Не говоря уже о том, что есть готовые реализации в официальном менеджере пакетов.
В них особой нужды в Delphi просто-напросто нет.
что есть готовые реализации в официальном менеджере пакетов.
Да что вы говорите? Будьте добры ссылку с официального сайта embarcadero.com с пакетом где имеются умные указатели. А если не сможете - нехрен тогда отрицательный голос в моих ответах ставить!
В них особой нужды в Delphi просто-напросто нет.
Ага, нужды нет. Одно дело пишешь:
obj := TSameObject.Create;
try
obj.DoSomething;
finally
FreeAndNil(obj);
end;
В случае с Smart Pointer всё проще по идее будет:
obj := TSmartPointer<TSameObject>.Create;
obj.DoSomething;
Так как надобность в try/finally и освобождением объекта отпадает.
P.S. Вашу компетентность в Delphi ставлю под большое сомнение.
Систему владения знаешь? Она в делфи реализована из коробки на основе TComponent (Owner, Free notify).
Ищи в GetIt пакет "Mitov" или кучу разных на GitHub.
Я себе реализовал (20 строк кода) defer/errdefer из языка Zig, и могу писать так: var s := TStringList.Create; defer(s); (именно подряд), а дальше любой код. В том числе, это работает и в локальном скоупе.
Зайди на мой гит, а потом пробуй что-то там ставить под сомнение. Реализация defer тоже есть на Гите.
И это не я ставлю минусы, так что ...
Систему владения знаешь? Она в делфи реализована из коробки на основе TComponent
Я ему про Фому, он мне про Ерёму...
Причём тут TComponent, который ещё с cамой первой версии Delphi известен? Речь то вообще то идёт про умные указатели, и это абсолютно разные вещи, которые роднит только то, что их не нужно освобождать "вручную". Используя TComponent в качестве родительского класса можно напихать в него что угодно, и ещё и закинуть в палитру компонентов, дабы в дизайнтайме его тупо бросать на форму, сведя к минимуму бряцание по клавиатуре. С таким подходом точно умные указатели не потребуются. 😄
Ага, нужды нет.
Речь шла об этом. О том, что умные указатели не сильно нужны. Потому что есть много других способов управлять объектами. Умные указатели - лишь один из способов.
TComponent обладает методами, которые позволяют реализовать систему владения объектами и из коробки стыкуется с многими штатными классами. Этот подход, например, используется в Rust.
Далее, как я уже сказал, легко можно реализовать defer, который укладывается в несколько строк, или который можно просто стануть с гита.
После этого - интерфейсы.
Есть ещё и ARC, для извращенцев. Его можно включить директивой.
И в Делфи уже давно есть деструкторы и конструкторы у record, которые очень легко позволяют реализовать умные указатели.
TComponent обладает методами, которые позволяют реализовать систему владения объектами и из коробки стыкуется с многими штатными классами.
Вот в том то и дело, большая часть автоматического сбора мусора в Delphi/Lazarus решается производными TComponent. А освобождение остальных объектов, производных TObject, особо не напрягает. Поэтому не всегда овчинка стоит выделки, мне лично незачем писать отдельный код для этого, достаточно банального obj.Free; или FreeAndNil(obj); и это абсолютно не напрягает.
сколько строк на асме займёт реализация простого класса с конструктором, деструктором, парой виртуальных методов и несколькими приватными членами.
А зачем это всё в коде на ассемблере?
FL Studio и тонны плагинов для этой программы написаны на Delphi
FL Studio раньше то же на Delphi писалась, однако последние версии всё же на CBuilder сделаны. Хотя CBuilder вполне может собирать и делфийский код, особенно вся VCL написана же на Паскале и прилинковать её к С++ коду в RAD Studio получается без проблем.
Насчёт VST плагинов хочу сказать одно - простые плагины, как правило собрать в Delphi можно без проблем, какой нибудь дисторшн, например. Да и то некоторые фреймворки для этого, как например Delphi ASIO & VST Project, в своём коде DSP используют ассемблерные вставки. Однако, если Вы решите разработать на Delphi, например, сурьёзный виртуальный синтезатор, то поверьте гемора не оберётесь. Пишу потому, что было дело разработал виртуальный синтезатор PolyGAS, который полностью был сделан на Delphi 7. Он нормально работал при скромном количестве одновременно звучащих нот, однако стоило на нём сыграть профессиональному музыканту, он увы уже не "вывозил" поставленную задачу, вызывая перегруз CPU. По сему в данное время на Delphi практически ни кто плагины и тем более DAW не пишет. Благо есть уйма С++ VST фреймворков с вполне демократичной лицензией, например, IPlug2.
Что за глупости? Во-первых, FL Studio до сих пор на Delphi. Во-вторых, Delphi 7? Серьёзно? А чё не Delphi 5? Все сейчас пишется в том числе и на Delphi.
Никакие не глупости, откройте любым качественным просмотрщиком ресурсов, например, PE Explorer исполняемый файл FL.exe и смотрите в разделе RCData значение параметра DVCLAL там будет следующее:
-C++ Builder Professional Version
А если исполняемый файл был собран Delphi, то Вы увидите примерно такое:
-Delphi Client/Server Suite (Enterprise)
FL Studio до сих пор на Delphi.
Как вам вот это?
https://www.embarcadero.com/case-study/image-line-software-case-study
Я же вам писал, что GUI FL Studio сделана на Delphi VCL, как и любая программа собранная как CBuilder, так и Delphi. А DSP у них навряд ли сделана на Паскале, скорее всего на ассемблере, потому как не вытягивает Паскаль сложные алгоритмы работы со звуком.
P.S. Вы вообще хоть один VST - плагин то написали, чтобы спорить с человеком, который плагинстроением занимается уже третий десяток лет?
не вытягивает Паскаль сложные алгоритмы работы со звуком.
Если у вас расчёты в плавающей точке, то справедливости ради, в современных Дельфях в x64 стало получше, т.к. перешли с FPU на SSE2. Можно рассчитывать на ускорение раза в 2.
Но конечно, у С/C++ прогресс компилятора за то же время гораздо больше (автовекторизация и пр.). По той простой причине, что в них вкладывается куда больше сил и денег, чем в непопулярные Паскали.
Ещё немаловажным обстоятельством является тот факт, что VCL некроссплатформена, а FMX наотрез отказывается работать в VST врапперах. Так как профессионалы музыкальной индустрии пишут музыку исключительно под macOS, то на Delphi не удаётся создать плагины под эту ось. По сему в этой нише С++ является де-факто отраслевым стандартом, и навряд ли что то поменяется в будущем.
Если у вас расчёты в плавающей точке, то справедливости ради, в современных Дельфях в x64 стало получше, т.к. перешли с FPU на SSE2.
А это справедливо для каких именно чисел: single, double или extended?
А это справедливо для каких именно чисел: single, double или extended?
Single и Double. Extended в SSE вообще нет, так что в x64 Extended = Double.
Для Single желательно использовать {$EXCESSPRECISION OFF}, иначе расчёты пытается делать в Double и тормозит из-за постоянных преобразований.
Каких-то чудес ждать не стоит, это скалярный SSE без векторизации, ускорение заметно в основном из-за неэффективности старого FPU-кодогенератора (и в целом FPU на современном железе).
Во-вторых, Delphi 7? Серьёзно?
Первая версия PolyGAS была разработана в 2005 году, в те времена Delphi 7 была де-факто стандартом для многих разработчиков Delphi.
Последняя версия уже была сделана на Delphi XE8 в 2017 году, после чего было решено портировать код на С++.
А сразу в машинном коде слабо писать?
религия не позволяет
P.S. Мне ещё в институте помнится асм весь мозг вынес
как может вынести мозг алгебра?
В те времена изучали его для отечественного проца К580ВМ80...
который i8080А.
PERQ: оживляем чудо из 1970-х