Наверное, потому, что в свое время Институт Радио активно использовал эту возможность PL/I. А когда появились первые IBM-PC/XT, они даже купили транслятор PL/I-86, чтобы быстро уйти с EC-ЭВМ, не переделывая программ. Но как раз этой возможности там и не оказалось (
я бы еще добавил "в учебных целях". На самом деле это частый случай. Результат дальше никуда не идет, но иногда это совершенно необходимая ступень для попыток создать реальный инструмент.
Не понял. Зачем мне 64-разрядный компилятор? Результат его работы - да, 64-разрядные ELF-файлы. Но самого-то зачем его менять с 32-х разрядов? Ведь это как раз тот случай, когда "640к хватит на все" )) Размер таблиц компилятора в 10-20 Мбайт это уже "сверх границ". Другое дело - выполняемый файл. Например, сейчас нам нужно 14 Гбайт данных в памяти, иначе никак. Но для этого 32-х разрядный компилятор генерирует всего-то 2 Мбайта 64-х разрядных команд (кодов).
что-то мне подсказывает что это как-то связано с DirectX.
Вы угадали. В прикладном ПО, перенос которого и является главной и конечной целью, видимо придется уходить на OpenGL. Но поскольку мы используем очень малую часть возможностей DirectX, надеюсь все пройдет легко.
На недоуменные вопросы отвечу так: я ничего не выбирал и ничего не устанавливал. Астру 5.15.0-70 установили на ноутбук китайцы на заводе в соответствии с договоренностью о продажах своих бытовых компьютеров в Россию. Кстати, при этом они перепутали Белоруссию с Россией и у меня теперь не "скачанные файлы", а "стягнутiыя файлы". Но мне это не мешает))
За советы установить не то, а это, искреннее спасибо, но есть области, где программист по своему желанию ничего установить не может. Например, как вы думаете, утвердит ли Роскосмос проектные документы на будущую станцию РОС, где будет написано:"ПО поддержки повседневной деятельности экипажа должно работать в среде Windows"? А ПО для какой ОС утвердит?
На том низком уровне, на котором я пытаюсь перенестить с одной ОС на другую, уже нет разницы между стулом и табуреткой. Как раньше я не чуствовал разницы для себя между Windows 7 и 10, так и сейчас не будет заметна разница между какой-нибудь Астрой и Альтом. Лишь бы GNU х86-64. Но пока доступ к DR0-7 - это головная боль, да.
Я писал о 1954 годе. А статья Колмогорова и Успенского - лето 1958 года, когда уже обсуждался будущий Алгол. Т.е. начиналась совсем другая эпоха. Что касается PL/1 и указателей в нем, то все-таки урежьте осетра, это был 1966 год, а не 1976. См., например, известную книгу "Мифический человеко-месяц", там история его применения для ОС/360 затрагивается.
Научный приоритет, вполне может быть и наш. У нас отличная математическая школа. А вот на практике, сомневаюсь, что разработчики PL/1 сами бы не пришли к подобному и вообще слышали о Колмогорове. Там были больше инженеры, а не ученые. Да и слишком все на поверхности.
Резюме. Я возражаю против исходного утверждения
PL/I (Programming Language One) ... где будут повторно ”впервые” использованы указатели, появится лишь в 1976-м
Оно не отражает действительность. Да, вики несправедливо приписывает "изобретение" указателей Лоусону. Но несправедливо и утверждать, что без Колмогорова в PL/1 не появились бы указатели.
Позволю себе не согласиться. В 1954 году еще не было ни широкой программисткой общественности, ни потребности разрабатывать языки, ни потребности вводить в них указатели.
Это такое же преувеличение, как и утверждение, что PL/I появился только в 1976 году.
Но при этом, я не ставлю под сомнение способности отечественных теоретиков программирования.
Например, комитет по разработке подмножества "G" PL/1 выразил благодарность группе коллег за ценные советы и предложения. В этом списке три наших соотечественника, включая А. Ершова.
Others who made important contributions to this standard were:
Paul W. Abrahams Kenneth Dritz Andrei P. Ershov A. Craig Franklin Mimi Gerstell Ev M. Greene Richard Howells L. Korneva Peter Krupp John Leffler Howell A. (Skip) Richards Gary Roberts David Sahakian W. Olin Sibert Anthony P. Smith Haruyuki Takeda Richard Weaver
Сам себя поправлю. Не в 1967, а в 1968 году в Киеве проходило мероприятие:
На котором был доклад о моделировании на PL/I.
Интересно, что все ключевые слова переведены на русский. Но пока вместо file - "ТЕКА".
В конце резюме: все как у "алголоязыков", но новое - работа с указателями. В конце ссылки на статью Харольда нашего Лоусона "Обработка списков на PL/1" от июня 1967 года и на спецификацию языка от IBM от января 1966.
Можно считать, что с этого момента широкая советская программисткая общественность была ознакомлена с указателями.
Если была минута, а стало - 16, то да. А так, что Вы сделаете за 45 секунд? А ошибки как выдавались на экран, так и выдаются. По умолчанию после ошибки все останавливается и ждет нажатия клавиш. В том числе клавиши прекращения. Кроме этого, ошибка наверняка проявится на первом же варианте и остальные 15 уже можно не выполнять.
Весь процесс распределения регистров x86 невозможно свести к фразе "раскрасьте граф". Если хотите погрузиться в волнующий мир распределения регистров - пробегите для начала вот это
А что мешает распараллеливать уже внутри вызова? Там же не сразу этот регистр требуется:
PUBLIC ?QB081: ;ВЫЗЫВАЕТСЯ ИЗ PL/1
MOV CH,1
PUBLIC ?QB08C: ;ВЫЗЫВАЕТСЯ ИЗ PL/1
MOV BH,AL ;СТАРШАЯ ЧАСТЬ ЗНАЧЕНИЯ БИТОВОЙ СТРОКИ
XOR BL,BL ;МЛАДШЕГО БАЙТА НЕТ
...
Сейчас все наоборот стараются побольше инлайнить
Ну и зря. В современных условиях стоимость обращения к памяти все время возрастает относительно времени выполнения команд.
Но многим кажется, что ладно данные, но уж следующие команды-то успеют скачаться, пока очередные скачанные команды выполняются. А это не факт. Поэтому уменьшение кода существенней влияет на быстродействие, чем раньше.
В данном случае, на мой взгляд, "щелевая" - это как анализировать, а "свертка" - это что делать. Команды ведь не выбрасываются, а лишь вкладываются друг в друга как матрешки.
Поскольку расположение кода относительно кэш-границ довольно-таки случайное, для объемных программ будет плюс-минус то же самое: где-то улучшится, где-то ухудшится.
Выигрыш в объеме невелик, зато и затраты в компиляторе мизерные. А так - здесь полкилобайтика сократили, там сократили, глядишь - в программе дописали новую возможность, а ее объем стал меньше, чем раньше. Очень приятно, и так год за годом ))
Наверное, потому, что в свое время Институт Радио активно использовал эту возможность PL/I. А когда появились первые IBM-PC/XT, они даже купили транслятор PL/I-86, чтобы быстро уйти с EC-ЭВМ, не переделывая программ. Но как раз этой возможности там и не оказалось (
я бы еще добавил "в учебных целях". На самом деле это частый случай. Результат дальше никуда не идет, но иногда это совершенно необходимая ступень для попыток создать реальный инструмент.
Например, вот список разрабочиков, неполный, конечно, но все-таки
Не понял. Зачем мне 64-разрядный компилятор? Результат его работы - да, 64-разрядные ELF-файлы. Но самого-то зачем его менять с 32-х разрядов? Ведь это как раз тот случай, когда "640к хватит на все" )) Размер таблиц компилятора в 10-20 Мбайт это уже "сверх границ". Другое дело - выполняемый файл. Например, сейчас нам нужно 14 Гбайт данных в памяти, иначе никак. Но для этого 32-х разрядный компилятор генерирует всего-то 2 Мбайта 64-х разрядных команд (кодов).
Так я же написал, что требуемое ПО (64-х разрядное) под Wine вообще не запускается. Например, не терпит в коде команды INT 3
Вы угадали. В прикладном ПО, перенос которого и является главной и конечной целью, видимо придется уходить на OpenGL. Но поскольку мы используем очень малую часть возможностей DirectX, надеюсь все пройдет легко.
На недоуменные вопросы отвечу так: я ничего не выбирал и ничего не устанавливал. Астру 5.15.0-70 установили на ноутбук китайцы на заводе в соответствии с договоренностью о продажах своих бытовых компьютеров в Россию. Кстати, при этом они перепутали Белоруссию с Россией и у меня теперь не "скачанные файлы", а "стягнутiыя файлы". Но мне это не мешает))
За советы установить не то, а это, искреннее спасибо, но есть области, где программист по своему желанию ничего установить не может. Например, как вы думаете, утвердит ли Роскосмос проектные документы на будущую станцию РОС, где будет написано:"ПО поддержки повседневной деятельности экипажа должно работать в среде Windows"? А ПО для какой ОС утвердит?
На том низком уровне, на котором я пытаюсь перенестить с одной ОС на другую, уже нет разницы между стулом и табуреткой. Как раньше я не чуствовал разницы для себя между Windows 7 и 10, так и сейчас не будет заметна разница между какой-нибудь Астрой и Альтом. Лишь бы GNU х86-64. Но пока доступ к DR0-7 - это головная боль, да.
Я писал о 1954 годе. А статья Колмогорова и Успенского - лето 1958 года, когда уже обсуждался будущий Алгол. Т.е. начиналась совсем другая эпоха. Что касается PL/1 и указателей в нем, то все-таки урежьте осетра, это был 1966 год, а не 1976. См., например, известную книгу "Мифический человеко-месяц", там история его применения для ОС/360 затрагивается.
Научный приоритет, вполне может быть и наш. У нас отличная математическая школа. А вот на практике, сомневаюсь, что разработчики PL/1 сами бы не пришли к подобному и вообще слышали о Колмогорове. Там были больше инженеры, а не ученые. Да и слишком все на поверхности.
Резюме. Я возражаю против исходного утверждения
Оно не отражает действительность. Да, вики несправедливо приписывает "изобретение" указателей Лоусону. Но несправедливо и утверждать, что без Колмогорова в PL/1 не появились бы указатели.
Позволю себе не согласиться. В 1954 году еще не было ни широкой программисткой общественности, ни потребности разрабатывать языки, ни потребности вводить в них указатели.
Это такое же преувеличение, как и утверждение, что PL/I появился только в 1976 году.
Но при этом, я не ставлю под сомнение способности отечественных теоретиков программирования.
Например, комитет по разработке подмножества "G" PL/1 выразил благодарность группе коллег за ценные советы и предложения. В этом списке три наших соотечественника, включая А. Ершова.
Others who made important contributions to this standard were:
Paul W. Abrahams
Kenneth Dritz
Andrei P. Ershov
A. Craig Franklin
Mimi Gerstell
Ev M. Greene
Richard Howells
L. Korneva
Peter Krupp
John Leffler
Howell A. (Skip) Richards
Gary Roberts
David Sahakian
W. Olin Sibert
Anthony P. Smith
Haruyuki Takeda
Richard Weaver
Сам себя поправлю. Не в 1967, а в 1968 году в Киеве проходило мероприятие:
На котором был доклад о моделировании на PL/I.
Интересно, что все ключевые слова переведены на русский. Но пока вместо file - "ТЕКА".
В конце резюме: все как у "алголоязыков", но новое - работа с указателями. В конце ссылки на статью Харольда нашего Лоусона "Обработка списков на PL/1" от июня 1967 года и на спецификацию языка от IBM от января 1966.
Можно считать, что с этого момента широкая советская программисткая общественность была ознакомлена с указателями.
Наверное, опечатка. Разработка PL/I началась в 1963 году. Первое публикование у нас - на Киевской конференции летом 1967 года.
Если была минута, а стало - 16, то да. А так, что Вы сделаете за 45 секунд? А ошибки как выдавались на экран, так и выдаются. По умолчанию после ошибки все останавливается и ждет нажатия клавиш. В том числе клавиши прекращения. Кроме этого, ошибка наверняка проявится на первом же варианте и остальные 15 уже можно не выполнять.
Потенциально увеличивается (меньше читать команд из памяти). А реально - да какая разница в каком регистре адрес, в RSI или в RBX?
Весь процесс распределения регистров x86 невозможно свести к фразе "раскрасьте граф". Если хотите погрузиться в волнующий мир распределения регистров - пробегите для начала вот это
А что мешает распараллеливать уже внутри вызова? Там же не сразу этот регистр требуется:
Ну и зря. В современных условиях стоимость обращения к памяти все время возрастает относительно времени выполнения команд.
Но многим кажется, что ладно данные, но уж следующие команды-то успеют скачаться, пока очередные скачанные команды выполняются. А это не факт. Поэтому уменьшение кода существенней влияет на быстродействие, чем раньше.
В данном случае, на мой взгляд, "щелевая" - это как анализировать, а "свертка" - это что делать. Команды ведь не выбрасываются, а лишь вкладываются друг в друга как матрешки.
Поскольку расположение кода относительно кэш-границ довольно-таки случайное, для объемных программ будет плюс-минус то же самое: где-то улучшится, где-то ухудшится.
Выигрыш в объеме невелик, зато и затраты в компиляторе мизерные. А так - здесь полкилобайтика сократили, там сократили, глядишь - в программе дописали новую возможность, а ее объем стал меньше, чем раньше. Очень приятно, и так год за годом ))
Согласен, но главный герой произносил именно так ))
Причем, чем глупее стишок, тем лучше запоминается. Со школы помню рад металлов, замещающих водород в кислотах. Только из-за стихотворного размера.
Натрий, калий, кальций, магний
Алюминий, цинк, железо,
Никель, олово, свинец.
Почти пирожок получился ))
Да, конечно. Но наука наплодила много других значков типа "аш с планкой". Прямо хоть вводи в юникод отдельное семейство "знаки научных формул" ((