Центр информации по операционным системам: Форумы / ОС-21 / Заглядывая в туманное будущее

Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21		<< Предыдущая тема \| Следующая тема >>
Заглядывая в туманное будущее - обсуждение

Переход на страницу 1 2 3 4 [5] 6 ... 13 14 15
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

Vadim Ushakov

Воскресенье 04.09.2005 04:21

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

batu написал(а) ...
Очень благодарен за ответ, но, к сожалению, не на мой вопрос. Здесь выполняется операция с известным при трансляции типом. А вопрос был задан какой код генерировать если тип данных (или объекта) станет известным только в момент выполнения.

Щаз ругаться буду

Это по вашему что:
BaseObject *obj1 = new A1(), *obj2 = new A1();
Объекты объявлены как BaseObject - точный тип становится известен только на этапе выполнения. Если я напишу:
BaseObject Foo(const BaseObject& obj1, const BaseObject& obj2){
return obj1 + obj2;
}
то так будет понятнее?
Тут даже спорить не о чем. Что вы спрашивали - на то я и ответил.

batu написал(а) ...
Sub EE (J As Integer)
I As Integer=0
J=I+J
End Sub
Ну, не знаем мы есть ли значение в J на этапе трансляции. И проверить это можно только на этапе выполнения.

На этапе трансляции нам известно, что тип J есть Integer, т.е. нам известна область значений, которые может принимать переменная, и операции, в которых он а может участвовать.
Извините, но "не знаем мы есть ли значение в J на этапе трансляции" - это чушь. Конкретное значение переменной мы не знаем. Но КАКОЕ-ТО ЗНАЧЕНИЕ БЕЗУСЛОВНО ЕСТЬ. Если есть объект - есть и его значение. Не бывает неинициализированных объектов. Ведь если объект не инициализирован - это значит, что его еще не существует, есть только место в памяти, содержащее мусор. А высокоуровневый язык программирования (такой, например, как Visual Basic - вы ведь приводите basic-подобный код) не позволит ссылаться на мусор и производить с ним какие-то операции.

batu написал(а) ...
Но проблемы с указателем тоже могут возникнуть в таких случаях если объект создавался динамически и уничтожен. И страничной защиты в таком случае мало.

Я приводил примеры на Си++... Ладно, представьте ту же программу на Java. И скажите мне, КАК вы сумеете уничтожить объект и сохранить где-то указатель на то место, которое было этим объектом, когда он был жив. Не получается? Автоматическая сборка мусора - вот как это называется. Извините, но как я уже писал, проблема высосана из пальца. Указатель всегда содержит либо ссылку на корректный объект, либо null. Обращения к null отлавливаются страничной защитой.

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

captain cobalt

Воскресенье 04.09.2005 06:40

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

batu написал(а) ...
Машинные команды бывают одно- двух- и трех-операндные.
Структура команд при этом следующая:
Для однооперандных команд
КОМАНДА| ОПЕРАТОР ИЛИ АДРЕС ОПЕРАНДА
Для двухоперандных команд
КОМАНДА| ОПЕРАТОР ПЕРВЫЙ ИЛИ АДРЕС ПЕРВОГО ОПЕРАНДА| ОПЕРАТОР ВТОРОЙ ИЛИ АДРЕС ВТОРОГО ОПЕРАНДА

Здесь упущен целый класс методов адресации - косвенная адресация - операнд расположен в памяти по адресу, содержащемуся в регистре.

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

Компилятор может генерировать корректный код с использованием косвеной адресации несмотря на то, что во время компиляции неизвестны значения используемых регистров.

Например, локальные переменные и параметры процедур традиционно размещаются на машинном стеке. Компилятор может адресовать их относительно регистра указателя стека, значение которого зависит от того, где ОС выделила стек и от предыдущих вызванных процедур.

Для манипуляции динамическими переменными также используется косвенная адресация. Адрес динамической переменной возвращается из процедуры NEW, то есть становится известен только при создании переменной.

