Linux or Windows?

А кто призывал писать ОСи на паскале?
Просто SII хотет что бы вы задумались и всё. А уж вам решать стоит ли к этим словам прислушиваться.
У меня такое ощущение, что большинство даже и не захотело задуматься.

 

SII
Ничего не понимаю

Хорошо, объясни неразумному

Ты можешь понять одну простую вещь. Что на дворе 21 век и железо меняется очень быстро. Новые процы, архитектуры. И чуть ли не каждый год.
Как ты представляешь себе выжать максимум из ядра, когда через полгода появится новый проц?
Твое "заоптимизированное" ядро джава не напрягаясь сделает.
Это не старые добрые времена. И не военная промышленность.
Там да, используется определенный процессор и мы знаем, что лет 20 -30 на нем все будет работать.
Как впрочем нельзя отбрасывать и сложность современных ОС. Это стало невозможным уже давным- давно.

Эта проблема есть - "ограничить свободу" дабы кодер делал меньше ошибок. И для этого прилагаются усилия, как в той же НЕТ. Но. Это область прикладного программирования, а не системного. Разница понятна?

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

//-------------
Следовательно - языки с "жесткими" правилами полезны. Но в своей области.
Добавлю, что на С можно написать компилятор, того же паскаля например, или себя самого. Можно ли на Паскале, написать компилятор Паскаля? Теоретически да. Практически он писался и будет писаться на С. Зачем плодить дополнительные ошибки?
Мало?
Просто мир не совершенен. И следует различать системное прогр. (С, Асм) и прикладное, где и вправду излишняя свобода "ограничивается". Что в данном разрезе, очень полезно.
Поэтому я не хаю языки, ни Паскаль, ни какие другие. Каждому свое.
И то что в Паскале возможна прямая работа с памятью, асм вставки, не делает его инструментом для системного программирования.
Если писать дальше, то выйдет статья
А вам советую просто поразмышлять и почитать материалы на эту тему.

 

SII

допустим на шаге 3 (для общности положим, что активна не sys_pause, а любая sys_* функция, реализующая системный сервис) происходит int 80h
ESP (стек системы) декрементируется на 12 (для x86) или на 40 (x86-64)
он сохраняется в TSS, но в TSS был сохранен адрес вершины стека системы, который и помещается в ESP
получается, что произошло неявное инкрементирование ESP
и дальнейшие действия могут привести к затиранию данных

 

Вы по всей видимости экстрасенс, узнаете что хочет сказать человек. Он четко сказал что Си язык извращенцев и Паскаль лучше, ему объяснили с точки зрения маркетинга и с точки зрения простых разработчиков в чем он не прав.
Товарищ rei3er обсуждает тему линя и виндов, в эту тему я не вмешиваюсь т.к. обе системы в целом равны и тут для меня нет смысла в оспаривании, но вот Си vs Паскаль, это уже другое, это не Delphi vs C в котором можно прийти к единому мнению и обсуждений на подобную тему не было.

Это откуда вы вычитали?

 

Linux.. Windows.. Си.. Паскаль.. Извращенцы.. Закрыто! =^____^=

[update]
А впрочем...

 

vito

Скачай исходники FreePascal и не позорься. И SP Forth, кстати, тоже пишется на самом себе предыдущей версии.

Assault

Так он на делфях такое вытворял, что половина здешних мыслителей его крео даж заценить по достоинству не способна. Потому что очень сильно голову задирать придётся.

 

CyberManiac

А конкретнее? Писал новые разновидности тан-грабберов и сопутствующего софта?

vito

1. За последние 2 года я видел новинки только среди видеокарт. Архитектура и тактовые частоты процессоров не изменились... Прирост производительности процев замедляется, да и невозможно наращивать частоты бесконечно.
2. Назовите принципиальные отличия .386 от .586 проца, которые не позволят перенести асм-код, оптимизированный под 386й на 586ю платформу...

 

Aquila
Хорошо со стороны смотреть...

Я вот тут написал, как я юзаю разные языки.
Дело в том, что все зависит от поставленной задачи.

