OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 21 Август, 2019 13:06

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 169 ]  На страницу Пред.  1, 2, 3, 4, 5, 6 ... 9  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 18:45 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Как Вы будете модуль с этой функцией раздельно компилировать, если Вы не знаете типов размеров элементов этого списка?
Ну как-то же компилирую! :о)
В принципе, в чём проблема-то? Ну не знаете Вы размеры элементов этих типов, и что с того? Зато Вы знаете, какие операции к ним можно применять, а это главное...
А если уж там эти элементы хранятся пусть даже в виде ссылок, ведущих в кучу, ну что ж, в худшем случае это приведёт к некоторому уменьшению быстродействия из-за косвенной адресации и более частых промахов в кешах...
В лучшем же случае программа хранится в некоем абстрактном представлении и переводится в конкретный тип во время линковки. Можно даже придумать что-то типа JIT-компиляции во время вызова функции, когда уже всё известно о характеристиках этих элементов...

Так в чём проблема-то?

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

Илья Ермаков писал(а):
Вот-вот, я уже не раз говорил, что Хаскелл - это С++ для функциональщиков И аргумент "Hello world написать очень просто", между прочим, не катит Если язык позволяет такие навороты и сферических коней, какие я видел у Душкина, то с этим языком что-то не то..
Не знаю, книгу Душкина я не видел. А Вы не могли бы как-нить её просканировать, да в виде DjVu, например, выложить для служебного пользования?
Душкин, кстатит, сейчас работает над второй книгой. Я видел начало этой книги -- вроде вполне адекватно, никаких наваротов...

Кстати, сравнение с С++ мне кажется глубоко неверным. Лучше сравнивать, ну например, с Адой. Хотя стандартный Хаскелл-98 гораздо компактнее и Ады и С++...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 18:46 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
merk писал(а):
такая функция не может быть раздельно скомпилирована. это просто шаблон функции. ее актуализация будет неявно генериться при компиляции того модуля, где ее используют.
Совершенно неверно! Это всё равно, что утверждать, что в С++ якобы невозможно ООП, так как непонятно как компилировать таблицы виртуальных методов...

В Хаскелле полиморфные функции, а не шаблоны. (Хотя есть ещё и Template Haskell, в котором можно и шаблоны делать, но это расширение, которого я сейчас касаться не буду...)
Один из вариантов полиморфных функции в Хаскелле таков -- полиморфные функции включает в себя неявный параметр, в котором находятся ссылки на таблицы виртуальных методов классов типов, которые используются в теле этой функции.

Но даже если взять и вариант, в котором полиморфные (как и любые другие) функции будут до стадии линковки/загрузки модулей находиться в виде некоего АСТ или в виде байт-кода, например, то что тут такого нехорошего, непонятно? Почему это хуже, чем хранить в виде машинного кода x86, скажите на милость? Да будет Вам известно, JIT-технология позволяет генерировать более качественный код, чем статическая кодогенерация...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 19:34 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Да будет Вам известно, JIT-технология позволяет генерировать более качественный код, чем статическая кодогенерация...

что значит более качественная? JIT это просто кодогенерация непосредственно перед исполнением. для компилируемого куска кода все равно что компилировать из промежуточного представления после первого прохода компилятора.
единственно что позволяет - не компилировать куски, что еще не вызывались. но если их вызовут - придется компилировать, впрочем это зависит от стратегии.
ну может более качественно - по размеру кода, это если не учитывать самого jit компилятора и наличия байт-кода с доп инфой для jit компиляции.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 19:52 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
merk писал(а):
что значит более качественная? JIT это просто кодогенерация непосредственно перед исполнением. для компилируемого куска кода все равно что компилировать из промежуточного представления после первого прохода компилятора.
Во время JIT-трансляции известны характеристики процессора и других деталей целевого компьютера. Это позволяет выбирать наиболее оптимальные наборы команд.
При статической же кодогенерации Вы будете ограничены некими стандартными наборами команд.
Так же JIT-кодогенератор может учитывать размеры кешев, например.

В совокупности, это позволяет получить более эффективный код, чем при статической кодогенерации...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 20:27 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Geniepro писал(а):
Да будет Вам известно, JIT-технология позволяет генерировать более качественный код, чем статическая кодогенерация...