С использованием косвеной адресации могут быть реализованы (и весьма эффективно) все рассмотренные выше ситуации когда нечто "неизвестно во время компиляции". Рекомендую выучить косвеную адресацию.

batu написал(а) ...
Например, память при выделении очищается, и при записи данных в ячейку устанвливатся аппаратно бит с признаком наличия данных. Таким образом, при обращении для чтения к отсутствующим данным возникает ошибка.

Не раскрыта политика манипулирования этим битом.

batu написал(а) ...
Программное решение этой проблемы гораздо сложнее, требует массу ресурсов, и я не знаю надежного решения (может вы в курсе?).

Поэтому можно предложить такую политику: потребовать, чтобы все адреса, по которым нет данных ("указатели, которые ни на что не указывают") были равны одному значению, и назвать его NIL.

Тогда проверка на наличие данных - это проверка указателя на NIL. Ну и далее по списку см. выше.

batu написал(а) ...
Dim I As Apple
I=I+1Я
Это пример из моего языка.

Какие значения и типы имеют следующие выражения:

1Я - 1Я
1Я + 1Я
1Я * 1Я
1Я / 1Я
1Я * 1Я + 1Я

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

batu

Вторник 06.09.2005 12:35

ID пользователя #5

Зарегистрирован: Суббота 03.07.2004 22:20
Местонахождение: Г Харьков
Сообщений: 22

Vadim Ushakov написал(а) ...

Щаз ругаться буду

Здесь я с вами согласен. Погорячился. Но, команды сгенерированые не нравятся. Все таки их слишком много (у тебя там чего-то не хватает, когда я дизасемблироват там выход на процедуру был) и встречаются часто . Поэтому и предлагаю оставить их машине.

Vadim Ushakov написал(а) ...

При такой архитектуре какое-то значение, конечно есть. Но в двоичноых кодах я не знаю что такое NULL. Вполне возможно, что это значение мусор. Принято (например в VB, что если значение не присвоено в Integer, то это 0 и.т.д.) считать что значение есть если оно не задано, но это не гарантирует от ошибок, и более того эти ошибки тяжело обнаруживаются.

Vadim Ushakov написал(а) ...
Я приводил примеры на Си++... Ладно, представьте ту же программу на Java. И скажите мне, КАК вы сумеете уничтожить объект и сохранить где-то указатель на то место, которое было этим объектом, когда он был жив. Не получается? Автоматическая сборка мусора - вот как это называется. Извините, но как я уже писал, проблема высосана из пальца. Указатель всегда содержит либо ссылку на корректный объект, либо null. Обращения к null отлавливаются страничной защитой.

Уничтожение объекта и освобождение памяти это разные вещи. Так что может существовать указатель, а объекта там нет. Например, уничтожить объект A можно так A=Nothing.
А дальше спокойно создавать новый объект A. Создание объекта и удаление выполняется операциями присваивания, а память выделяется операторами Dim A As Object, и как правило сохраняется за объектом на всей области определения переменной. (не все языки java).
Я б особенно не дергался. Все и так работает. Но, увы не так надежно и эффективно как хотелось бы.

Captain cobalt написал(а) ...
Здесь упущен целый класс методов адресации - косвенная адресация - операнд расположен в памяти по адресу, содержащемуся в регистре.

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

К этому можно много чего добавить. На СМ1-СМ2 старший бит говорил о том что данные находятся по адресу адреса. Или базовая адресация не ограничивается 3-мя уровнями, а может быть массивом. Это сути не меняет. Разве что усложняет. И не надо меня посылать учится методам адресации. Как минимум не вежливо по отношению к возрасту и опыту. Я таким как Вы на эту тему лекции читал в институте 15 лет назад. А вот примеры насчет операций с пользовательскими типами понравились. Сильно типизированые языки предполагают проверку типов. Так вот при определении операций необходимо не только определять функцию, но и тип результата операции. Так, например складывая длину 2метра+3 метра получаем тот же тип длина. А при перемножении 2метра*3 метра получим совсем другой тип площадь.

