В последнее время стал замечать, что проблема искусственного интеллекта(далее ИИ) все сильнее и сильнее будоражит умы людей планеты Земля. Первые мысли на эту тематику стали появляться достаточно давно - вспомнить хотя бы великолепнейший фильм "Терминатор"и не менее великолепнейшего "Робокопа"(часто именуемого Рыбокопом). Целая масса футуристических произведений вылилась(и до сих пор выливается) на прилавки магазинов о неких роботах которые обладают разумом подобному человеческому, при этом обладающим пуленепробиваемыми частями тела, умеют летать, телепортироваться, разговаривать на китайском и прочими неимоверными способностями о которых человек всегда мечтал - вот такое вот чудо на колесах изобретает ум людской дабы преклонить перед своими ногами все тихо-мирно живущее население нашей одной единственной и неповторимой планеты Земля. Конечно же с самого начала никто и не думал применять сие гениальнейшее изобретение во вред всему живому и не живому... кроме одного профессора-шизойда который за то, что его сосед в детстве не предусмотрительно назвал "ботанегом" решил испепелить всю нашу обитель, дабы неповадно другим было умного, интеллигентного и воспитанного человека так оскорблять. Затаив глубокую обиду наш "дарт-вёдер" чуть-чуть меняет гравитационное поле земли моск надежды всего человечества и надежда превращается в ночной кошмар. Или же, по некоторым источникам, надежда в силу силы своей воли превращается в кошмарег самого дьявола. На такую вот захоХулину обычно и тратят плёнки режиссеры и вырубают леса дровосеки. В общем-целом конечно же не сказать, что абсолютно бесполезно - попадаются весьма впечатляющие экземпляры. Однако же более интересным мне кажется тот факт, что некоторые люди вполне себе серьезно верят в такую вот мрачную "перспективу", и часто занимаются выдуванием из мухи целого слона(с ушами). С одной стороны отрицать возможность такого весьма печального, и обрекающим на нет все иллюзии человечества по поводу светлого коммунистического будущего нельзя - ибо как говорится "погоду на завтра мы узнаем послезавтра". А пока можно с большой долей вероятности утверждать, что зеленые железные человечки не попадут на прилавки городов как минимум ближайшие лет 40-50(ну во всяком случае я на это надеюсь), а если говорить про терминаторов с человеческим разумом то тем вообще на порядок больше времени потребуется. Да и не факт, что оные вообще выйдут из под контроля правителей мира сего - у мафии длинные руки. Странным мне кажется еще и то, что "тесты" для определения достиг ли ИИ уровня человеческого появились до того как человек сам понял, как охарактеризовать/определить то чем наделила его природа - это, имхо, весьма весомый аргумент против того, что такой "самопал" когда либы сЫмиеет место быть. Самый известный из этих тестов - это тест Тьюринга. Объективность этого теста вопрос спорный и требует не малого количества пива. Так, что этот вопрос трогать не будем, вместо этого будем верить, что это всего лишь бурная(доморощенная) фантазия писателей(народных умельцев(с)) и исчо одно "предсказание" Ванги которому не суждено сбыться...
- Location:патцтолом
Недавно передо мной встала одна проблема. Появилась она в следствии того, что в какой то момент я осознал, что алгоритмически оптимизировать функции классов векторов, матриц и кватернионов больше не куда, а хочется. Основную проблему здесь конечно представляют операции над матрицами. Хотя и не планировалось использовать последних как основной инструмент для произведения модельных/видовых преобразований(для этого лучше использовать кватернионы - и быстрее и удобнее), но полного их изъятия из кода произвести, к сожалению, нельзя по как минимум одной простой причине - сам OpenGL работает с матрицами. Да и мало ли пригодятся при решении всяких задачек по линейной алгебре :)... В общем решил я взяться за ассемблер. План был следующий - на асме пишу отдельные модули, а дальше дело линкера. Вопроса о выборе между тем писать ли asm-процедуры на встроенном ассемблере или же в отдельных модулях не стоял ибо от приложения требуется полная переносимость а перспектива переписывания оных в двух вариантах(AT&T и Intel синтаксисах) меня нисколько не устраивало. Взяв на вооружение nasm(Netwide assembler) я принялся к испытаниям на "реальных" условиях - Ubuntu со своим gcc и XP с msvc. К сожалению третьей ос (MacOS X) под которую планируется так же пустить приложение в наличии нету, однако я надеюсь, что и там все будет как по маслу ибо ядро иённоё сродни всем *nix'ам. Надо сказать, что испытания прошли практически безболезненно. Единственное, что необходимо было сделать, так это написать один макрос, буквально в несколько строчек, который очень хорошо выручает:
+=============+
%include "c32.mac"
%macro cglobal 1
global _%1
%define %1 _%1
%endmacro
%macro cextern 1
extern _%1
%define %1 _%1
%endmacro
+=============+
(к нему нужен с32.mac)
Необходимость в этом макросе возникает потому, что господа из microsoft и GNU как всегда что-то не поделили - первые в обязательном порядке требуют наличия символа "_"(вот такой вот у них формат) перед любой функцией и переменной написанной на ассемблере а вторым как всегда пофег... то есть, под Win32 платформой нужен макрос написанный выше, для сборки в elf формат(то-бишь платформа linux) в нем(макросе), необходимо избавится от всего кроме первой строки, и вписать две строчки. В итоге:
+=============+
%include "c32.mac"
%define cglobal global
%define cextern extern
+=============+
Как следствие в обоих случаях в C++ мы должны обращаться к функции без подчеркивания, то есть с тем именем которым мы ее наделили в асме. Для пущей наглядности:
+=============+
%include "my.mac" ;
cglobal someFunc ; макрос cglobal который обращается к global описанному в c32.mac
proc someFunc
%$arg1 arg
%$arg2 arg
;...тело функции
endproc
+=============+
Из С++ вызываем так:
+=============+
extern "C" void someFunc(int a, int b);
...
...someFunc(i, j);...
+=============+
Да, и конечно нужно подключать сам объектник нужного(который требует компилятор) формата. Вот вобщем то и усё. Немного... зато избавляет от огромного множества проблем связанных с переносимостью кода. По большому счету ключевую роль в решении этой проблемы сыграл nasm - один из немногих действительно кроссплатформенных ассемблеров с простым но весьма полезным препроцессором. Еще один известный мне - fasm(Flat Assembler). Он, к слову, обладает более мощным препроцессором в отличии от nasm'а, но это уже дело пятое.
+=============+
%include "c32.mac"
%macro cglobal 1
global _%1
%define %1 _%1
%endmacro
%macro cextern 1
extern _%1
%define %1 _%1
%endmacro
+=============+
(к нему нужен с32.mac)
Необходимость в этом макросе возникает потому, что господа из microsoft и GNU как всегда что-то не поделили - первые в обязательном порядке требуют наличия символа "_"(вот такой вот у них формат) перед любой функцией и переменной написанной на ассемблере а вторым как всегда пофег... то есть, под Win32 платформой нужен макрос написанный выше, для сборки в elf формат(то-бишь платформа linux) в нем(макросе), необходимо избавится от всего кроме первой строки, и вписать две строчки. В итоге:
+=============+
%include "c32.mac"
%define cglobal global
%define cextern extern
+=============+
Как следствие в обоих случаях в C++ мы должны обращаться к функции без подчеркивания, то есть с тем именем которым мы ее наделили в асме. Для пущей наглядности:
+=============+
%include "my.mac" ;
cglobal someFunc ; макрос cglobal который обращается к global описанному в c32.mac
proc someFunc
%$arg1 arg
%$arg2 arg
;...тело функции
endproc
+=============+
Из С++ вызываем так:
+=============+
extern "C" void someFunc(int a, int b);
...
...someFunc(i, j);...
+=============+
Да, и конечно нужно подключать сам объектник нужного(который требует компилятор) формата. Вот вобщем то и усё. Немного... зато избавляет от огромного множества проблем связанных с переносимостью кода. По большому счету ключевую роль в решении этой проблемы сыграл nasm - один из немногих действительно кроссплатформенных ассемблеров с простым но весьма полезным препроцессором. Еще один известный мне - fasm(Flat Assembler). Он, к слову, обладает более мощным препроцессором в отличии от nasm'а, но это уже дело пятое.
- EPIлог
- CONтент
www.demoscene.ru
the end.
- PROлог
