в своё время тестировал видюхи -- и использовал их параллельно для разогрева блинчиков. Конечно, микроволновка разогревает быстрей и горячей, но куда мне спешить и зачем обжигаться? тесты долгие, а так утилизация бесполезного тепла и экономия энергии :)
В порядке придирок -- весьма и весьма много ошибок в русском языке, начиная с экспЕрИмента.
По существу вопроса: как минимум, адреса команд стоило б выводить в шестнадцатеричном виде, при реальной работе это обычно намного удобней, чем в десятичном.
"Нанометры" технологии уже довольно давно (навскидку -- после 40 нм) не отражают реальные геометрические размеры транзисторов, а являются "маркетинговыми", как здесь уже отмечали. Поэтому брать сей маркетинговый размер и из него пытаться посчитать количество атомов...
Микропрограммы хранились, скорей, в КР556РТ5, а не РТ4 -- 512*8, а не 256*4. Во всяком случае, в ряде СМок было именно так. Ну а РТ4 тоже использовались -- но больше как хитрые дешифраторы.
Ну, сказать, что "без процессора", никак нельзя -- есть процессор, есть. От того, что он реализован не в виде одной микросхемы, он процессором быть не перестаёт.
Костыльно-с. Как, впрочем, половина в Це++. Постоянно удивляюсь: добавить что-то навороченное комитет по стандартизации может, а простое и очевидное... религия, что ли, не позволяет?..
Вообще, с терминологией могут быть проблемы. Я лично придерживаюсь того, что операторы -- это if, while и т.п., ну а плюсы-минусы -- это операции. Соответственно, присваивание в Паскале -- оператор, а в Си -- операция. Ну а что возможности переопределения в Дельфях/ФриПаскале сильно ограничены -- тут да; развитие языка, как по мне, пошло по абсолютно неверному пути (стали подражать Жабе, похоже, -- а она ущербна по определению, ибо "управляемый" язык для работы на виртмашине, а не относительно низкоуровневый для работе на голом железе, как и классический Паскаль, и Си).
Массивы массивов были, многомерные массивы -- нет. Ну а что в Паскале много чего нет -- оно понятно. Идеального языка вообще нет (и быть не может, по большому счёту, ибо требования противоречивы).
И родная DECовская RSX-11M работала -- сам работал. Да и наша ОС-РВ -- это RSX-11M и есть, с парой мелких правок (во всяком случае, если говорить про ядро).
Точней, шесть регистров: седьмой и восьмой -- указатель стека и счётчик команд, так что не очень общего, хоть и нумеровались вместе с общими.
Под 6502, кстати, мне приятней писать было, чем под 8080. Правда, AVR8 ещё приятней -- но это уже совсем-совсем другое поколение (и транзисторов там немеряно по сравнению с этими -- одни только 32 регистра сколько жрут).
Можно ещё добавить, что, когда расширяли EBCDIC и превращали его в ДКОИ, не добавили в него все русские буквы, а только те, которые отличались по начертанию от латиницы, скорей всего, для экономии места на барабанах принтеров (число рядов на барабане соответствует числу печатаемых литер, соответственно, меньше символов -- меньше барабан, а значит, при прочих равных, принтер дешевле, а печать -- быстрей, ведь для печати одной строки нужен полный поворот барабана). О том, что будут возникать проблемы, в частности, с сортировкой, особо не думали: в СССР латиница особо не требовалась. Да и за бугром тоже не особо в те времена думали, а иногда и сейчас не думают (из-за чего даже в относительно современном ПО могут быть проблемы с символами, отличными от английского алфавита -- включая западноевропейскую латиницу со всякими там ударениями и умляутами). В общем, было бы ошибкой думать (с)
Ну, что эффективная, но сложная система команд однозначно затрудняет создание хорошего кодогенератора -- это, конечно, так. Но, как по мне, это не повод делать неэффективную систему команд -- а любые классические RISCи именно такими и являются. Недаром постепенно они сами от своих идей и отошли. Скажем, у современных ARMов единственное, что от идеологии RISC осталось, -- это отсутствие команд, прямо обрабатывающих данные в памяти, все остальные атрибуты они утратили: есть сложные команды, выполняемые несколько тактов, команды имеют разную длину (система команд Thumb), декодирование стало весьма нетривиальным...
Ну и про ручное программирование всё ж не стоит забывать. Да, на ассемблере пишут редко, но иногда такая нужда бывает. Кроме того, помня, что 90% времени расходует 10% кода, в некоторых задачах вполне оправданной может быть ручная ассемблерная оптимизация. Естественно, подходить надо без фанатизма, но и без пофигизма (зачем оптимизировать? поставим более мощный проц! а что мобила из-за этого работает от батареи 2 часа, а не 20 -- пофиг, у конкурентов то же самое).
Если память не изменяет, в VAX разделение памяти на 2 нижних гига и 2 верхних навязывалось архитектурой, -- но, возможно, с чем-то путаю, а искать сейчас лениво :) Ну а в Системе 370 и последующих у всей памяти полное равноправие. Вообще, в смысле системной архитектуры IBMовские мэйнфреймы -- пожалуй, самые прямые из всех машин (а одни из самых кривых, если не самые кривые, -- ПК :) ).
А как с советом № 20 перекликается вот такое из совета № 19?
"Наш дизассемблер" -- справа столбец адресов в явно десятичном виде: 6099, за ним 6100 и т.д.
ADD. А, блин, это я ступил: это номера строк, а не адреса. Ну, тогда адреса надо б добавить.
в своё время тестировал видюхи -- и использовал их параллельно для разогрева блинчиков. Конечно, микроволновка разогревает быстрей и горячей, но куда мне спешить и зачем обжигаться? тесты долгие, а так утилизация бесполезного тепла и экономия энергии :)
В порядке придирок -- весьма и весьма много ошибок в русском языке, начиная с экспЕрИмента.
По существу вопроса: как минимум, адреса команд стоило б выводить в шестнадцатеричном виде, при реальной работе это обычно намного удобней, чем в десятичном.
"Нанометры" технологии уже довольно давно (навскидку -- после 40 нм) не отражают реальные геометрические размеры транзисторов, а являются "маркетинговыми", как здесь уже отмечали. Поэтому брать сей маркетинговый размер и из него пытаться посчитать количество атомов...
Микропрограммы хранились, скорей, в КР556РТ5, а не РТ4 -- 512*8, а не 256*4. Во всяком случае, в ряде СМок было именно так. Ну а РТ4 тоже использовались -- но больше как хитрые дешифраторы.
Ну, сказать, что "без процессора", никак нельзя -- есть процессор, есть. От того, что он реализован не в виде одной микросхемы, он процессором быть не перестаёт.
Тогда property -- тоже не сахар, потому что написать код с его помощью быстрее, проще, понятнее и безошибочнее, чем костылями.
Ну дык и Си -- тоже сахар. И ассемблер тоже. Что мешало писать прямо в машинном коде?
Костыльно-с. Как, впрочем, половина в Це++. Постоянно удивляюсь: добавить что-то навороченное комитет по стандартизации может, а простое и очевидное... религия, что ли, не позволяет?..
Ну, более громоздкий и менее читаемый синтаксис тоже не есть хорошо. Да и с переопределением операций проблемы.
О терминах не спорят, о терминах договариваются.
Вообще, с терминологией могут быть проблемы. Я лично придерживаюсь того, что операторы -- это if, while и т.п., ну а плюсы-минусы -- это операции. Соответственно, присваивание в Паскале -- оператор, а в Си -- операция. Ну а что возможности переопределения в Дельфях/ФриПаскале сильно ограничены -- тут да; развитие языка, как по мне, пошло по абсолютно неверному пути (стали подражать Жабе, похоже, -- а она ущербна по определению, ибо "управляемый" язык для работы на виртмашине, а не относительно низкоуровневый для работе на голом железе, как и классический Паскаль, и Си).
Массивы массивов были, многомерные массивы -- нет. Ну а что в Паскале много чего нет -- оно понятно. Идеального языка вообще нет (и быть не может, по большому счёту, ибо требования противоречивы).
А в Паскале многомерные массивы были 50+ лет назад. Да и модули Турбо Паскаля вменяемее и существуют лет 30...
И родная DECовская RSX-11M работала -- сам работал. Да и наша ОС-РВ -- это RSX-11M и есть, с парой мелких правок (во всяком случае, если говорить про ядро).
Точней, шесть регистров: седьмой и восьмой -- указатель стека и счётчик команд, так что не очень общего, хоть и нумеровались вместе с общими.
Под 6502, кстати, мне приятней писать было, чем под 8080. Правда, AVR8 ещё приятней -- но это уже совсем-совсем другое поколение (и транзисторов там немеряно по сравнению с этими -- одни только 32 регистра сколько жрут).
Можно ещё добавить, что, когда расширяли EBCDIC и превращали его в ДКОИ, не добавили в него все русские буквы, а только те, которые отличались по начертанию от латиницы, скорей всего, для экономии места на барабанах принтеров (число рядов на барабане соответствует числу печатаемых литер, соответственно, меньше символов -- меньше барабан, а значит, при прочих равных, принтер дешевле, а печать -- быстрей, ведь для печати одной строки нужен полный поворот барабана). О том, что будут возникать проблемы, в частности, с сортировкой, особо не думали: в СССР латиница особо не требовалась. Да и за бугром тоже не особо в те времена думали, а иногда и сейчас не думают (из-за чего даже в относительно современном ПО могут быть проблемы с символами, отличными от английского алфавита -- включая западноевропейскую латиницу со всякими там ударениями и умляутами). В общем, было бы ошибкой думать (с)
Ну, что эффективная, но сложная система команд однозначно затрудняет создание хорошего кодогенератора -- это, конечно, так. Но, как по мне, это не повод делать неэффективную систему команд -- а любые классические RISCи именно такими и являются. Недаром постепенно они сами от своих идей и отошли. Скажем, у современных ARMов единственное, что от идеологии RISC осталось, -- это отсутствие команд, прямо обрабатывающих данные в памяти, все остальные атрибуты они утратили: есть сложные команды, выполняемые несколько тактов, команды имеют разную длину (система команд Thumb), декодирование стало весьма нетривиальным...
Ну и про ручное программирование всё ж не стоит забывать. Да, на ассемблере пишут редко, но иногда такая нужда бывает. Кроме того, помня, что 90% времени расходует 10% кода, в некоторых задачах вполне оправданной может быть ручная ассемблерная оптимизация. Естественно, подходить надо без фанатизма, но и без пофигизма (зачем оптимизировать? поставим более мощный проц! а что мобила из-за этого работает от батареи 2 часа, а не 20 -- пофиг, у конкурентов то же самое).
Если память не изменяет, в VAX разделение памяти на 2 нижних гига и 2 верхних навязывалось архитектурой, -- но, возможно, с чем-то путаю, а искать сейчас лениво :) Ну а в Системе 370 и последующих у всей памяти полное равноправие. Вообще, в смысле системной архитектуры IBMовские мэйнфреймы -- пожалуй, самые прямые из всех машин (а одни из самых кривых, если не самые кривые, -- ПК :) ).