Наверх

captain cobalt

Вторник 06.09.2005 15:23

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

batu написал(а) ...
Так что может существовать указатель, а объекта там нет.

Зачем это нужно?

batu написал(а) ...
Например, уничтожить объект A можно так A=Nothing.
А дальше спокойно создавать новый объект A. Создание объекта и удаление выполняется операциями присваивания, а память выделяется операторами Dim A As Object, и как правило сохраняется за объектом на всей области определения переменной. (не все языки java).

Здесь следует тщательно различать value-типы и reference-типы.

Переменные value-типа содержат собственно данные.
Переменные reference-типа содержат ссылку на данные либо NIL; память необходимо вручную выделять с помощью NEW (а при отсутствии сборщика мусора освобождать также вручную).

Обычно типизированные языки предоставляют некоторое количество примитивных базовых элементарных типов, и некоторое количество конструкторов типов для построения более сложных типов из более простых.

Рассмотрим, например, язык Active Oberon.

В нем имеются такие конструкторы типов:
-- ARRAY
-- POINTER TO
-- RECORD
-- расширение записи
-- OBJECT

OBJECT - это reference-тип.
Все остальные - это value-типы.

Некоторое затруднение с reference-типами заключается в том, что для обращения к собственно ссылке и к данным по ссылке используется одно имя. При этом используется правило типа "если разыменование очевидно, то оно не пишется". Присваивание переменной reference-типа значения NIL или другой переменной reference-типа относится к ссылке, остальные операции относятся к данным по ссылке. Поскольку ссылка - это примитивный тип, а reference-типы обычно используются для составных типов, то неоднозначности разрешаются довольно очевидным образом.

А об объектах value или reference типа речь шла выше?

batu написал(а) ...
И не надо меня посылать учится методам адресации.

Тогда непонятны вопросы типа "как формировать адрес для объекта-параметра процедуры". Адрес формируется вполне однозначным и очевидным образом и способ его формирования зависит от:
-- value или reference тип имеет объект
-- конвенция вызова - как передаются параметры, через стек или регистры или ...

Косвеная адресация применяется и в машинных командах передачи управления : "косвеный переход" и "косвеный вызов подпрограммы". Поэтому на вопрос "какую операцию здесь применять" ответ - "использовать команду косвеной передачи управления".

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

captain cobalt

Вторник 06.09.2005 16:17

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

Также рекомендуется почитать книжку

Влиссидес - Применение шаблонов проектирования. Дополнительные штрихи. -- Издательский дом "Вильямс", 2003. -- 144 с.

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

Я до сих пор утверждаю, что приведённые выше примеры динамической типизации - это ошибка проектирования.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Vadim Ushakov

Четверг 08.09.2005 13:46

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

captain cobalt написал(а) ...
Я до сих пор утверждаю, что приведённые выше примеры динамической типизации - это ошибка проектирования.

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

В моем понимании процессор должен быть очень "тупым" и очень быстрым. А все средства для поддержки ЯВУ должна предоставлять программная run-time-среда, а не аппаратура. ИМХО, будущее за многопроцессорными системами, где каждый процессор не так уж умен, но зато ОЧЕНЬ производителен и таких процессоров в одной системе не просто много, а МНОГО.

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

captain cobalt

Четверг 08.09.2005 20:06

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

Vadim Ushakov написал(а) ...
А что касается языков с динамической типизацией... Это еще нужно доказать, что имеется технологическая потребность и необходимость использования таких языков. Во всяком случае, это не очевидно.

По этому поводу вот цитата из вышеупомянутой книги:

Джон Влиссидес написал(а) ...
Статическое задание типов во многих случаях помеха, а не преимущество, не могут же ошибаться 50 000 программистов, работающих на Smalltalk! Но чем более крупной и долгоживущей является система, тем более вероятно, что она выиграет от статической типизации.

Как известно динамическая имеется в языках Oberon, хотя очень многого другого там нет.

