Центр информации по операционным системам: Форумы / Ядро / Ядро ОС на C++

Центр информации по операционным системам :: Форумы :: Концепции :: Ядро		<< Предыдущая тема \| Следующая тема >>
Ядро ОС на C++

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

Автор

Добавил

Roman I Khimov

Вторник 26.04.2005 22:35

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

Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601

Tommy написал(а) ...
объектная технология вовсе не требует объектного языка!

Вот это, как говорится, в дырочку. ООП - это мышление, в первую очередь.

Tommy написал(а) ...
Так что Ассемблер - на свалку.

Смело.

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

Греби и улыбайся!

Наверх

Chizh

Вторник 26.04.2005 23:10

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

Зарегистрирован: Понедельник 13.09.2004 18:42
Сообщений: 170

Затаившиеся баги слишком часто потом этот кайф обламывают - это всё-равно что ловить кайф от прыжков без парашюта. Оно может и кайфово, но вероятность разбиться очень высока.
[ Редактирование вторник 26.04.2005 23:18 ]

Наверх

Dron

Среда 27.04.2005 10:34

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

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

(Активно встаю на защиту святого!!!

Тут есть еще один момент... отладка... когда я смотрю в отладчик, я вижу там асм... отладку по сырцам прикрутить на ядро - еще умудриться надо. так вот, мне легче понять что в асме у меня не так, ибо все написано на нем же, чем соображать что мне нагенерил си... (к тому же не надо парится как наладить отладку по сырцам!)

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

Хороший код - залог уменьшения количества ошибок на любом языке!

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

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

Наверх

Dron

Среда 27.04.2005 10:37

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

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

Зы... вчера нашел ошибку в ATL... Ж) ламеры и маздаи...
Кому интересно - велкам ту C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\include\\statreg.h строка 451... для сравнения - строка 482...

Естественно это VS.NET 2003...
[ Редактирование среда 27.04.2005 10:39 ]

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

Наверх

Chizh

Среда 27.04.2005 14:00

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

Зарегистрирован: Понедельник 13.09.2004 18:42
Сообщений: 170

>Тут есть еще один момент... отладка... когда я смотрю в отладчик, я вижу там асм...

Нет проблем - генерируй ассемблерный исходник из сишного файла, и отлаживай сколько хочешь

>Насчет потенциальных ошибок - строгий язык (c/c++ к такому относится с большой натяжкой) конечно может минимизировать этот фактор, но программист сам должен понимать что он пишет, иначе грошь ему цена.

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

>Хороший код - залог уменьшения количества ошибок на любом языке!

Это не повод для программирования например в Hex кодах.

PS Ассемблер нужно знать, но на нём не нужно программировать.

[ Редактирование среда 27.04.2005 14:05 ]

Наверх

Dron

Среда 27.04.2005 14:33

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

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

Ну вот зачем я буду придумывать способы посмотреть как моя программа выглядит в асме??? когда я на асме пишу не хуже.

Я ж не призываю писать на асме все... но для ядра он вполне уместен.

Написание ядра на ассемблере во многом облегчает мне процесс.

Ну начнем с того, что многих необходимых вещей C не поддерживает вообще... а ассемблерные вставки не самая наглядная вещ.

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

Придумывать методы, как все это обходить на си - это, лично для меня, лишний гемор.

ЗЫ: ну хоть кто нибудь глянул на мой код? и на асме можно писать наглядно...

И не надо утрировать (насчет HEX кодов, ибо мы говорим о языках программирования)

ЗЫ: А насчет ATL - я говорил смотреть на .h файл... чтож вы такие не внимательные?

[ Редактирование среда 27.04.2005 14:35 ]

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

Наверх

Chizh

Среда 27.04.2005 15:46

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

Зарегистрирован: Понедельник 13.09.2004 18:42
Сообщений: 170

>Ну вот зачем я буду придумывать способы посмотреть как моя программа выглядит в асме???

Придумывать не нужно. Генерировать Ассемблерный исходник умеет любой компилятор.

>Я ж не призываю писать на асме все... но для ядра он вполне уместен.

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

>Ну начнем с того, что многих необходимых вещей C не поддерживает вообще... а ассемблерные вставки не самая наглядная вещ.

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

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

Всё нормально с регистрами, в ассемблерных вставках описываются все используемые регистры. Вот например ассемблерная вставка "in al,dx"

char inpb(int nPort);
#pragma aux inpb = "in al,dx" parm [dx] value [al] modify exact [al]

Здесь указывается что параметр функции [dx], результат в [al] и модифицируется [al].
В коде вызывается обычным образом: char Data = inpb(Port);
при этом в код будет вставнена только инструкция in al,dx, без вызова функции.

>ЗЫ: ну хоть кто нибудь глянул на мой код? и на асме можно писать наглядно...

Все знают возможности asm и cpp. Чего смотреть-то? Всё равно как в cpp не получится.

ЗЫ: А насчет ATL - я говорил смотреть на .h файл... чтож вы такие не внимательные?

Я думал что в папке Include только одни заголовки, поэтому не глянул на тип. Да, кто-то поспешил

[ Редактирование среда 27.04.2005 15:49 ]

Наверх

Dron

Среда 27.04.2005 16:47

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

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

Насчет вставок - не все так безоблачно как ты говоришь... то что ты написал - сработает только в ваткоме. в gcc - все выглядит по другому...
Я знаю что это не страшно, но мне не хочется с этим связываться вообще.
Не надо меня плиз учить! Я тебе могу написать 5 вариантов оформления инлайн вставок на разных компиляторах...

А сгенеренный ассемблер - совсем не то же самое что написанный самостоятельно...

Да я ж никого не убеждаю... пишите на C++, пишите хоть на бейсике... каждый выбирает то, что ему удобнее.

Как сказал один мой друг еще давным давно... - "Операционную систему можно написать на чем угодно!"

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

Наверх

Chizh

Среда 27.04.2005 17:24

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

Зарегистрирован: Понедельник 13.09.2004 18:42
Сообщений: 170

Нет, я просто пытался перевести разговор в аргументированную плоскость. Ну да ладно.

>А сгенеренный ассемблер - совсем не то же самое что написанный самостоятельно...

C - это высокоуровневой Ассемблер, поэтому не надо про тоже/не тоже.
Касательно совместимости компиляторов - а твоя система компилируется любым компилятором Ассемблера?

[ Редактирование среда 27.04.2005 18:03 ]

Наверх

Dron

Четверг 28.04.2005 10:24

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

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

нет, просто мой компилятор ассемблера есть под любую платформу...

в отличии от ваткома... который даже с ELF дружит как-то странно...

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

Наверх

Переход на страницу 1 2 3 [4] 5 6 7 8 9
Перейти: Наверх