В статье (http://tommd.wordpress.com/2009/09/13/kernel-modules-in-hask... представлен пример создания и сборки рабочего модуля для Linux ядра, написанного на функциональном языке программирования Haskell (http://ru.wikipedia.org/wiki/Haskell) с интегрированным сборщиком мусора. Для сборки задействован компилятор GHC (http://www.haskell.org/ghc/) и наработки проекта House (http://web.cecs.pdx.edu/~kennyg/house/), ориентированные на использование Haskell для низкоуровневого программирования.URL: http://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/
Новость: http://www.opennet.me/opennews/art.shtml?num=23394
>As a result, the first command below should not result in output while
>the second should be minimal.
> nm module.ko | egrep “^ +C ”
> nm module.ko | egrep “^ +U ”U __kmalloc
U kfree
U krealloc
U mcount
U printk
Это Hello World! такой, c malloc и free :)
Ваще забавно, только не вижу смысла писать системные задачи на функциональном языке...
Ядро не должно думать, ядро должно ПРАВИЛЬНО передавать от юзера к железу и обратно.
Ну или железо должно думать, а пользователь только нажимать на кнопки...
>Ваще забавно, только не вижу смысла писать системные задачи на функциональном языке...сходу кажется что immutable states и прочие штуки повышающие стабильность и предсказуемость языка по сравнению с C того стоят
Пусть думает - надо же защиту от дурака, чтобы пользователь не раскаивался в итоге от своих ошибок.
>Это Hello World! такой, c malloc и free :)А как же! Там же сборщик мусора. Без него теперь никак... ;)
Сбылась мечта VSL! =)
в чём тут прикол? вот если бы на паскале можно было писать модули для ядра...
а почему бы не на коболе?
>в чём тут прикол? вот если бы на паскале можно было писать
>модули для ядра...Какие проблемы? Паскаль знаете? Вперед!
Такие же объектники генерит, даже asm впаян... можно прогнать через p2c
думается, что p2c не так чисто работает, как хотелось бы. ;)
> Какие проблемы? Паскаль знаете? Вперед!Блин, ждем пример модуля ядра на брейнфаке. Уж ты извини, павлинукс, но gcc с асм вставками получается как-то сильно менее черезпопно и кроссплатформенно чем паскаль с оными, имхо :).Более того - в gcc как-то проще и понятнее генерация кода и упихивание всего этого в случаях когда на выходе надо получить что-то предсказуемое до битика (e.g. бинарь с предсказуемым размещением частей для зашивки в однокристалку, etc).
>в чём тут прикол? вот если бы на паскале можно было писать
>модули для ядра...Лучше на брейнфаке.
Ты наверное свято веришь в то, что "настоящие" программисты пишут только на C/C++?
>Ты наверное свято веришь в то, что "настоящие" программисты пишут только на
>C/C++?Настоящие программисты не забивают гвозди головой.
>Настоящие программисты не забивают гвозди головой.ОК. Прошу в студию примеры того, что не умеет паскаль такого, что умеет Си? :)
Причем здесь "умеет - не умеет"? Можно ли гвозди забивать, например, плоскогубцами? Можно. Но никто так не делает - для этого есть молоток. Примерно так же и с языками программирования.
по скорости он будет уступать. нужно более конкретно обяснить, какая конкретно скорость подразумевается, или вы сами знаете? даже не скорость оптимизации (в этом случае можно условно не учитывать).
>>Настоящие программисты не забивают гвозди головой.
>
>ОК. Прошу в студию примеры того, что не умеет паскаль такого, что
>умеет Си? :)модули для ядра :)
Ах да, вспомнил, в Паскале незя мешать логику и математику...
( a || b ) * ( a && b ) << c
c + !( a || b ) * dкоторая ох как нужна при работе с девайсами
В паскале указатель может ссылаться на не инициализируемую переменную - очень полезно для глюкофф
В Паскале нет арифметики с указателямиВычисление чисел Фибоначчи, работает раз в 20 быстрее чем любая рекурсия, рекурсия с массивами,....
/* ---------------- */
#include <stdio.h>
void l(unsigned int* n1, unsigned int* n2, int n) {
unsigned int k1,k2;
if(n<=1) { *n1=1; *n2=1; return; }
if(n==2) { *n1=2; *n2=1; return; }
if(n%2) {
l(&k1, &k2, (n-1)/2 );
*n1 = k1 * ( k1 + k2 ) + k1 * k2;
*n2 = k1*k1 + k2*k2;
} else {
l(&k1, &k2, (n/2)-1);
*n1 = ( k1+k2 ) * ( k1+k2 ) + k1*k1;
*n2 = ( k1+k2 ) * k1 + k1*k2;
}
}unsigned int f(int n) {
unsigned int n1, n2;
l(&n1,&n2,n);
return n1;
}void f_print(int n) {
printf("%dth Fibonacci number is %lu\n",n,f(n));
}int main(void) {
f_print(46);
return 0;
}/* ---------------- */
Только ради такой красоты, можно выкинуть слово Pascal из мозга,
и поставить фаервол, чтоб не возвращалось.
У Паскаля есть один большой ПЛЮС, - С него ЛЕГКО перейти на С, обратно уже не возможно. :)
>Ах да, вспомнил, в Паскале незя мешать логику и математику...Да можно. Но это опять забивание гвоздей при помощи плоскогубцев:
Integer( a or b ) * Integer( a and b ) shl c;
c + Integer(not( a or b) ) * d>В паскале указатель может ссылаться на не инициализируемую переменную - очень полезно для глюкофф
Не совсем понятно что здесь имелось ввиду, но способность указателей ссылаться на все что угодно - это, скорее, свойство Си.
>В Паскале нет арифметики с указателями
Да есть. Но она тоже через жо^W^Wпреобразование типов.
>>Ах да, вспомнил, в Паскале незя мешать логику и математику...
>
>Да можно. Но это опять забивание гвоздей при помощи плоскогубцев:
>>В Паскале нет арифметики с указателями
>
>Да есть. Но она тоже через жо^W^Wпреобразование типов.Все, что вы тут называете "забиванием гвоздей плоскогубцами", является примером строгой типизации. Паскаль и Си это как литературный язык и уличный жаргон. Да, на втором говорить иногда удобнее и лаконичнее. Но на первом четче и приятнее.
тогда программинг на асме - трехэтажный мат? :)в действительности си (плюсы - немного меньше) для меня - ассемблер с "человеческим лицом". этот язык программирования так и был задуман по своей сути.
>тогда программинг на асме - трехэтажный мат? :)Нет. Потому что проблема Си и в бОльшей степени Си++ не в низком уровне, а в расхлябанном стиле.
>в действительности си (плюсы - немного меньше) для меня - ассемблер с
>"человеческим лицом". этот язык программирования так и был задуман по своей
>сути.Да. И только в этом смысле он действительно хорош.
Паскаль гораздо более продвинут, чем Си. Я считаю, что единственная причина, почему на нем не пишут ядра ОС (хотя, попытки наверняка были), это его богатая стандартная библиотека, которую тяжело перенести на уровень ядра (например, строки).
>Паскаль гораздо более продвинут, чем Си.Недавний пример из личной практики.
const
LocoCodeTable: array [0..166] of TLocoRec = (
(Name: '2М62'; Code: 539;),
(Name: '2М62У'; Code: 579;),
(Name: '2ТЭ10'; Code: 526;),
(Name: '2ТЭ10В'; Code: 533;),
(Name: '2ТЭ10Л'; Code: 527;),
(Name: '2ТЭ10С'; Code: 580;),
...
...Так вот, чтобы объявить этот массив, необходимо точно знать сколько в нем элементов, то есть мне их пришлось сначала все СОСЧИТАТЬ! И делать это приходилось каждый раз когда нужно было удалить или вставить несколько элементов! О_о Это, конечно, нетрудно (нужно из номера последней строки вычесть номер первой), но зачем, скажите, этот "продвинутый" язык заставляет меня заниматься такой херней?!
> Я считаю, что единственная причина, почему
>на нем не пишут ядра ОС (хотя, попытки наверняка были), это
>его богатая стандартная библиотека, которую тяжело перенести на уровень ядра (например,
>строки).Странное утверждение. Богатую сишную стандартную библиотеку (со строками, с динамической памятью, бог знает еще с чем) на уровень ядра перенести смогли, а паскалевскую почему-то не могут... :\
И, кстати, да, Вирт написал свою Bluebottle на Обероне, паскальподобном языке. Я же говорю, что гвозди можно забивать и плоскогубцами :)
>[оверквотинг удален]
>const
> LocoCodeTable: array [0..166] of TLocoRec = (
> (Name: '2М62'; Code: 539;),
> (Name: '2М62У'; Code: 579;),
> (Name: '2ТЭ10'; Code: 526;),
> (Name: '2ТЭ10В'; Code: 533;),
> (Name: '2ТЭ10Л'; Code: 527;),
> (Name: '2ТЭ10С'; Code: 580;),
> ...
> ...Не путаете с Си++? Это я к тому, что Линукс пишут на Си, хоть и используют расширения gcc.
>зачем, скажите, этот "продвинутый" язык заставляет меня заниматься такой херней?!
Этот продвинутый язык заставляет вас заниматься херней, чтоб вы наконец поняли, что делаете что-то не так, и что пора вынести данные из исходников во внешний файл, загружаемый в рантайме.
>Странное утверждение. Богатую сишную стандартную библиотеку (со строками, с динамической памятью, бог знает еще с чем) на уровень ядра перенести смогли, а паскалевскую почему-то не могут... :\
В Си нет строк. А в паскале они есть, да еще и с подсчетом ссылок и автоматическим управлением памятью под ними. Вот такие вещи как раз сложно унести в ядро, насколько я понимаю.
>И, кстати, да, Вирт написал свою Bluebottle на Обероне, паскальподобном языке. Я
>же говорю, что гвозди можно забивать и плоскогубцами :)Совершенно другой язык, несмотря на то, что является далеким потомком Паскаля.
int Count[]={10, 20, 30};так можно на си. и это не расширение gcc.
си может обрабатывать символьные массивы неограниченной длины. не вижу здесь где-то каких-то преимуществ. потому что видеть в таких простых очевидных вещах только положительное, это уже фанатизм. потому как всегда есть компромис, никогда нет только положительных вещей. это попахивает маркетингом, когда предоставляют факты в розовом цвете. это как фейки о скорости обработки явы в сравнении с си или плюсами (якобы ява справляется шустрее). а скажешь: Фибоначи или Гаус и все. приплыли.язык си на момент начала написания ядра был более распространненным, и он более подходит для байтовых операций, операций с битами. конечно, порой нужна и обработка строк, но это как-бы на второстепенном плане. и можно без каких-либо больших трудностей работать с обычными символами и с уникоде. но все-таки там нет некоторых удобных функций для работы с битами, что приходится делать или в цикле, либо в ущерб мультиплатформенности делать на асме. пример - определение местоположения первого, установленного бита в байте. но остальное, типа циклического сдвига и прочего работает на ура и быстро.
Паскаль это работающий, структуированный язык для обучения. по крайней мере было так задумано. совковый клон - алгоритмический язык.
в свое время переписывали "Реверси" из хаотичного бейсика на Паскаль. без единого goto, и исходник программки вышел процентов на 30 меньше на последнем. просто для понимания и поиска ошибок. а потом пришел сам по себе си, и на на нем можно писать элегантные программки. для больших и средних проектов больше подходит уже c++ даже с применением UML.
а настоящий программист скорее тот, кто пишет красивые и эффективные программки. если профессионально, то еще и успевает в срок сдать проект. но это уже философия, аки спор о "лучшести" того или иного языка.
>>[оверквотинг удален]
>В Си нет строк. А в паскале они есть, да еще иОпа... это типа вот так вот... :)
type string = packed array [1..20] of char;
var a: string;
a := 'i'm dump Passal string';
----------
Просто и ясно:char *str = "i'm nice c string"
Так что, везде строка это массив символов.
>type string = packed array [1..20] of char;
>Так что, везде строка это массив символов.Это было давно и неправда. Серьезно :)
>>type string = packed array [1..20] of char;
>>Так что, везде строка это массив символов.
>
>Это было давно и неправда. Серьезно :)А серьезно это в SNOBOLE? :)
>Не путаете с Си++?Нет. В Си++ не надо знать количество элементов чтобы инициализировать константный массив. :)
>Этот продвинутый язык заставляет вас заниматься херней, чтоб вы наконец поняли....
В топку. Язык, который пытается меня поучать, пусть используют прыщавые школьники. А мне работать надо.
>...что делаете что-то не так, и что пора вынести данные из исходников во внешний файл, загружаемый в рантайме.
То есть вместо того, чтобы просто работать с обычным массивом, я должен еще подумать как его загрузить из файла? А если моя программа крутится на голой железяке в которой нет ни файловой системы, ни даже операционки?
>В Си нет строк. А в паскале они есть, да еще и с подсчетом ссылок и автоматическим управлением памятью под ними. Вот такие вещи как раз сложно унести в ядро, насколько я понимаю.
Почему сложно? Другое дело, что такие вещи в ядре и не нужны. Ядро - слишком ответственная вещь чтобы доверять управление памятью компилятору. В ядре это все контролируется и оптимизируется вручную, поэтому там нужен язык, который не учит жизни, а просто делает то, что от него требуют.
> В паскале указатель может ссылаться на не инициализируемую переменную - очень полезно для глюкоффв сях тоже можно это сделать. или подразумевалось что-то специфичное?
int *pvariInt;
int variInt;pVariInt = &variInt; // возможно, компайлер предупредит.
>pVariInt = &variInt; // возможно, компайлер предупредит.Не предупредит. С какой стати?
потому что происходит использование неинициализированой variInt
хотя, для pvariInt интересен только адрес памяти, а это уже известно. неизвестен только ее наполнитель.
>ОК. Прошу в студию примеры того, что не умеет паскаль такого, что
>умеет Си? :)А можно на паскале сформировать raw binary с предсказуемой структурой и поведением? А чтоб еще и под не самую простую архитектуру, типа гарвадрца (например, Atmel AVR, у которого флеш для кода и статичных данных, а оператива - только для временных данных и не может выполнять код вообще). Чтоб машинный код, статичные данные и динамичные данные можно было пхнуть в конкретные адреса (возможно, обитающие в разных адресных пространствах) и бинарь сразу мог бы выполняться процом из его флехи, не делая левых обращений куда попало, не ожидая никакого рантайма вообще, не нуждаясь в сложном предварительном загрузчике педалящем формат типа ELF'а и прочая. В свое такое с борланд паскалем это было напряжно. То есть, асм вставки воткнуть - можно, но вот получить гольный бинарь способный работать в нестандартном окружении - уже опаньки. А как с этим сейчас?
Грубо говоря - режим этакого "супер-ассемблера", когда компилер можно детально проинструктировать что и куда необходимо распихать, не геморроясь с выписыванием этого (или как минимум большинства из этого) на ассемблере (тем более что портировать будет сильно проще). В сях то оно с полпинка - язык для системных дел...
>Грубо говоря - режим этакого "супер-ассемблера", когда компилер можно детально проинструктировать что
>и куда необходимо распихать, не геморроясь с выписыванием этого (или как
>минимум большинства из этого) на ассемблере (тем более что портировать будет
>сильно проще). В сях то оно с полпинка - язык для
>системных дел...Это верно, но тут речь больше идет о языке, чем о компиляторе или кодогенераторе.