Хакеры сновидений: Архив 1-6 - Lokky
Шрифт:
Интервал:
Закладка:
Окружающий мир, как видит его человек, очень близок к ООП, объектам и иже с ними, в то время как машинные коды и ассемблер близки к работе "напрямую" (читай видение, намерение), когда права уже не важны, но при ошибке в коде можно завалить всю программу и возможно всю Операционную систему.
С нашей точки зрения интересен полиморфизм и особенно возможность перегрузки методов (то есть фактически замена метода унаследованного от объекта предка своим методом, с тем же названием, но другим содержимым, или с тем же названием, но отличем в передаваемых параметрах илии их порядке). Возможно ещё менять уровень доступа к объектам, но с этим сложнее.
ps я не первый раз обдумываю об описании устройства мира с помощью языка программирования. Это может породить интересные идеи, но при желании их реализовать появляются проблемы: собственно как это сделать, практической части всега недостаточно.
С уважением, Ligth
nick
Тут, как мне кажется, все зависит от определений понятий.
Насколько я вижу, то, о чем ты говоришь, больше похоже на функциональное программирование, тоесть в твоей модели вся программа состоит из функций, через которые последовательно проходит поток исполнения. В этом случае началом отработки метода действительно будет точка входа. Но, как мне кажется, контактная точка - это то, что связывает два метода, вызывающий и вызываемый. В этом случае реально их будет связывать поток исполнения кода, а принимать решение о том, должны ли методы быть связаны, будет процессор на основании инструкций скомпилированного исходника и собственной архитектуры.
Тоесть, как мне кажется, "сущностью" связи между методами будет сумма текущего состояния данных в процессоре, инструкций, опять же загруженных в процессор, и архитектуры процессора. А "представлением" связи будет переход потока исполнения после соответствующего "решения" процесора.
Мне немного сложно рассуждать на этом уровне, так как у меня довольно приблизительные познания в низкоуровневом программировании, но думаю что дело обстоит примерно так.
Можно еще рассмотреть модель классов, где функции объединены в сущности более высокого уровня - классы. Здесь суть исполнения кода останется такой-же, но на уровне логики, которая в конце концов будет преобразована в те же инструкции процессора, добавятся процессы инициализации типов классов и их экземпляров перед вызовом собственно методов. Тоесть в некоторых случаях добавятся вызовы как бы скрытых методов инициализации высокоуровневой сущности, после которых будут вызваны собственно те методы, которые вызывались. Хотя для процессора никаких скрытых методов не будет, они будут скрытыми с точки зрения программиста.
Ligth
если смотреть с точки зрения кода, если программа записана на одном листе, то действительно, местом взаимодействия будут точки вызова функции/возврата из функций. В таком коде каждая строчка будет некоторой функцией, командой. Такой код есть машинный код. Или я не понимаю чего-то.
Masja
Nick, мне понравилась твоя фраза:
"сущностью" связи между методами будет сумма текущего состояния данных в процессоре, инструкций, опять же загруженных в процессор, и архитектуры процессора.
В магии это называется степень экзальтации, а в электричестве - проводимостью
nick
На мой взгляд, если мы хотим описать мир как программу, стоит определить основные действующие элементы. Насколько я вижу, такими элементами будут:
железо с определеной архитектурой
базовая низкоуровневая программа, управляющая железом (BIOS), которую, кстати, можно переписать программно
базовое "низкоуровневое программное поле" (операционная система, сторонние программы, интегрированные в операционную систему на низком уровне), в котором выполняются другие программы, и к которому выполняющаяся программа имеет лимитированный доступ
собственно код отдельной программы со своей логикой
электрический ток!
пользователь, как некий начальный импульс к запуску всего процесса и к запуску отдельный программ (могут быть разные пользователи)
Собственно же программа может быть представлена, как и сказал Ligth, в двух видах - бинарного кода, загруженного в память и частично в процессор, и описания этого кода - такого же бинарного (биты в файле, еще никуда не загруженные), либо в виде другого языка. Ligth, поправь меня, если я тебя не так понял.
Можно обратить внимание, кстати, на несколько интересных моментов:
разный программный код может давать один и тот же результат
теоретически, хотя крайне маловероятно, разные программы могут скомпилироваться в одинаковый код
сама компьютерная железка может быть виртуальной - тоесть все программы (в том числе операционная система) и пользователь будут думать что это компьютер, а на самом деле это хитрая программа, которая ведет себя как компьютер, и знает про это только админ
Masja, если я тебя правильно понял, в жизненном цикле классов, по крайней мере в случае языка Java, есть сходное понятие. В случае Java класс как сущность состоит на самом деле из трех сущностей:
описание логики класса (бинарный код) - "тип"
экземпляр типа класса - объект типа "Класс", существующий для каждого класса в единственном экземпляре (в рамках определенной части программы), собственно "класс", у которого уже доступны некоторые методы и поля (т.н. статические мемберы класса)
экземпляр класса - у него уже доступны нестатические мемберы, а также, что самое главное, экземпляров класса уже может быть множество, и все они будут связаны со своим "классом"
В этом случае, как мне кажется, "класс" соответствует этой самой степени экзальтации. Хотя может быть этому понятию соответствует не сам класс, а состояние класса, и состояние экземпляров класса.
Какая аналогия реала с программой? На мой взгляд, потоком исполнения будет собственно человек, причем именно человек как фокус, существующий "здесь и сейчас", а не человеческая жизнь. Переходами между методами могут быть переходы внимания из одной ситуации в другую. Причем часто я при этом действительно замечаю момент "оставления" старых данных в предыдущей области, и переход в новую область с каким-то минимальным набором необходимых данных (вызов метода с параметрами ), причем новая область, чаще всего, уже насыщена данными, оставленными от предыдущих посещений (состояние класса). Классы же можно ассоциировать с конкретными областями жизни человека, с его точки зрения, что кажется мне логичным, так как класс - несколько виртуальная структура, можно обойтись и без них.
Если подключить концепцию многопоточности - то под потоком модно представить отдельного человека. Что здесь интересно, что поток - понятие виртуальное. На самом деле физических потоков - столько сколько процессоров (не больше). А "логические" потоки формирует операционная система, выполняя их инструкции последовательно на одном процессоре. Есть над чем подумать
red_warg
Никого не хочу огорчать, но почему за основу взята фон Неймовская архитектура?
(т.к. знаю что есть и другие, но фоннеймовский вариант был более прост для того чтобы сделать ЭВМ в середине 20 века, сейчас же наблюдается тенденция к уходу от классичекой схемы)
Я согласен что теперешний комп может в некотором роде может отражать строения вселенной, но не буквально же.
nick
И вот еще интересный момент. Чтобы программа не была "вещью в себе", операционная система предоставляет ей API - интерфейс доступа к ресурсам операционной системы (набор специальных методов и/или классов). В то же время самой операционной системе и программам, запущенным в ней, доступны методы работы с "железом" - специальные регистры процессора, прерывания устройств и т.д. Причем операционная система имеет доступ к большему количеству таких методов (здесь я не совсем уверен, так что будет хорошо если кто-нибудь меня поправит).
Таким образом программа имеет возможность влиять на состояние системы в целом, и в то же время обеспечивается контроль над этим влиянием со стороны операционной системы.
red_warg, а почему, кстати, не буквально?
red_warg
Потому что, мир работает по-другому.
nick
А в чем принципиальная разница? Мне сравнение с компьютерной программой кажется вполне логичным.
lfxor
Некоторые особенности исполнения программ.
Рассмотрим программу, вычисляющую S из входных переменных a, b, e и f:
01 c = a+b
02 d = a-b
03 R = c*d
04 a = R*e
05 b = R*f
06 S = R+a+b
Программа простая. Ее особенность в том, что команды 01 и 02 могут исполняться в любом порядке или одновременно. На современных процессорах это так и произойдет - порядок исполнения будет определяться готовностью вычислительных устройств, а при надлежащем их количестве команды будут выполнены одновременно. Это же касается и команд 04 и 05. А команды 03 и 06 - "узловые" в том смысле, что исполняться одновременно с ними не может ни одна другая.