GCC 4.2.0

> Дык я выше

Когда я отвечал, я этого ещё не видел. :)

> Может быть вы просветите, связка компилятор паскал + TASM имеет их поддержку?

С трудом. Я системным программированием только во времена DOS занимался, так что tasm последний раз использовал только в прошлом тысячелетии. :)

Только почему связка? Встроенный ассеблер не был вызовом tasm. Это был ассемблер, удобный для написания небольших вставок/небольних процедурок. Имел приятные фичи, типа mov ax, i , где i - переменная типа integer.

Для серьёзного можно было делать именно свзяку, т.е. линковать obj файлы от любого ассемблера, не только tasm. В том числе и от любого языка программирования, способного сделать obj в нужном формате (я не помню какой там требовался).

кстати icc откровенное глюкалово. причем на полном серьезе можно получит 2х2=5 при стандартных флагах и небольшем везении. один шайтан знает сколько еше в нем грязнохаков

>нет, я имел в виду что то вроде >......

Ну, если это действительно работало в TP<=5.0, то это минус борланду (за то, что не заблокировали возможность таких костылей): кроме проблем никакой пользы подобные извращения не приносят, особенно в DOS:)

А тестовый код для паскаля писал явно человек, впервые пишущий на нём:)

> fpc -opas test.pas -O3

ЕМНИП, надо не -O3, а -OG3. А ещё лучше -OG3r. Кроме того, -OG3 эквивалентно -OG2u, а про -u вроде бы в руководстве написано, что оно может приводить и к обратному результату.

>Работа с портами ввода-вывода средствами языка; Привязывание переменных к абсолютному адресу памяти;

Ещё забыл Mem[Seg:Ofs]

:)

> Только почему связка?

Я не настаиваю. :) Просто тут проскочил лозунг, что паскаль якобы подходит для системного программирования, что там TASM вызывается...

>вроде ясно указал некоторые средства, необходимые для системного программирования.

Ты ещё про паяльник забыл:)

Здесь вобще-то языки сравнивались, пока ты не влез со своим "средствами низкоуровневого программирования". Но, хоть про то, что асм-вставки gcc обрабатывает с помощью gas ты узнал - и то польза - теперь в школе будешь хвастаться:)

>паскаль якобы подходит для системного программирования,

подходит

>что там TASM вызывается

А написал "AFAIR TASM вызывается", возможно я неправильно "R" - меня поправили. Наверное, это в Turbo C так было - перепутал, виноват, всё-таки больше 15 лет прошло:)

> А тестовый код для паскаля писал явно человек, впервые пишущий на нём:)

Да нет, не впервые.. Скажем так, впервые за последние примерно 4 года. А что не так? Я специально транслировал C-шный код, вроде аналогично получилось.

ужас...

1. s/"j := j + i"/"inc(j,i)"/ ну и соответственно s/"i := i + 1"/"inc(i)"/

2. перед end точка с запятой не нужна

1. В оригинальном паскале inc-а нет, если мне не изменяет память. в любом случае на скорость это не влияет.

2. Она опциональна, я предпочитаю ставить для консистентности кода.

begin
    i := 2;
    while i < N do begin
        j := i * 2;
        while j < N do begin
            nprime[j] := 1;
            j := j + i;
        end;

        repeat
            i := i + 1;
        until (i >= N) or (nprime[i] = 0);
    end;
    primes_count := 0;
    for i := 0 to N - 1 do begin
        if nprime[i] = 0 then
            primes_count := primes_count + 1;
    end;

    writeln(primes_count);
end.
-----------------------------------------
begin
for i:=2 to Prev(N) do
    begin
    for j:=i*2 to Prev(N) do nprime[j]:=1;
    repeat Inc(i) until (i>=N) or (nprime[i]=0);
    primes_count:=0;
    for i:=0 to Prev(N) do
        if nprime[i]=0 then Inc(primes_count);
    end;
writeln(primes_count);
end.

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

~/tmp/tests/2 $ cat test.c
#include <stdio.h>

unsigned fib(unsigned n)
{
  if (n == 0 || n == 1)
    return 1;
  
  return fib(n - 1) + fib(n - 2);
}

int main(void)
{
  printf("%d\n", fib(43));
}
~/tmp/tests/2 $ cat test.pas
program fibonacci;

function fib(n : longword ) : longword;
begin
   if (n = 0) or (n = 1) then
      fib := 1
   else
      fib := fib(n - 1) + fib(n - 2);
