> man operating_systems
Центр информации по операционным системам :: Форумы :: Общие :: Разное
 
<< Предыдущая тема | Следующая тема >>
Язык как основа операционной системы
Переход на страницу  1 2 3 ... 8 [9] 10 ... 15 16 17
Модераторы: Roman I Khimov, Wanderer, Dron
Автор Добавил
GVL
Понедельник 22.10.2007 19:11

ID пользователя #482
Зарегистрирован: Пятница 28.10.2005 18:16
Местонахождение: Украина, Винница
Сообщений: 11
ossadchy написал(а) ...

Можно даже без интерпретатора вовсе - все в бинарный код компилировать, написав соответствующий frontend для PCC/GCC.


Можно, но интерпретируемый код легче контролировать что самое главное на этапе проэктирования...
Наверх
Dron
Понедельник 22.10.2007 20:18


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
smalltalk - идеальное решение...

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

Андрей Валяев
Наверх
Сайт
Chizh
Среда 24.10.2007 13:34
ID пользователя #90
Зарегистрирован: Понедельник 13.09.2004 18:42
Сообщений: 170
GVL написал(а) ...
Можно, но интерпретируемый код легче контролировать что самое главное на этапе проэктирования...

Интерпретируемый код точно так же контролируется, как и не интерпретируемый, дело не в этом. Отладку кода можно перенести на второй план, поставив на первое дизайн. Код на высокоуровневых языках, особенно семейства "функциональных", похож на "исполняемую спецификацию". Т.е. берутся тезисы спецификации/описания системы, и почти "один в один" кладутся на код (почти как в "литературном" программировании), без лишних заморочек с элементарными функциями, конструкциями языка, и прочего "мусора". Сам код при этом имеет вид формул и функциональных отношений "как прописано в спецификации". При этом получается, что те самые оставшие 10% ошибок кодирования ложатся на корректность самой спецификации.
В принципе, такой подход к программированию не обуславливается только специальными языками программирования. Такие ЯВУ просто "облегчают" принцип программирования спецификация->код. С таким же успехом можно программировать и на Си/C++/SmallTalk, главное чтобы из кода было видно, что на первом месте стоит дизайн, а не программистские трюки, только лишь запутывающие код. Я сам придерживаюсь такого подхода, только до реального написания спецификаций пока не дошёл

[ Редактирование Среда 24.10.2007 13:57 ]
Наверх
Сайт
Dron
Среда 24.10.2007 14:01


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
А я уже дошел... Я уже написал несколько документов по моему будующему ядру... старею, склероз, надо все записывать... благо теперь я знаю что туда надо писать и как это должно быть... в отличии от первого ядра...

Поэтому, разумное желание многих программистов начинать программировать со спецификаций должно быть подкреплено опытом разработки подобных продуктов. Иначе ИМХО никак!

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

Андрей Валяев
Наверх
Сайт
GVL
Среда 24.10.2007 16:48

ID пользователя #482
Зарегистрирован: Пятница 28.10.2005 18:16
Местонахождение: Украина, Винница
Сообщений: 11
Chizh написал(а) ...

Интерпретируемый код точно так же контролируется, как и не интерпретируемый, дело не в этом..........


Полностью согласен.

Я хотел сказать немного о другом. Ядро ОС практически на 100% зависит от архитектуры процессора для которого написано. Если некто решил написать ОС базируясь на IA32 то он практически повторит решения давным давно придуманные разработчиками Windows, Linux или любой другой ОС для данной архитектуры. Архитектура любого процессора предлагает (или навязывает) разработчику свою схему работы с такими вещами как защита памяти, виртуальная память, управление процессами, обработка исключительных ситуаций и т.п. Отказ от такой зависимости реально позволяет создать чтото кардинально новое. Не зря разработчики Сингулярити поступили именно так. Сам по себе такой отказ предполагает использование некоего промежуточного байт кода который исполняется на виртуальном процессоре и потом транслируется в объектный код для конкретного железа. Более того, при успешном тестировании и хороших показателях работы возможна и кардинально противоположная картина - под промежуточный язык может появится процессор который его исполняет. Примеры последнего уже есть - например процессор под язык форт, кажись и под Java тоже делают...
По-этому, считаю, чтобы спроэктировать новую ОС (а не пародию на уже существующие) нужно для начала специфицировать и имплементировать виртуальное железо и естественно язык для него. Думается, что в Сингулярити поступили именно так... просто язык у них уже был.
Вот такие вот мысли...

[ Редактирование Среда 24.10.2007 16:50 ]
Наверх
Dron
Среда 24.10.2007 21:19


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
А я мыслю что проектировать надо не железо... для JavaOS - виртуальным железом становится как там ее Java-Classlib.
Или В виндовом понимании - HAL, тока понимать этот уровень абстракции можно по разному.

Всмысле некоторые пытаются делать абстрактное железо, Но ИМХО правильнее делать абстрактный комп более высокого уровня... Вот где-то так я мыслю...

Ос на Java или на C#- это очень хорошо, только медленно и ограниченно по возможностям.

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

Андрей Валяев
Наверх
Сайт
Chizh
Четверг 25.10.2007 00:49
ID пользователя #90
Зарегистрирован: Понедельник 13.09.2004 18:42
Сообщений: 170
Dron написал(а) ...
Ос на Java или на C#- это очень хорошо, только медленно и ограниченно по возможностям.

Это не беда. Во-первых оно не очень медленно, это далеко не интерпретатор Бейсика. Во-вторых, когда-то и С/С++ были очень медленными, но потом научились оптимизировать. Так же будет и с новыми языками, поэтому лучше не терять время, а ловить момент и заранее делать наработки на перспективных языках. Объективная реальность такова, что на прикладном уровне Java и C# используется всё активнее и шире, они скоро полностью вытеснят остальные языки. Скоро C/C++ останется только в ядрах
Наверх
Сайт
cmp
Четверг 25.10.2007 07:13
ID пользователя #279
Зарегистрирован: Понедельник 18.04.2005 15:35
Сообщений: 131
Chizh написал(а) ...

Скоро C/C++ останется только в ядрах

об этом я давно задумывался, в последствии будете иметь батник-архиватор, батник-автокад, и тому подобную лабуду, а все вместе это будет виндовс-10,
где топ-100 функциям будут соответствовать огромные кнопки, и а вызов всех остальных будет сродни уговариванию при помощи бубна
Наверх
ossadchy
Четверг 25.10.2007 11:00
ID пользователя #941
Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181
Между прочим, языки подобные Java и C# не обязаны быть интерпретируемыми.

2cmp: почему же батник, просто на языках более подходящих для прикладного программирования все будет писаться и это нормально -- для каждой задачи свой инструмент. С другой стороны если эти языки оправдают себя и в ядрах, то почему бы не писать на них ядра.
Наверх
Сайт
Chizh
Четверг 25.10.2007 15:53
ID пользователя #90
Зарегистрирован: Понедельник 13.09.2004 18:42
Сообщений: 170
cmp написал(а) ...
об этом я давно задумывался, в последствии будете иметь батник-архиватор, батник-автокад, и тому подобную лабуду

Больно уж напоминает "не знаю, но осуждаю". Лучше поменьше читать форумы, а почаще разбираться самому. Тогда окажется, что не так страшен чёрт, как его малюют
Наверх
Сайт
Переход на страницу  1 2 3 ... 8 [9] 10 ... 15 16 17  

Перейти:     Наверх

Транслировать сообщения этой темы: rss 0.92 Транслировать сообщения этой темы: rss 2.0 Транслировать сообщения этой темы: RDF
Powered by e107 Forum System

© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.