- Маг
- Постоялец
ffinder
>> Ведь по сути, это инкапсуляция (от слова "капсула") данных в пределах логической единицы.
>зачем он реально нужен, кроме как создания jail/realm?
Секретность: один объект может создавать другой объект из неизвестного источника (DLL, Интернет) и дать ему столько прав, сколько считает нужным без угрозы оказаться в "одном пространстве", а потом быть выпотрошенным с потрохами.
Безопасность: методы одного объекта могут читать только его память и испортить только ее, в случае ошибки.
Упрощение разработки: сокращается степень накопления ошибки - если метод выполнил недопустимую операцию, намного проще найти виновного и на более раннем этапе, а не ждать, пока произойдет каскад взаимосвязанных ошибок, чтобы потом их распутывать.
Стандартизация: все программы используют один и тот же метод хранения объектов, соот-но, им будет легче взаимодействовать.
> ага, задержки при доступе к памяти. чем больше у тебя будет фрагментация, тем меньше быстродействие.
Ты не понял - никакой фрагментации.
Память использует ассоциативный доступ, чтобы быстро найти пустые ячейки и выделить их. После выделения, объекты могут сдвигаться в памяти куда угодно, закрывая дыры, так как сами адресуются по ID. Процессор, используя ассоциативную память быстро переводит этот ID в реальный эффективный адрес. Члены данных в себе адресуют по индексу
> что такое истинное ОО тогда в твоем понимании?
Инкапусуляция данных и runtime-информация о типе объекта.
Маг
> > что такое истинное ОО тогда в твоем понимании?
> Инкапусуляция данных и runtime-информация о типе объекта.
Насколько ты знаком с Smalltalk ?
Маг
> Память использует ассоциативный доступ, чтобы быстро найти пустые ячейки и
> выделить их. После выделения, объекты могут сдвигаться в памяти куда угодно,
> закрывая дыры, так как сами адресуются по ID. Процессор, используя
> ассоциативную память быстро переводит этот ID в реальный эффективный адрес.
> Члены данных в себе адресуют по индексу
Всё хорошо до тех пор пока не появится аналог String :)
Маг
> методы одного объекта могут читать только его память и испортить только ее, в
> случае ошибки.
тогда отладчик невозможен - никто другой не может читать память объекта
кстати, как будет тогда реализован обмен сообщениями?
innuendo
> Насколько ты знаком с Smalltalk
Основная идея - тотальное наследование.
Насколько мне известно, идея наследования пришла в голову Страуструпа под влиянием Smalltack.
> Всё хорошо до тех пор пока не появится аналог String :)
Да, как организовать списки - нетривиальная задача.
Хотя у меня есть мысль на эту тему: reallocated-блоки разбивать на связанные сектора с фиксированной длиной, которые упорядочиваются микросхемой памяти так, чтобы закрыть дыры после вставки/удаления.
Т.е. память разбита на сектора и у каждого сектора две задачи:
1. Проверить поля ParenId/StartIndex соседа справа. Если они меньше, то выполнить операцию swap
2. Проверить поле ParenId соседа справа, если они равны и собственное поле size меньше MAX_SIZE, забрать у соседа недостающие до MAX_SIZE значения.
Примерно так. Тогда команды insert/remove занимали бы всего несколько тактов внезависимости от длины списка, а вся память кипела бы активностью в параллельном режиме, разгружая процессор :)
В любом случае, эта задача должна быть снята с плеч пользователя, а нерешаемых задач - не бывает :)
ffinder
>> методы одного объекта могут читать только его память и испортить только ее, в случае ошибки.
>тогда отладчик невозможен - никто другой не может читать память объекта
Так это зависит от флагов и кто кого создал. Объект, владеющий другим объектом, если захочет, может читать память подчитненного ему объекта.
Дочерний объект - не может никогда читать память своего родителя.
Тотальная иерархия, никакой демократии :)
Да и отладка облегчится еще и по другой причине - любой байт будет ассоциирован с какой-то информацией о типе. Т.е это не просто число, а, фактически, пара тип/значение.
> кстати, как будет тогда реализован обмен сообщениями?
Мысли на этот счет есть, но я бы две темы не смешивал.
Прежде чем рассуждать о таком процессоре - неплохо бы разобраться с основами ООП. И не с искажениями в виде C++ или Java, а с первоисточниками типа Smalltalk или CLOS.
Маг
Мне только одно не понятно.
Как все, что вы описали реализовать на кристале))))
Начнем с того, что такие вещи простыми транзисторными ключами не сделать...
А это соответственно требует усложнения модулей памяти, что за собой влечет увеличение ее стоимости и судя по описанным "свойствам" не хило.
Сейчас память - это куча банок с маленькой ПЗУ в которой прописано все что нужно для памяти (vendor, size, speed stepping). Остальное делает
DMA.
А тут придеться еще отдельный процессор делать для управления памятью, писать для него "прошивку" которую придется хранить в отдельной flash памяти. И чтобы все это работало со скростью центрального и адекватно отвечало на запросы, а главное с адекватной скоростью, то придется это делать с соответсвующими затратами на тепловыделение. Тут уже ARM и иже с ним не обойдешься.
Т.е. такой блок придеться делать на кристалле основного проца, отдельно выносить flash память для программы, а модули памяти опять таки подключать чисто как плата с банками памяти. Да плюс ко всему проц должен иметь еще и свои наборы "инструкций" которые вы описали, что скорее всего приведет также к разработке микро прошивок и хранение их где нить во flash памяти.
И того имеем интересную структуру. Проц получает команду чтения из памяти.
Он записывает нужные данные во внешние регистры sub проца для памяти, (но пардон! регистры это не миллионы байт, это ограниченные ячейки внутренней памяти процессора, отсюда не понятно как проц сможеть получить map, например, для указателя на 150 метров памяти) и уже тот начинает исполнять свою внутренную программу, и только потом возвращает что-то основному процу.
А теперь момент. Мне нужно записать 150 метров памяти.. И что? Каждый раз будет выполняться обращение к sub процу памяти, тот будет копировать в лучшем случае 8-16-32-64 байта памяти за раз, плюс время на исполнение "своей" программы, в итоге получаем черепашью скорость. Если же это делать путем возврата sub процом памяти адреса на первый байт блока в 150 метров, то копирование памяти будет производится без участия sub проца и соответственно он НИКАК не сможет проконтроллировать что и как копируется, и уж тем более разделить ее как вы описали.
Если же "разделение" памяти делать после того как она скопирована, то мы получим не хилый простой основного проца, так как sub проц будет исполняя свою программу разделять память...
Имхо цена будет огого, а скорость работы такого процессора будет не очень высокой.
Маг
> > Насколько ты знаком с Smalltalk
> Основная идея - тотальное наследование.
Основная идея - объекты обмениваются сообщениями. Это основа. Потом уже наследование и др :)
Что-то мне кажется что "реальное распараллеливание" - плохая идея. Люди бывает, мучаются с синхронизацией даже двух потоков, а вы хотите, чтобы вся программа работала вразнобой. Хотя, хорошо, если распараллелить такие вещи, как таймеры или обработчики сообщений.
Кстати, вот по теме: http://ru.wikipedia.org/wiki/Закон_Амдала - тут указываются реальные пределы прироста производительности, которые могут быть достигнуты при распараллеливании. Это и так можно объяснить, это более-менее понятно, просто там целая статья.
Мух
>Начнем с того, что такие вещи простыми транзисторными ключами не сделать...
>А это соответственно требует усложнения модулей памяти, что за собой влечет увеличение ее стоимости и судя по описанным "свойствам" не хило.
Возможно ты и прав, хотя всегда найдутся области, где цена - не вопрос, особенно если отдача от машины перевешивает затраты на ее постройку.
Однако вопрос НЕ в том, как организовать инструкции alloc/insert/remove/free для списков на машинном уровне, это я отвлекся от темы :)
> Сейчас память - это куча банок с маленькой ПЗУ в которой прописано все что нужно для памяти (vendor, size, speed stepping).
Естественно, для такой архитектуры оставить память под списки с общими правами для всех - не имеет смысла.
Самое простое решение - сделать еще и память блоков, тогда у нас получится четыре уровня, а не два уровня, как сейчас:
1. Память типов: {ID блока кода, ID описания структуры, usageCount}, а также неявный ID (type id).
2. Память заголовков объектов: {ID типа, ID блока сущности, ID объекта владельца, lock, usageCount}, а также неявный ID.
3. Память заголовков блоков памяти: {размер, адрес, ID объекта владельца, lock}, а также неявный ID.
4. Сплошная (flat) память, на которую ссылаются блоки и только они.
Таблицы 2 и 3 работают примерно так же, как сейчас таблица дескрипторов задач в процессорах x86. Т.е. каждая задача имеет свое виртуальное адресное пространство, позволяя по сути обращаться в ее пределаз к байтам по индексам в пространстве, а не их реальным адресам в физ. памяти.
Выделением блоков занимается специальный модуль в кольце ядра.
innuendo
> Основная идея - объекты обмениваются сообщениями. Это основа. Потом уже наследование и др :)
Я бы не стал пока ограничивать способы обмена сообщениями между объектами каким-то одним "самым правильным" :)
Потому что не вижу такого.
Zefick
> Что-то мне кажется что "реальное распараллеливание" - плохая идея. Люди бывает, мучаются с синхронизацией даже двух потоков, а вы хотите, чтобы вся программа работала вразнобой.
Так синхронизацию все равно нужна, потому что lock отвечает только за сущность объекта, для которого вызывается метод. Вызов любого метода автоматом вызывает быстрый lock(this), выход из метода - unlock(this). Все агрегированные члены - не запираются, пока их собственные методы не будут вызваны. Это делает работу более надежной, а взаимную коммуникацию объектов - более простой, но не освобождает от работы по синхронизации множеств объектов по нужному тебе алгоритму.
Маг
Наследование, говоришь? Расскажи как будешь делать аналог
super message. ?
Посылку сообщения суперклассу ...
Объектно-ориентированная архитектура, я уверен, может дать огромные преимущества в скорости и безопасности кода
Не знаю ни одного примера абстракции, для которой бы не существовало более быстрого решения без использования этой абстракции.
Есть ли у кого схожие идеи на эту тему и кто как считает - возможна ли в ближайшем будущем такая архитектура ?
Ну вы про HAL слышали ? Очень странно, но до сих пор в этой теме не был упомянут этот термин.
ProGrAMmER256
> Не знаю ни одного примера абстракции, для которой бы не существовало более
> быстрого решения без использования этой абстракции.
Пишешь в машинных кодах? O___O
Никто с Катаной не разбирался ?
А с VM от Smalltalk ?
Тема в архиве.