end;

begin
   writeln(fib(43));
end.
~/tmp/tests/2 $ gcc -O3 test.c -o c
~/tmp/tests/2 $ time ./c
701408733
3.206 secs
~/tmp/tests/2 $ time ./c
701408733
3.171 secs
~/tmp/tests/2 $ time ./c
701408733
3.168 secs
~/tmp/tests/2 $ fpc -O3 -opas test.pas
Free Pascal Compiler version 2.0.4 [2007/01/28] for i386
Copyright (c) 1993-2006 by Florian Klaempfl
Target OS: Linux for i386
Compiling test.pas
Linking pas
12 Lines compiled, 0.0 sec
~/tmp/tests/2 $ time ./pas
701408733
9.049 secs
~/tmp/tests/2 $ time ./pas
701408733
8.949 secs
~/tmp/tests/2 $ time ./pas
701408733
9.178 secs

Ну и про опции компиляции тебе уже сказали:)

> Просто тут проскочил лозунг, что паскаль якобы подходит для системного программирования, что там TASM вызывается...

Я писал, что это не так. :) Паскаль? Ну, подходит. Примерно в той же мере, что и C. Я встречал операционку, написанную на FPC. Не как убийцу Linux, а for fun. Для обучения.

Системное программирование (близко к ядру) это вообще настолько узкая область, что для неё вообще не нужно обилие инструментов. Не учитывается, что кроме паскаля модули ядра *обычно* не пишут на: D, Erlang, Forth, Ada, Java, C#, C++, Objective-C, OCaml, Haskell, Lisp. ;-) На ассемблерах, в чистом виде, тоже не пишут, кстати. :)

> for j:=i*2 to Prev(N) do nprime[j]:=1;
Здесь надо итерироваться с шагом i

> repeat Inc(i) until (i>=N) or (nprime[i]=0);
test2.pas(13,12) Error: Illegal assignment to for-loop variable "i"

И вообще
test2.pas(10,13) Error: Identifier not found "Prev"

> Ну и про опции компиляции тебе уже сказали:)

Не заметил.

Арифметике действительно помогли на полсекунды быстрее работает. Но медленнее чем gcc.

А вот фибоначчи не помогли.

> в любом случае на скорость это не влияет.

fpc:

i:=0; while i<0x10000000 do inc(i,l)

$ time ./a

real 0m0.583s

i:=0; while i<$10000000 do i:=i+1

$ time ./a

real 0m0.726s

> 2. Она опциональна, я предпочитаю ставить для консистентности кода.

возможно зависит от компилятора...

s/"0x10000000"/"$10000000"/ естественно, просто начал писать здесь, ещё до компиляции :)

PS результаты по другим попыткам примерно такие же

У меня эти примеры работают абсолютно одинаково. Довольно странно вообще, если inc это формально процедура, то она не должна быть быстрее оператора присваивания. Хотя кто его знает..

> Довольно странно вообще, если inc это формально процедура, то она не должна быть быстрее оператора присваивания. Хотя кто его знает..

В Borland варианте Inc был макросом, типа write. В FPC поддерживаются inline. (В последних Delphi, впрочем, тоже). Остальное надо смотреть в исходники, которых под рукой нет.

>function fib(n : longword ) : longword;
begin
   if (n = 0) or (n = 1) then
      fib := 1
   else
      fib := fib(n - 1) + fib(n - 2);
end;


В принципе, это не полностью эквивалентный C-варианту код.
Для freepascal так, пожалуй, будет более идентично:

program test;
{$mode objfpc}
uses
    UnixType; // чтобы использовать тип culong

{$OVERFLOWCHECKS OFF}
function fib(n : culong): culong;
begin
   if (n = 0) or (n = 1) then
      exit(1);
	     
   Result := fib(n - 1) + fib(n - 2);
end;
{$OVERFLOWCHECKS ON}
		
begin
   writeln(fib(43));
end.

$ diff ./incon.pas ./incoff.pas

3c3

< inc(i)

---

> i:=i+1

$ diff ./incon.s ./incoff.s

1c1

< .file "incon.pas"

---

> .file "incoff.pas"

17c17,19

< incl U_P$PROGRAM_I

---

> movl U_P$PROGRAM_I,%eax

> incl %eax

> movl %eax,U_P$PROGRAM_I

PS fpc 2.0.4, ключи не использовались

