Разное

Спасибо большое!

Ну ты ж знаешь, я "семидесятник" :) (дитя семидесятых годов того века)
А деньги мы зарабатываем совсем иным способом.

>Model Tiny
>CodeSeg
Я только во flat и 32-битном режиме пишу... это еще при желании можно в деньги превратить... Все эти 16-битные режимы были актуальны 20 лет назад, сейчас 64-битные процессоры в этот режим даже не переключишь.

>т.е. вирусописатель из меня очень так себейный - тренироваться нужно будет, если такая задача встанет...

Model Tiny CodeSeg Org 100h Start: jmp Init Mess db ‘Время пришло!!!’,10,13,’$’ S_Time dw 1020h Init: mov ah,2Ch int 21h cmp cx,S_Time jne Init mov ah,9h lea dx,Mess int 21h mov ah,4Ch int 21h end Start

:)))

>PS Это важная технология, можно сказать истоки, но романтических чувств, как скажем C, ассемблер во мне не будит - не мое.

У нас с тобой с точностью до наоборот :) Он эти чувства будет во мне. В отличие от С.

Ну я себя великим системным программистом никогда не считал, да и ассемблер своей вотчиной пожалуй тоже. Я все-таки считаю ассемблер вымершей тенологией, из которой ушли все деньги, он нужен, но я бы на него не ставил. На ассемблере я программировал довольно поздно, и мои программы на нем - это набор вызовов библиотечных функций, т.е. вирусописатель из меня очень так себейный - тренироваться нужно будет, если такая задача встанет... но меня в свое время тоже интересовали схожие вопросы (да и сейчас интересуют, если честно) - откуда, что пошло и почему так, а не иначе. Это хорошие вопросы, ответы на них позволяют довольно далеко видеть вперед, ну или по крайней мере дают почти 100% ответы на вопросы, о том перспективна технология или лучше на неё не тратить времени.

PS Это важная технология, можно сказать истоки, но романтических чувств, как скажем C, ассемблер во мне не будит - не мое.

Игорь, гляжу за живое задела вас тема)) в некоторой степени я вас понимаю, это сродни новогодней елки в возрасте пяти лет)) "когда деревья были большими" и ассемблер казался вершиной программирования))
хотя мое общение с ассемблером было на уровне баловства... выдирал из игры (типа саботера) алгоритм бегущей строки, и еще пару тройку приблуд, но то время вспоминается с удовольствием)

Нолики и единицы переводятся в обычные числа, число расположенное в пределенной точке, сообщает, что это команда или набор данных. Когда вы видите if(!$f), вы знаете, что if - это команда, а $f - переменная, у машины тоже есть возможность это узнать. Вот с машинными кодами примерно тоже самое, одни коды определяют то, что следует за ними, если это не так - программа не работает. Вообще архитектура программ такова, что управляющий код и храниться совместно с данными. Именно на этом основана атака переполнени буфера - если у вас не проверяется размер вводимых данных, можно подобрать такую строку, что она перепишет управляющий код в программе и заставит изменить её логику, например, пустив вас на закрытый сервер. Номера команд вы без труда найдете на сайте Intel (или того, процессора который вам интересен, если вообще что-то осталось), можно и ссылки на книги привести, только писать в машинных кодах - это вообще уже ни в какие ворота, ну разве вы только вирус пишите, которые работают вне операционных систем. Если вам это интересно, лучше начните с ассемблера - любая книга (а их довольно много) вам откроет глаза в этот мир.

PS Я начинал отвечать с первого сообщения, поэтому это последний ответ, первый - в конце темы :)

>С высоким и низким уровнем языков более-менее понятно. А как машинные коды понимают
>операции? Т.е. как появляется управление машинным кодом? ? Может, я не правильно
>изъясняюсь, как появилось управление вкылом и выкылом?
Машинный код - это номер команды процессора, которую он должен выполнить, например один код отвечает за помещение значения в регистр (ячейка памяти процессора), другой номер отвечает за сложение значений двух ячеек и помещения результат в третий. Т.е. когда процессор встречает в потоке номер операции - он выполняет операцию с таким номером. Понятно, что в ячейках хранятся только целые числа, для сложения чисел с плавающей точкой нужен уже довольно сложный алгоритм (он реализован в железе в сопроцессоре), а по алгоритмам вычисления синуса раньше защищали диссертации, это сейчас мы вызываем его из библиотеки или сопроцессора, а вообще над его реализацией билось довольно много людей и у нас в стране и за рубежом.

PS Если хотите досконально разобраться, изучите ассемблер - это тяжело, но очень полезно, просто другими глазами будете смотреть на языки программирования и программы. Денег он, конечно, не принесет и с первого раза может не получиться его освоить на приличном уровне, но с точки зрения программирования понимание ассемблера дает очень много (никто еще не пожалел, что изучил ассемблер, даже не смотря на то, что им практически никто не пользуется).

Ну по большому счету нужно скидывать ссылку на несколько книг, так как и с вкл и выкл тоже не все гладко и просто. Изначально были машинные коды, т.е. адреса ячеек памяти и номера команд, которые оперировали содержимым ячейки. Т.е. создали программу и её без компиляции и интерпретации процессор сразу понимает. Затем создали ассемблер, заменив машинные коды мнемониками, стало проще, но все-равно для каждого из процессоров нужно было переписывать программу, так как команды у разных процессоров отличаются. В связи с этим стали появляться компиляторы, т.е. программы, которые преобразовывали текст языка высокого уровня в машинные коды или ассемблер. Т.е. программы стало возможным откомпилировать для разных процессоров, в том числе которые появятся в будущем. Компьютеры главным образом нужны были ученым, поэтому одним из первых языков высокого уровня был FORTRAN, который был заточен для программирования мат.формул. Это был первый язык, похожий на английский и не требовавший для программирования знания осообенностей данной конкретной машины. Вообще говоря, влияние процессора и ассемблера оставалось очень высоким, поэтому языки высокого уровня повторяли логику команд распространенных процессоров. If, goto, циклы, ветвление – это все навеяно ассемблером. Языки высокого уровня прижились, достаточно было разработать компилятор и груда ПО становилась доступна для новой платформы. В районе 1970 года этот прием был применен для создания операционной системы UNIX, а языком высокого уровня был С – первый язык высокого уровня для системного программирования. То что вы видите в современных языках – шлифовалось десятилетиями, удачные конструкции развивались, неудачные отбрасывались. Первые языки были тем еще зоопарком. Годы спустя языки вышли на еще более абстрактный уровень – ООП, понятно, что круто разработать язык для определенной проблемы, который бы оперировал понятиями данной проблемной области. Однако это очень дорого. Поэтому ввели ООП-языки, которые позволяли для каждой проблемной области разработать свой мини-язык программирования, оперирующий понятиями этой области. Сейчас мы находимся в такой точке, что время программистов стоит дороже времени машин и самих машин. Поэтому большое распространение получили интерпретаторы и языки пятого поколения (внедряющие в синтаксис довольно продвинутые алгоритмы, которые раньше нужно было реализовывать самостоятельно).

PS Если что-то не понятно, уточняйте период, который интересует – в него можно еще более углубиться. Пощупать руками можно почти любой, с машинными кодами будет труднее, но на ассемблере можно и сейчас создавать программы, в том числе и Windows (это дорого и не выгодно, но можно).
PPS Если кратко - сначала команды определялись архитектурой компьютера (if, for), затем потребностями разработчиков (class, try).