1. ASM - очень редко, в виде вставок в C / pascal
2. Pascal - все реже встречается в проектах. Почти не использую. Раньше юзал для построения GUI или разных вычислений.
3. C/C++ -- Создание разделяемых объектов: Работа с пользователями системы, файлами, устройствами, написание драйверов. В основном - это нити CNI и JNI.
4. Ada -- только в целях медитации и изучения разных подходов к программированию. В проектах не встречается.
5. BASIC - Надобности использования нет. В системе установлен для разных экспериментов.
6. PHP - Это если надо что-то быстро обработать. Для меня - это язык простой и мнгновенной обработки данных, и как следствие, исчезает надобность в PERL
7. Shell -- строго для создания CheckTool и Configure.
8. Java (SUN)- Основной язык. Используется для создания интерфейсов к разным девайсам и программам, всё ООП на нём, логика тоже на нем. Нити из JNI с/с++ библиотекам
8.1 GCJ (GNU Java) - Это не язык, но у него есть свои фичи, которых нет нигде! ClassLoader - нифига не работает, как ни крути, однако, взаимодействие с ассемблером (GAS) - это стоит попробовать.

Все зависит от поставленной задачи.

 

Не надо устраивать холивар с делфями. И тем более притягивать Рэма, он писал и на Си в том числе.
P.S. Синтаксис прочих языков всетаки больше приближен к Си и это уже обсуждалось неоднократно.

 

CyberManiac
Я же сказал, что далек от Паскаля. А ты насколько я знаю, его любитель.

Assault
1. Предел по частотам достигнут, архитура строися по другому принципу.
2. Мат. сопроцессор например.

 

vito

А... "Пастернака не читал, но осуждаю"...

А еще я иногда преподаю С++, хе-хе-хе. Каких только гадостей не сделаешь ради денег...

 

CyberManiac

Я не сказал, что не знаю его вовсе.
Но не люблю, и для работы он мне не нужен.
Так что. Пастернака я читал Возможно невнимательно, но это другой вопрос
Да и как я написал - теоретически возможно. От тебя узнал, что это уже сделано
//----------
Ты лучше просвети нас по поводу Осей на Паскале. И будучи знатоком, объясни объективно и его недостатки

 

Попался тут Delphi компилер DCC от ПО Kylix3.

и понял что мне так не хватало в 35-метровом обрубке ZipSlack (Linux Slakware 11) стартующей на FAT32 из под FREE DOS (у мну три системы на одном C:\) )))
Да, да старого доброго, быстрого компилятора+линкер...

Покамест приходиться заниматься жостким дзеном, относительно перепиливания System/SysInit (чтоб ELF-ы были маленькие), и заодно податоскаться по части 32-битной кросплатформенности, в Delphi кодинге)))
Necromancer13 песал:

хе.. Главное чтоб Midnight Commander не глючил (хотя с ним есть некоторые нюансы)

 

да хватит вам про языки спорить
здесь в отличие от ОС все и так ясно
все они функционально эквивалентны
а остальное зависит от личных предпочтений и рыночной конъюнктуры

 

CyberManiac

Можно ещё вспомнить Турбо Паскаль -- тоже на Паскале (не считая компилятора командной строки TPC, написанного на ассемблере). Да и первые Дельфи были на Дельфи, если склероз не изменяет. А компиляторы Фортрана, бывало, писали на Фортране (у меня даже книжка валяется, "Трансляция с Фортрана на машинах с малым объёмом памяти", там такой компилятор и описывается) -- а ведь Фортран, да ещё в 1960-е, даже близко по возможностям обработки файлов и строк символов не лежал ни с Паскалем, ни с Си...

Assault

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

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

Нет таких отличий. Вот наоборот, сверху вниз -- это понятно. Появились новые команды, коих у 80386 попросту нет. Единственная проблема может возникнуть из-за того, что Интел не обеспечивает полной совместимости снизу вверх, т.е. можно наткнуться на ситуацию, когда более поздний процессор что-то делает не так, как более ранний. Но это весьма редкие случаи; я, честно говоря, назвать сходу не возьмусь.

im1111

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

 