Да-да, о проверках вечно забываешь. :)

>Системное программирование (близко к ядру) это вообще настолько узкая область, что для неё вообще не нужно обилие инструментов. Не учитывается, что кроме паскаля модули ядра *обычно* не пишут на: D, Erlang, Forth, Ada, Java, C#, C++, Objective-C, OCaml, Haskell, Lisp. ;-) На ассемблерах, в чистом виде, тоже не пишут, кстати. :)

В NT пишут дрова на плюсах только в путь (да и у самой NT хороший % кода написан на плюсах)... ну и для линукса был экспериментальный фреймворк

>Имеет смысл добиться, чтобы проект собирался любым компилятором. Однако переводить проект со специально оптимизированного под конкретную программную платформу компилятора на компилятор под неё не оптимизированную скорее всего не следует. Насколько я знаю, Intel С++ покупают те, кому его оптимизация действительно критична. Если же собираете програмки вроде два-окна-четыре-кнопки, то сомневаюсь, чтобы Вы использовали Intel C++.

icc/fpc любит HPC-шники из за поддержки OpenMP а с недавнего времени и Cluster OpenMP. Причём код получается вполне приличным по скорости как для Intel там и для AMD (как это ни странно) процессоров. Правда с выходом subj-вого gcc с поддержкой OpenMP "из коробки" (раньше он был как отдельный бранч) будем посмотреть кто кого ;)

PS: На моём коде gcc+PVM/MPI рвёт icc+MPI как тузек грелку...правда видимо сказывается 10 летний цикл непрерывной заточки кода именно под gcc

Дожили...

В треде про выход GCC 4.2 обсуждаем паскаль.

s/fpc/ifc/ конечо же ....

>ну и для линукса был экспериментальный фреймворк

А можно по-детальнее? Ссылки всячески приветствуются. (Просто сам уже подумывал писать нечто подобное;))

>Дожили... В треде про выход GCC 4.2.0 обсуждаем паскаль.

Да прям уж, дожили, в новости про 4.0.0 обсуждали "c=0; c=c++", а теперь пытались обсудить '++i + ++i', но скатились в Паскаль.

> В NT пишут дрова на плюсах только в путь

И тем не менее, я бы просил не передёргивать и не уводить в сторону. Я сказал "модули ядра". Когда в NT найдутся модули ядра, тогда... А пока... :)

> ну и для линукса был экспериментальный фреймворк

Интересно, я для чего слово "обычно" выделял? Мало ли что эксперементальное было? Это как раз подтверждает особенность ниши драйверов/модулей. Там используется тот инструментарий, который рекомендует разработчик. Всё, что не вписывается в эту схему - не приживается. M$ предлагает использовать C++ - оно живёт. В линукс это не принято и никакой фреймворк не помог.

>perl -e '$i=5; print ++$i + ++$i,"\n"'

>14

Неудачный пример... У прела все наоборот. Что сделает следующая команда:

$a[$i++] = $i ?

>perl -e '$i=5; print ++$i + ++$i,"\n"'
>14
>Как видите.

Тогда Perl вообще алогичен. Ибо:

perl -e '$i=5; print $i++ + $i++,"\n"'
11

:D
(собственно, исследования на на такой форме в своё время и проводил)

Экий, Perl забавный-то :D

>if (n = 0) or (n = 1) then

Гы. if(n<2) он не умеет? :D

Вот вам 40 страниц готового флуда по теме c++ / pascal что б не мучили зря клаву.

http://www.sql.ru/forum/actualthread.aspx?bid=24&tid=400116

на icc гнать не надо - в принципе неплохой компилер, и код icc ~8.1 давал побыстрее чем gcc 3.~1. Почему-то экономия на системных вызовах была до 10%!. Мы тут было хотели на него сползти, однако появился gcc новый ~3.4 и этот icc уделал, и язык как будто с icc драли :-) - те же коррекции пришлось делать - ну там для предварительного разрешения имён template пришлось this-> повставлять местами. И мы остались на gcc. Так что лучше сначала свои тесты скомпильте под обои - и нам сообщите - будет интересно. Вдруг icc снова царь горы?

> Гы. if(n<2) он не умеет? :D

Умеет. Но в c-шном аналоге было "if (n == 0 || n == 1)", поэтому и для паскаля использовалось "if (n = 0) or (n = 1) then"