Я-то знаю :-) Только знаю, что пока в полной мере JIT не реализован почти нигде, а где реализован - там ещё уйма нерешённых проблем. А в смысле "здесь и сейчас" имеются названные проблемы. Т.е. автовывод типов - не за просто так. А требует определённой поддержки-цены. Речь не про сам этот автовывод (да пребудет мир с ним и с его дедушками до седьмого колена :-) ), а про елейную манеру ФП-шников подавать все свои "конфеты" как дармовые и удивляться: "А почему ж вы не хотите то и это, ведь это так же, как и у вас, но гораздо круче, и всё за просто так" :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 20:40 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
А требует определённой поддержки-цены.
Ну так ведь всё требует какой-то цены. Пресловутая правильность оберон-технологии тоже требует цены, и немалой. Не говорю уже о потере удобств типа foreach...
Вот взять повторное использование кода на основе обобщённых или полиморфных процедур/функций. Отсутствие этого в Оберонах приводит либо к отказу от этого повторного использования и многократного ручного написания однотипных процедур, отличающихся только мелочами вроде типов входных параметров, при этом появляется серьёзная опасность в виде многочисленных ошибок, да и просто потеря драгоценного времени высокооплачиваемых программистов...
Либо приходится использовать тайные знания о метаинформации обероновского рантайма (которая ещё небось и не в каждой реализации Оберонов имеется) и плясать с бубном, пытаясь вручную сделать то, что давно уже автоматизировано и надёжно реализовано в боле высокоуровневых языках, не говорю уже про Хаскелл, а хотя бы в той же Аде с её дженериками...

Вот Вам цена простоты Оберона. Хорошо ещё, если эта простота не будет хуже воровства для Вас лично, а вот для многих других -- именно что хуже... ;о)

Илья Ермаков писал(а):
Речь не про сам этот автовывод (да пребудет мир с ним и с его дедушками до седьмого колена :-) ), а про елейную манеру ФП-шников подавать все свои "конфеты" как дармовые и удивляться: "А почему ж вы не хотите то и это, ведь это так же, как и у вас, но гораздо круче, и всё за просто так" :-)
Ну так тоже самое делают и оберонщики, чем мы хуже вас? 8-о :о))
Это называется пиар, господа! :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 20:45 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Geniepro писал(а):
Не знаю, книгу Душкина я не видел. А Вы не могли бы как-нить её просканировать, да в виде DjVu, например, выложить для служебного пользования?

Да я бы и рад, но там 550 страниц + мягкий корешок: сканировать мучение, да плюс рассыпется.

Цитата:
Душкин, кстатит, сейчас работает над второй книгой. Я видел начало этой книги -- вроде вполне адекватно, никаких наваротов...

Ага, не только талмуды аля Страуструп писать, нужно ж и "Бархатный путь" пытаться накатать :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 20:53 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Geniepro писал(а):
Вот взять повторное использование кода на основе обобщённых или полиморфных процедур/функций. Отсутствие этого в Оберонах приводит либо к отказу от этого повторного использования и многократного ручного написания однотипных процедур, отличающихся только мелочами вроде типов входных параметров, при этом появляется серьёзная опасность в виде многочисленных ошибок, да и просто потеря драгоценного времени высокооплачиваемых программистов...

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 20:57 

Зарегистрирован: Вторник, 01 Январь, 2008 16:19
Сообщения: 35
Цитата:
Так же JIT-кодогенератор может учитывать размеры кешев, например.

если речь идет о кешах процессора, то их всегда не хватает. 8)
ориентироваться на размер кеша можно только в предположении, что процедура работает монопольно и долго. в противном случае кеш забит потусторонними процессами, вызовами других функций, работой прерываний и самой ос.
как тут можно учесть размер кеша?
кто-то из джиткомпиляторщиков пишет, что может учесть кеши процессора???
где это?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 21:09 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Geniepro писал(а):
Вот взять повторное использование кода на основе обобщённых или полиморфных процедур/функций. Отсутствие этого в Оберонах приводит либо к отказу от этого повторного использования и многократного ручного написания однотипных процедур, отличающихся только мелочами вроде типов входных параметров, при этом появляется серьёзная опасность в виде многочисленных ошибок, да и просто потеря драгоценного времени высокооплачиваемых программистов...


Вспоминается мой собственный опыт с "обощёнкой". Когда четыре года назад начал использовать С++, то был в восторге от того, как шаблоны позволили сократить объём кода в несколько раз по сравнению с Дельфи (там были около БД-шные задачи). Шаблоны были, пожалуй, основным для меня достоинством С++ (т.к. оборотную сторону "свободы красиво нанизывать..." я понял весьма скоро).
Но вот как-то уже два года в Обероне обхожусь без них превосходно. А тот спектр задач, который тогда решал на шаблонах, лучше и гибче решается тут на метапрограммировании.