rei3er

Как оказалось, не всем всё ясно, и некоторые уверены, что Паскаль -- неполноценный язык, потому что "учебный"

Да и не только в функциональной эквивалентности дело. Сравните, например, классический Бэйсик (неструктурный) со структурными языками. Одинаковую программу по функционалу можно написать и там, и там, но насколько проще, понятнее, быстрее (если она большая) её можно сделать на Паскале или Си! Дело-то не в goto, а в том, что в классическом Бэйсике без него обойтись невозможно, ну а в указанных языках он либо вообще не нужен (строго говоря, без него всегда можно обойтись), либо используется редко и в специфических случаях (имхо, наиболее правильный подход). Соответственно, и структура программы на Паскале и Си будет куда яснее и нагляднее, чем на классическом Бэйсике.

Правда, Бэйсик не является функционально полноценным -- в нём нет работы с динамическими данными, но, надеюсь, понятно, что здесь речь не о наборе операций была

Возвращаясь к нашим баранам...

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

Если int выдаётся пользовательским процессом, то происходит аппаратное переключение на стек системы (поскольку уровени привилегий кода до и после прерывания различны), если же выдаётся потоком ядра -- аппаратного переключения нет, поэтому и приходится выполнять программное переключение.

Экономия -- на стеке режима ядра для процессов режима пользователя. В Линухе каждый такой процесс имеет стек режима ядра в 8 Кб, который самому этому процессу не нужен (он даже доступа к нему не имеет), а нужен самой системе. Я же от этого стека полностью отказываюсь -- вот вам и экономия.

Кстати, может, лучше обсуждение в аське продолжить? Подавляющему большинству наша беседа малоинтересна (в ней же священной войны не намечается )...

 

ок
но вопрос еще в силе

применительно к этому

+ вот это http://www.wasm.ru/forum/viewtopic.php?pid=225467#p225467

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

так у вас есть и собственный стек, и стек системы
что такое собственный стек?

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

 

rei3er

Это Вы про вот этот вопрос:

Если да, то ответ элементарный: на шаге 3, равно как и на всех прочих шагах до окончания шага 5, т.е. до передачи управления следующему процессу, никаких int'ов возникнуть не может. Обработка int'а ведётся в рамках обработчика прерывания, а не в рамках потока режима ядра, а обработчикам прерываний обращаться к системным сервисам с помощью int запрещено.

Скорей, не с терминологией проблема, а с недопониманием -- вот что значит общение через Инет, при живом за 30 секунд друг друга поняли б...

Процессы пользователя работают только в режиме пользователя -- зачем им стек системы? Они к нему не обращаются и обратиться не могут -- на то они и процессы пользователя!

В единственном имеющемся TSS находится указатель вершины единственного стека режима ядра, используемого для обработки абсолютно всех прерываний. Когда прерывание происходит во время работы процесса пользователя (т.е. когда CPL=3), происходит автоматическое переключение на стек системы, и в SS:ESP загружается адрес вершины стека ядра. Чего здесь сложного-то?

Единственное, что может сбивать с толку, это моё ручное сохранение SS:ESP потока ядра (если int выдал он, а не процесс пользователя) в TSS. Но на самом-то деле глубоко без разницы, где его сохранять -- можно выделить отдельную переменную. Просто этим я экономлю шесть байт: всё равно в TSS соответствующее поле не используется по прямому назначению, поскольку аппаратная многозадачность не зайдествована.

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

 

SII

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

а что ты изречёшь по поводу проблемы портирования оси на другие камни??? узконаправленные оси пишутся и писались на асме, а вот оси для рынка строфать на чистом асме эконом. невыгодно)

 

так когда же тогда выполняется это условие?

любая работа процесса в режиме ядра - это либо обработка прерывания, либо выполнение кода системного вызова типа sys_pause
когда же тогда может генерироваться програмное прерывание в режиме ядра?

так SS:ESP потока ядра принадлежит диапазону адресов стека системы, если я правильно понял
а если нет, то где идет переключение на стек потока?
и опять этот загадочный стек потока...
хоть убейте, пока суть не понятна