Была же на ЛОРе новость. Я даже чего то пробовал на нём по приколу.

>И тем не менее, я бы просил не передёргивать и не уводить в сторону. Я сказал "модули ядра". Когда в NT найдутся модули ядра, тогда... А пока... :)

Месье так шутит ?

В WINDOWS/system32/drivers загляните. Все как один *.sys вполне себе "модули ядра" .... по смыслу разумеется а не по названию

>> ну и для линукса был экспериментальный фреймворк

>Интересно, я для чего слово "обычно" выделял? Мало ли что эксперементальное было? Это как раз подтверждает особенность ниши драйверов/модулей. Там используется тот инструментарий, который рекомендует разработчик. Всё, что не вписывается в эту схему - не приживается. M$ предлагает использовать C++ - оно живёт. В линукс это не принято и никакой фреймворк не помог.

В Linux принято экспериментировать, благо платформа открытая, или вы не заметили ? ;)

http://netlab.ru.is/exception/LinuxCXX.shtml

Только не уверен то или нет. ЛОРОвский поисковик жутко тормозной и выдаёт результаты не по релевантности а чёрте по чему....саму новость не нашёл

Посмотрел патч - имено это и пробовал ;)

> Месье так шутит ?

Отнюдь. Именно по названиям мы их и различаем. Тем более, что для Win* вообще разговора нет. Там есть драйверы, написанные на Object Pascal. В том числе и под nt, точнее, под 2k+, т.к. vdm.

(Что бы исключить неправильное понимаение - есть - не в поставке от M$)

> В Linux принято экспериментировать, благо платформа открытая, или вы не заметили ? ;)

С какой целью это было сказано? Оно что-то иллюстрирует? Ну написал кто-то for fun. С тем же успехом я могу сделать модуль на FPC for fun. Дальше-то что? Передо мной не стоит задачи написания модуля, вот я её и не делаю.

Вообще, это мегалол. Типа, исключительность в написании модулей, всегда вылезает в спорах C[++] vs. Pascal. Когда приводят примеры того, что и паскаль может, начинаются вихляния, типа это никому всё равно не нужно. Но самое интересное, это то, что из говоривших про модули, писали их в лучшем случае - единицы. Мегааргумент.

>Отнюдь. Именно по названиям мы их и различаем

Пацтулом =) "Мы" это кто ? ;)

>Вообще, это мегалол. Типа, исключительность в написании модулей, всегда вылезает в спорах C[++] vs. Pascal

Я в упор не понял причём тут C++ vs Pascal ?

Речь шла о языках на которых пишется код кернельных драйверов/модулей

Вам наглядно показали что это не только C/asm

К слову сказать есть мегаудобные фреймворки для написания драйверов на C++ в NT. Конечно оно не "кernel boost" но то, что сделано в даном плане в ядре линукс выглядит либо просто убого либо представляет собой набор лисапедов (по собственному лисапеду на драйвер). К слову сказать наверное это можно было бы написать и на C.

> Экий, Perl забавный-то :D
Он не забавный. Он очень аккуратный Ж-)
print ++$i + ++$i; это ++$i; ++$i; print $i + $i
а
print $i++ + $i++; это ++$i; print $i + $i; $i++

Пасквилянты опять пыжатся, только дальше windows kernel который кажется только и умеет что вирусы поддерживать ничего системного не написали. А вот на C, извините но kernel на 4K процов уже существует по факту, и знаете ли, не падает. Так что все эти заявления, что мол pascal был бы лучше и т.д. можно смело сливать, так как программист не мыслит сослагательно, иначе это не программист а политик.

> Я в упор не понял причём тут C++ vs Pascal ?

Я тоже не понял. Не я здесь начал про паскаль.

> Речь шла о языках на которых пишется код кернельных драйверов/модулей

Не шла. Взяли и в очередной раз полили грязью паскаль. Вообще, это наводит на размышления. Де факто, по количеству использующих, C и C++ победили паскаль. Причём давно. Однако, сущствование большого количества тех, кто до сих пор его пинает наводит на разные размышления. О том, за счёт чего была эта победа. У настоящих победителей такого комплекса неполноценности не бывает.

>Я тоже не понял. Не я здесь начал про паскаль.

Да ну ? ;)

>Не шла. Взяли и в очередной раз полили грязью паскаль

do {
http://www.linux.org.ru/jump-message.jsp?msgid=1923981#1925421
} while( true );

;)