О стандартных контейнерах иногда жалеешь, но у них есть обратная сторона: начинают использовать без понимания особенностей работы и получают дикий оверхед... Если учесть, что для повседневки часто достаточно обычных линейных списков, линейного поиска и простой сортировки вставками (вспоминается опыт Вирта по замене в компиляторе двоичных деревьев на лин. списки). А когда нужно иное, то результат написания с учётом специфики задачи часто гораздо лучше, чем у типовых контейнеров (либо у контейнеров быстро возникают тонкие параметризации, кучи версий и наворотов, со всем сопутствующим, ну, STL у всех перед глазами). Ну а упомянутая сборка мусора сильно облегчает всё енто, позволяя строить сколь угодно динамические структуры без запарки по поводу владения...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 21:22 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
но зато иногда более продуктивно в том смысле, что это динамический механизм, со всеми вытекающими
А вот это, кстати, весьма интересный вопрос, что из этого вытекает.


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

Но ценою меньшей гибкости и удобством работы (конкретно в Обероне).


С другой стороны Вы всё более настойчиво предлагаете использовать малодокументированные и непереносимые возможности "обероновского метапрограммирования", которое являетя по сути динамической типизацией "со всеми вытекающими".

А вытекает отсюда повышенная гибкость манипулирования объектами программы, ценой которой является также и повышенное количество ошибок, выявляемых только во время тестирования, да и то далеко не всегда...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 21:23 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
merk писал(а):
как тут можно учесть размер кеша?
кто-то из джиткомпиляторщиков пишет, что может учесть кеши процессора???
где это?
Ну, это скорее моё предположение, что это могло бы быть полезным...

А вообще, учёт размера кеша может быть полезен, например, при настройке параметров сборщика мусора, что бы первое поколение объектов максимально полезно заполняло кеш без его переполнения... Но тут связи с JIT вобщем-то нет...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 21:27 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Вспоминается мой собственный опыт с "обощёнкой". Когда четыре года назад начал использовать С++, то был в восторге от того, как шаблоны позволили сократить объём кода в несколько раз по сравнению с Дельфи (там были около БД-шные задачи). Шаблоны были, пожалуй, основным для меня достоинством С++ (т.к. оборотную сторону "свободы красиво нанизывать..." я понял весьма скоро).
Но вот как-то уже два года в Обероне обхожусь без них превосходно. А тот спектр задач, который тогда решал на шаблонах, лучше и гибче решается тут на метапрограммировании.
Хотелось бы повторить слова vlad'а -- зря Вы судите об "обобщёнке" по шаблонам С++. Это может быть не так ужасно... ;о)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 21:29 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Предлагаю вернутся к теме и рассмотреть следущую задачу (конкретную и текущую :) ): необходимо считывать из таблицы БД, размещенной на сервере, некоторую информацию и отображать ее на выносной панели индикации. Проблема усугубляется тем, в случае возникновения каких либо нештатных ситуаций никто ничего делать не будет, там даже не будет клавиатуры. В крайнем случае охранник позвонит в службу поддержки.
Но для тривиальных случаев (например перзагрузили машину на которой сервер БД) необходимо сделать две вещи:
1. Отобразить текущее состояние
2. Попытаться восстановить соединение с БД
При этом недопустимы ни какие трапы, системные сообщения, т.е. ничего что требует каких либо манипуляций.
В delphi я примерно представляю как это сделать, а как это будет выглядеть в BlackBox?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 21:32 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
т.к. оборотную сторону "свободы красиво нанизывать..." я понял весьма скоро
Этот момент я упустил...
А что там в С++ можно так "свободно и красиво нанизывать", не подскажете? ;о)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 22:48 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Geniepro писал(а):
Илья Ермаков писал(а):
но зато иногда более продуктивно в том смысле, что это динамический механизм, со всеми вытекающими

А вот это, кстати, весьма интересный вопрос, что из этого вытекает.

Из этого вытекает, что вся "обобщённость" шаблонов заканчивается после того, как отработал последний проход компилятора.... А вот с метапрограммированием только начинается и как раз самое интересное :-)

Да, "динамическая типизация", если хотите. На архитектурном уровне у неё очень много плюсов. В том и прелесть Оберонов, что когда я захочу, я буду иметь всю динамическую типизацию и сколь угодно динамическое связывание (на уровне того же Smalltalk-а, вплоть до полной его эмуляции), а на уровне обычного кода все прелести статических проверок... (за исключением абстрактной атомарной типизации аля Ада, но этот вопрос уже много мусолился - такова цена расширяемости. Иначе был бы лишний пучок тонких проблем).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 23:03 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Geniepro писал(а):
Этот момент я упустил...
А что там в С++ можно так "свободно и красиво нанизывать", не подскажете? ;о)


Ну, когда тогда начал изучать - то много чего показалось :-) Бусинки разные и перья в одно место, як у папуасов, как тут недавно на КД Info21 сказал (правда, его быстро отмодерировали...). Было, типа, круто :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Январь, 2008 23:13 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Axcel писал(а):
Проблема усугубляется тем, в случае возникновения каких либо нештатных ситуаций никто ничего делать не будет, там даже не будет клавиатуры. В крайнем случае охранник позвонит в службу поддержки.
...
В delphi я примерно представляю как это сделать, а как это будет выглядеть в BlackBox?