Известен способ, по которому фиксированная программная система использующая динамическую типизацию может быть автоматически эквивалентно преобразована так чтобы использовать только статическую. Но это плохо годится для систем Oberon и компания, которые не являются фиксированными. Наоборот, они являются расширяемыми - прямо во время работы к ним можно динамически компоновать модули. Видимо для расширяемых систем динамическая типизация имеет довольно существенное значение.

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

Vadim Ushakov написал(а) ...
И уж совсем нет никакой нужды выносить поддержку динамической типизации на аппаратный уровень.

Да.
Аналогично нет нужды выносить защиту памяти на аппаратный уровень.

Но снующие повсюду "крутые микроядерщики" и просто юниксоиды с этим не согласны и заявляют что якобы "в Bluebottle нет защиты памяти".

Видимо закалённые фанаты Эльбруса столь же категоричны насчёт аппаратной типизации.

Аппаратная защита памяти для поимки нулевых указателей используется в Bluebottle лишь потому что имеет нулевые накладные расходы при работе в штатном режиме.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Dron

Пятница 09.09.2005 09:51

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Защита памяти будет не нужна, когда сама архитектура от безтиповой перерастет в типизированную.

А пока все что вы здесь обсуждаете - лишь внешние наслоения над архитектурой, которая о типах вообще ничего не знает. (следовательно все типовые ограничения - могут быть обойдены!)

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

Андрей Валяев

Наверх

captain cobalt

Пятница 09.09.2005 11:15

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

Vadim Ushakov написал(а) ...
В моем понимании процессор должен быть очень "тупым" и очень быстрым. А все средства для поддержки ЯВУ должна предоставлять программная run-time-среда, а не аппаратура. ИМХО, будущее за многопроцессорными системами, где каждый процессор не так уж умен, но зато ОЧЕНЬ производителен и таких процессоров в одной системе не просто много, а МНОГО.

Осталось выбрать подходящую ОС.

Как насчёт EPIC/VLIW машин? Pефал-машин?

Dron написал(а) ...
Защита памяти будет не нужна, когда сама архитектура от безтиповой перерастет в типизированную.

Архитектура чего?
Что значит "перерастёт"?

Вот, например, программная архитектура Bluebottle основана на сильной типизации и ей защита памяти не нужна. И она может работать на существующих машинах.

Dron написал(а) ...
А пока все что вы здесь обсуждаете - лишь внешние наслоения над архитектурой, которая о типах вообще ничего не знает.

Иерархическая многоуровневая архитектура вообще-то считается хорошим тоном в проектировании программного обеспечения.

Например:

Файловые системы предоставляют возможность иерархического именования данных. Они работают поверх плоских дисковых блочных устройств, которые о файлах "ничего не знают". И о правах на доступ к файлам тоже.

Протокол TCP предоставляет услуги надёжного соединения. Он работает поверх ненадёжного пакетного протокола IP, который о соединениях "ничего не знает".

Dron написал(а) ...
следовательно все типовые ограничения - могут быть обойдены!

О каких именно угрозах идёт речь?
И каковы механизмы их реализации?

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Dron

Пятница 09.09.2005 11:45

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Файловые системы предоставляют возможность иерархического именования данных. Они работают поверх плоских дисковых блочных устройств, которые о файлах "ничего не знают". И о правах на доступ к файлам тоже.

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

То же самое и с памятью.. типы - это хорошо, но когда можно работать и без типов - вся надежность типовая сводится к нулю.

архитектуру железа надо менять.
Объекты - это лишь видимость.

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

Собственно к чему я клоню.
Вот есть аппаратные возможности защиты памяти. которые нельзя обойти. физически... - вот это надежно..

А всякие идеальные программные архитектуры без надежной аппаратной поддержки - ерунда!
[ Редактирование пятница 09.09.2005 11:48 ]

Андрей Валяев

Наверх

Переход на страницу 1 2 3 4 [5] 6 ... 13 14 15
Перейти: Наверх