Так Вы сначала определитесь, какие могут быть "нештатные ситуации".
Первого вида - ошибки в вашей программе. Оберон-идеология - немедленное прерывание текущей, так скажем, задачи. Для интерактивных приложений, на которые в первую очередь ориентирована среда, текущий вариант - показ трепа и ожидание дальнейших действий пользователя. Для встроенного приложения сценарий не совсем подходит, ну, я бы подправил пару строк в базовом обработчике исключений в Kernel, дабы не было никаких трепов, а происходили какие-то действия по перезапуску (и ничего плохого в данном случае нет, т.к. custom-задача может потребовать custom-изменений в среде, это же не массовое и не открытое приложение).

А "нормальные нештатные" обработал бы, как вкратце рассказывал выше. Всё окружение (типа БД и т.п.), как полагается, покрыто набором абстракций, в терминах которых написана основная часть приложения. Эта часть не подозревает, что под ней какая-то ненадёжная среда. А далее определяются все возможные нештатные ситуации с отключениями БД и т.п., в слое абстракций делаются разъёмы для инсталляции обработчиков. А выше в приложении описываются обработчики. При попытке обратиться к базе данных и её недоступности не происходит возврата управления основному коду и не происходит трепа, а вызывается обработчик, который разбирает ситуацию, пытается исправить ситуацию и указать технич. слою, что сделать (попробовать ещё раз, или укажет запасной сервер ну и т.п. - по логике вашего приложения). Если ситуация исправлена, то в итоге основной код получит нормальный результат как ни в чём не бывало. Ну а если не вышло - то идут особые действия, типа показа сообщения об ошибке и невозможности дальнейшей работы, пока не будет устранено то-то и то-то, ну и т.п.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Январь, 2008 00:48 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Цитата:
Так Вы сначала определитесь, какие могут быть "нештатные ситуации".

Ну предположим я определился: нештатная ситуация - потеря соединения с БД, а мои действия - вывод на статус-строку текущее состояние подключения к БД и попытка восстановления соединения с БД (периодически). Вопрос: как задавить системные реакции? В Delphi для этого есть try ... exсept ... end, а как в BB "задавить" трап? Редактировать Kernel?
Цитата:
А далее определяются все возможные нештатные ситуации с отключениями БД и т.п., в слое абстракций делаются разъёмы для инсталляции обработчиков. А выше в приложении описываются обработчики

Не совсем понятно в каком слое абстракции?, в подсистеме SQL? Или в своей подсистеме? В Delphi я делаю обработку после except и при этом мне не нужно думать ни о каких разъемах.
Цитата:
Эта часть не подозревает, что под ней какая-то ненадёжная среда

Вот тут я уже не согласен концептуально. Мне кажется это не верный подход "не подозревать" . Среда такая, какая есть и полное решение задачи состоит в том, чтобы каким-то образом сработать в любом случае. А так получается искусственное разбиение единой задачи.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Январь, 2008 01:14 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Axcel писал(а):
Не совсем понятно в каком слое абстракции?, в подсистеме SQL? Или в своей подсистеме? В Delphi я делаю обработку после except и при этом мне не нужно думать ни о каких разъемах.


Потому что в Delphi Вам возвращается исключение... А в подсистеме Sql, насколько я помню, для этого служат коды ошибок (поля res объектов Database и Table). Трепы при потере соединения не генерируются. Ну так и пользуйтесь либо кодами ошибок, либо оборачивайте в свой слой, имитирующий безошибочность, а ошибки посылающий по боковым разъёмам...

Цитата:
Вот тут я уже не согласен концептуально. Мне кажется это не верный подход "не подозревать" . Среда такая, какая есть и полное решение задачи состоит в том, чтобы каким-то образом сработать в любом случае. А так получается искусственное разбиение единой задачи.

Так не Вы "не подозреать", а код, отвечающий за основную логику приложения "не подозревать" :-)
Просто повышение уровня, абстрагирование.
Между прочим, при обращении по указателю где-то глубоко внизу под Вами может возникнуть ошибка доступа к странице. И вместо выполнения инструкции из Вашей программы сначала управление будет передано на спец. обработчик спец. прерывания, который достанет эту страницу из файла подкачки. А потом Ваша инструкция выполнится как ни в чём бывало. И Ваша программа ни о чём таком и не подозревает. Потому что абстрагирована механизмом виртуальной памяти, который повышает гарантии (усиливает постусловия) относительно базового аппаратного урвоня....


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 169 ]  На страницу Пред.  1, 2, 3, 4, 5, 6 ... 9  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB