Okay, then let's start a real discussion here...

The programming language Pascal unfortunately has a really bad reputation amongst programmers and in the hacker scene. They call Pascal a "bondage-and-discipline language". There's even yet a fixed proverb out: "real programmers don't use Pascal".

For the arguments read the article about Pascal from "The New Hackers Dictionary" (aka "jargon file") and the related articles:

http://tuxedo.org/jargon/html/entry/Pascal.html

Okay, the paper, they refer to is from 1981 and lots of the limitations of standard Pascal don't relate to FPC. But then they can say, it's not a common standard, so your Pascal is not Pascal, it's proprietary, it's not portable.

So, what do you think, how can we argue against them? What about publishing our own paper?
What else could we do for the reputation of Pascal?

Andreas K. Foerster wrote

What else could we do for the reputation of Pascal?

Personally, I couldn't care less about the reputation of Pascal :) It's the language I first learned and of all languages I know (Pascal, C, C++, Java, Haskel, Prolog) it's the one in which i can express my thoughts the best. I think you should always use the language you're most comfortable with or because it's the best for a certain purpose, not because other people think it's cool or not.

Regarding the fact that most Pascal implementations are not standardized: that simply a fact you can't do much about. It is obviously a negative point, but that doesn't mean the language (or dialect) itself is bad.

Jonas

Andreas K. Foerster wrote

The programming language Pascal unfortunately has a really bad reputation amongst programmers and in the hacker scene. They call Pascal a "bondage-and-discipline language". There's even yet a fixed proverb out: "real programmers don't use Pascal".

This may be true, if you definitely WANT to do "dirty" things, like mis-using pointers as integers and similar things, but exactly this is normally not required.
When my son started to learn at school C and C++, I was forced to get in touch with C/C++ a little bit. And I can tell you, I will never use I need, is exactly what you mentioned above: -------------------------------------------------
A programming language which forces me to use correct syntax and disallows dirty things. It must be flexible enough to fit to my major needs, give me access to the OS's API's when required, and do most trivial things internally. -- And all that can be found within one language: PASCAL. It is no wonder, that Pascal is a "technical language", and that I choose it a long time ago, because I _am_ a technician...!
(An example: Have you ever tried to work with "strings" or "arrays of string" in C language? Strings are a very basic thing to me, but C makes an odysee out of that!)

Okay, the paper, they refer to is from 1981 and lots of the limitations of standard Pascal don't relate to FPC. But then they can say, it's not a common standard, so your Pascal is not Pascal, it's proprietary, it's not portable.

Not true... As long as you use standard pascal syntax and limit yourself to only use Standard (ANSI?) pascal, it IS portable! It is the same as if you would use plain C (as far as I understood this "Deluxe-Assembly-Language"). If you do not use system-dependent functions, it is portable. But when you use them, you'll get a lot of work when changing to a different OS....

mfg

Ing. Rainer Hantsch

Hi!

Am Die, 2002-06-04 um 13.14 schrieb Rainer Hantsch: [ ... ]

You speak out of my heart.

I have to use plain C sometimes, so I managed to work with it. I've even written a few programs/modules without a curse! *beingproudofme* ;-)

Then I thought, ok, C isn't that bad, except the few dirty things. But soon in a lecture on our university ("digital signal processing with C") I learnd to hate it again. Pointers are so silly in C. And everybody has to learn how they work right at the beginning, because nothing works without pointers.

My father told my, that all C programmers are so proud of the pointer capabilities of C. Yes, sure, they've never seen anything else. When learning Pascal, there was no need, because you only need pointers for enhanced problems. But they switched to C before they came to use pointers in Pascal. Then they saw pointers in C and, wow, pointers!

But types in C are more ugly too. You can't declare a PInteger as a pointer to an Integer. You have to use the star '*' every now and then. My professor said (laughing) he only needed three (3) stars in series at most! Can you imagine? (int ***matrix) ??? Pfui! No self defined types?

The problem on Pascal's reputation is it's reputation. If you come somewhere and tell them, you are a good Pascal programmer, eeeverybudy will set up a smile! Most Pascal programmers don't even dare to say they use Pascal! Pascal's reputation is so bad, because it's not publicly known what Pascal can do. Most people learnd programming with Pascal. Then, when they got a bit of the clue, they had to switch to C. And then they think, Pascal is only able to do simple things. And perhaps they have bad memories on Pascal (which comes from their inability to program in the beginning, not from Pascal, but they project it onto). And, nowadays it's cool to speak bad about Pascal. This kind of selfdefined cool guys, which let me define the word "cool" as something very bad. :-)

Bye
Hansi

Okay, then let's start a real discussion here... The programming language Pascal unfortunately has a really bad reputation amongst programmers and in the hacker scene.

No. In the C and C++ scene. This is not the same thing, even if they like to pretend that.

They call Pascal a "bondage-and-discipline language". There's even yet a fixed proverb out: "real programmers don't use Pascal".

If you start discussing with them, all this nonsense is founded on very old standard Pascals.

For the arguments read the article about Pascal from "The New Hackers Dictionary" (aka "jargon file") and the related articles: http://tuxedo.org/jargon/html/entry/Pascal.html

Written by ESR, a known C advocatist afaik.

Okay, the paper, they refer to is from 1981 and lots of the limitations of standard Pascal don't relate to FPC. But then they can say, it's not a common standard, so your Pascal is not Pascal,

There are several compilers that implement it, some of which are free. K&R C never was an official standard, but that also never stopped anybody.

it's proprietary, it's not portable.

Let them name the inportabilities. They can't.

Most C isn't portable anyways. They all use propietrary extensions too.

Even GNU does. And since they are not standard, they are proprietary :-)

So, what do you think, how can we argue against them?

Don't waste too much time on it. I often engage in language discussions, but I somewhat like the discussion (an infection I probably got from

What about publishing our own paper?

Won't help. There are several answers on the "Why Pascal is..." article, and they rarely get quoted.

Making a nice, balanced advocatism site would make it easier to refer to and counter some common misconceptions though.

What else could we do for the reputation of Pascal?

Make great programs. 99% of the trolls don't have a clue, and convincing them won't help Pascal a bit. Availability of tools, examples and source might.

... caught on fidonet, just like the habit of not finishing sentences)

Maybe this is a nice task for Jedi, since this goes for Delphi too.

Hi,

Andreas K. Foerster wrote

The programming language Pascal unfortunately has a really bad reputation amongst programmers and in the hacker scene. They call Pascal a "bondage-and-discipline language". There's even yet a fixed proverb out: "real programmers don't use Pascal".

This is my _FAVOURITE_. :) We once had a discussion on this topic with Arpad Gereoffy (author of MPlayer), who is of course a C programmer. This was a few years ago, when Arpi and myself was very active on the hungarian demoscene. Arpi declared Pascal as an 'anti-programming' language. :) After that, on the demo compo we competed Arpi's 'elitez-make-demos-in-C' stuff with our little thing made in a lame 'anti-programming' language. And we won. FPC forever. ;)

For the arguments read the article about Pascal from "The New Hackers Dictionary" (aka "jargon file") and the related articles: http://tuxedo.org/jargon/html/entry/Pascal.html

Yeah, another yood thing. C lovers always comes with this stuff. :) They doesn't have better things against Pascal than this ancient article?

So, what do you think, how can we argue against them? What about publishing our own paper? What else could we do for the reputation of Pascal?

There was a reply for the article you told above, but i can't found the URL between my bookmarks... :/
Anyway, i don't think we should argue against them... Do as we did in the democompo. Don't argue, simply beat 'em! ;)

Bye,

Johann Glaser wrote

Am Die, 2002-06-04 um 13.14 schrieb Rainer Hantsch: But types in C are more ugly too. You can't declare a PInteger as a pointer to an Integer. You have to use the star '*' every now and then.

This is TYPICALLY "C" language. It is a "better assembly language" in my eyes, not able to do the simplest things without requiring a bunch of libraries, where all this stuff is already coded. And if you have a look inside these libraries, ... - better you DON'T...!

My professor said (laughing) he only needed three (3) stars in series at most! Can you imagine? (int ***matrix) ??? Pfui! No self defined types?

...and be aware of forgetting only one "*" or "&" if you are working with such vars! "C" is definitely stupid enough to compile without any related warning and brutally overwrites that memory. -> Application Crash -> And here you will need a longer while to find ot the reason!
Thus, in Pascal you will get probably an compiler error, saying something like "Illegal pointer type" or so! -> It couldn't come out clearer, where the problem is located!

The problem on Pascal's reputation is it's reputation. If you come somewhere and tell them, you are a good Pascal programmer, everybody will set up a smile! Most Pascal programmers don't even dare to say they use Pascal!

I watch the same with people programming in "Visual C++" or "Visual Basic". Sounds great, this "Visual", and then it is related to: "Oh, he can program Windoze! - Whow..."
And then you see applications which do nearely nothing but need Megabytes for that. I do not want to know the size of a simple program which does nothing else than opening a simple window and writing "Hello world" into it!

But if Pascal would really be so bad: Why is JAVA so much similar to it? So Pascal can't really be such outdated, as all this "C" guys say...

I agree to 100%. - But let me tell you how I came to Pascal.

I am meanwhile 42 years old. With roughly 20-21 years, I did my first steps of "real programming" on a self built Industrial PC with a 3 MHz Z80 CPU, 64kB(!) RAM, and a 10MB SASI Harddisk (No mis-typing! SASI, which was before SCSI!). The OS was CP/M plus, the screen was an ADM-3A Terminal over a serial line. You see, a real "PowerMachine", but it was extremely expensive at that time. (More than 4360,00 Euro, if I remember right!) I started with MBASIC80 (Microsoft Basic for 8080 CPU's), because I knew BASIC from my younger brother's C=64 and wrote some programs for calculating and dimensioning central heatings. Later, I also used the basic Compiler to get TOP performance. -> Sorting a "file of record" with 1000 entries needed then "only" some hours(!), rather than a whole night... -> "Great!" =8-O

Later, I asked a friend. He gave me a 8"-floppy with "TurboPascal 3.0 for CP/M". I tried it out and found that it was ... a.) Easy to understand (especially in comparison to C!) b.) Worked much easier with structured files
c.) Allowed me better access to the whole Screen/Printer/... d.) EXTREMELY FAST.

Within a relatively short time I ported all of my BASIC programs to it. It was phantastic. Jobs which ran before for hours(!), needed now only a few minutes! The speed increase whas more than 1:50!
From this moment I developed always in TurboPascal. First on CP/M, later on DOS, but I always could use my old sources. (-> This about portability.)

Then I started with Windoze - and I decided to leave this out. A good decision, now I work on LINUX, and I still can re-compile my old TP7 programs and use them natively on LINUX after some minor changes (filenames,...).

So: WHERE ARE THIS PORTABILITY PROBLEMS? I SEE NONE!

And, nowadays it's cool to speak bad about Pascal. This kind of selfdefined cool guys, which let me define the word "cool" as something very bad. :-)

I would say it is not "cool", it only points out the knowledge of these guys...

mfg

Ing. Rainer Hantsch

Hi,

forced to study C more deeply than i did it before. I don't like most things in C, but there are a few things in it what can come handy, and now i'm missing it from Pascal.

For example the static lists. Maybe they're possible in Pascal too, but i can't find a word about them in FPC docs. They really can make a lot of things easier. And there are a few more things in C, which you can use more freely (beside the free mis-use of language elements you told above) so Pascal really 'bondages' you in these cases. Also, C allows more extensive use of macros, but this is only a compiler issue, IMO.

But there are still three things i _hate_ in C.

1., The headers are separated from the rest of the source. It can be a real pain in larger projects to dig up what's declared in where, and vice-versa. I saw sources, where the programmers avoided this with keeping everything in a single .h file (which was more than 300k...). Cool eh? ;) And the makefiles. Of course, makefiles can be handy in larger projects. But in C, you simply must use them in projects with more than two .c files, if you don't want a nervous wreck.

2., The string 'handling' or we can say the lack of it? Needless to say, this makes the most problems with C. This is the reason of most bugs in software written in C. For example, thoose buffer-overflow problems in the networking stuff, and such. Of course i don't mean using Pascal (and Pascal-alike programming style) should avoid all of thoose bugs, but it should be a protection against most of them.

3., Lack of namespaces. (With <...> Do stuff.) Okay this feature is implemented in C++, but missing from C. It can be a real pain, when you working with deep structures. But, you can solve the problem, with macros, or with direct pointers to deeper elements. Pfui... ;)

Bye,

Keep in mind that you cannot raise the reputation of Pascal by just blaming C. As Marco pointed out, "all" we need is great programs written in Pascal. As long as the great majority of serious stuff (like games) has been written in C++, everyone going to start a bigger project gets the clue that C++ is certainly a safe choice for him - and I cannot blame him for that. Also, important APIs like that of Windows, OpenGL, ... have been designed to use with C; plenty of good stuff requires support of C++ classes - in fact, C(++) is kind of standard nowadays. You cannot avoid it, a useful compiler (of whichever language) needs to support it.

We all in this list know that Pascal _is_ a good choice, we needn't tell it to each other. Andreas raised the question of improving Pascal's reputation, not degrading that of C - which is hopeless :-)

------

Ingmar

------

"Salamanders can survive up to six hours outside a fire if regularly fed pepper" (Scamander 1927).

They say Pascal ist closed. But who sais so?
What about a new standard?
Who defines standards?

Btw. what do you think about the "Extended Pascal" standard? (which FPC doesn't follow)

At least he's the publisher.

a known C advocatist afaik.

He did a lot of things in C.
But IIRC he wrote once, that C should only be used if absolutely necessary.
I think he mostly prefers LISP.

Good argument.

Even GNU does. And since they are not standard, they are proprietary :-)

LOL ;-)))
We should ask RMS what he thinks about that. ;-)

> What about publishing our own paper? Won't help. There are several answers on the "Why Pascal is..." article, and they rarely get quoted.

Can you give me some links.
Then _I_ could quote them. ;-)

Making a nice, balanced advocatism site would make it easier to refer to and counter some common misconceptions though.

Good idea.

> What else could we do for the reputation of Pascal? Make great programs. 99% of the trolls don't have a clue, and convincing them won't help Pascal a bit. Availability of tools, examples and source might.

Rainer Hantsch wrote

(An example: Have you ever tried to work with "strings" or "arrays of string" in C language? Strings are a very basic thing to me, but C makes an odysee out of that!)

AFAIK the official Pascal standard doesn't even know about strings at all. If you realy want to program standard Pascal programs that use text, you have to use ARRAY OF CHAR.

[portability]

If you really want to stick to the standard, then I think C is really better. (see above)

BTW. why does anybody here speak about C and not about other languages? I didn't even mention C in my first posting.

It is not related to the discusion topic, but maybe fun too...

"Why C is not my favorite language?"

http://www.cs.virginia.edu/~wz5r/cs655/whycnot.htm

Good day for you, Johann!

Tuesday, June 04, 2002, 5:32:13 PM, you wrote:

The Pascal language as C and other languages based on Machine of Tyuring (how it's writing?), so there is no major differences in posibilities of any language. I like pascal because I learned it first, but I have to look at C because there is many public sources and libs on C/C++. And I don't know how some tasks may be solved in pascal. For example, I don't know how can I made .VXD driver for windows. Main skate of C is that C - language for system programming. Also, C-compilers allows to build embedded applications and so on. Maybe pascal should go to system language?

-- Someone who loves to program and enjoys being clever about it

and yet another article

http://www.moorecad.com/standardpascal/clang.html

----- Original Message -----
From: "Paul Yanchenko"

Hi, first of all say that I'm happy to see such activity in fpc-other! I thought I was the only one subscribed to it ;)

Pascal, C and Java among others are general purpose languages, so they are capable of do almost everything in a computer, from OSs to CGI applications. Recently I was discussing with some friends to start developing a video game, the first point of argue was which language use C o Pascal. Every one of us have a diferent predilection, I prefer Pascal, the other C and the other C++. We couldn't decide which one use since everyone have its own good and bad points. At the end we decided to develop it in the 3 languages and then link them together. But the problem is that FPC is not able to use C++ libs so we've got to stick to C and Pascal :(
So if we want to make Pascal a good choice for commercial programming I think that the first thing to do is the ability to use C++ libs. If you only can do VxD with C, then do it in C but you can always have the posibility to develop the app in Pascal.

Ciao, Ivan

Ivan Montes wrote

> Main skate of C is that C - language for system programming. > Also, C-compilers allows to build embedded applications and so on. > Maybe pascal should go to system language?

I think, that's nor question of the language, but of the implementation. Of course FPC can still be improved.

So if we want to make Pascal a good choice for commercial programming I think that the first thing to do is the ability to use C++ libs.

Could you do this?

Hi there,

Tuesday, 04 June, 2002, 21:38:42, Paul Yanchenko wrote: [...]

pascal. For example, I don't know how can I made .VXD driver for windows. Main skate of C is that C - language for system programming. Also, C-compilers allows to build embedded applications and so on. Maybe pascal should go to system language?

I think .VxD problems are rather Mr. Gates' problems, not Pascal's :))) Now seriously. This generally seems to be an interesting point. Several years ago I wanted to have fun and created some *very* small (test-purpose) 32-bit "operating system" (ok, control program) for my i486, which was able to provide some file access, console I/O, and run some simple text-based executables. Just kind of demo. Well, actually I even managed to run FAR (text-mode user shell for Windows, similar to GNU's Midnight Commander) with it. The "operating system" binary size was 180K, it booted in half a second, and - applause, please - it was coded in Pascal (mostly, + assembler). Well, more precisely, in Borland's Pascal 9, mostly known as 'Delphi 2.0'. This was before I got to linux, so the project depended heavily on closed-source win32 tools and I got stuck missing some important compiler features and finally found that win32 operating environment design is somewhere brain-damaged. At that point the project died. (Later, I found I was a bit brain-damaged too :)
Still, I personally have a feeling that modern Pascal (like Borland's or FPC perhaps) is in partucular suitable for building and maintaining a _large_ project such as an operating system. Why not? Does anyone know some real obstacles, or perhaps such kind of project exists already?

Still, I personally have a feeling that modern

Pascal

is in particular suitable for building and

maintaining

a project such as an operating system. or perhaps such kind of project exists already?

Well, it's not exactly Pascal, but close ...
http://www.oberon.ethz.ch/

__________________________________________________ Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Modula2 (inbetween Pascal and Oberon in the Wirthian pedigree) was also designed for systems programming.

Borland made a Turbo Modula2 for CP/M, and BPs extensions to ISO pascal are afaik a hybrid of Modula2 and the (then draft) for Extended Pascal.

Hi!

System programming with Pascal is a very interesting task. My attempt to write a small operating sys was totally in assember (Turbo Assembler), because I had control over memory regions, ...

When you wrote your OS with Delphi, I guess you made .exe files or at least .dll files. But therefore you have to implement a loader for it. Did you? Is it very difficult to write a loader for .exe, .dll or (far better) for ELF binaries?

Yesterday I had a closer look to the Infineon TriCore TC1775 microcontroller. It is a 32 bit µC with looots of funny things inside. (but it is a BGA329 package, but I'll manage that ;-) ). I thought of writing a nice assembler for Linux, GPLed of course. But only assembler is a bit poor, so I thought of extending FreePascal to use that assembler.

My question: How difficult and how much work is it to extend FPC for that processor? Some time ago I heard of a new internal structure to easily implement newer processors. Is that restructuration already in 1.1?

Additionally this Pascal would have to be more complex than normal FPC, because I'd need interrupt procedures like in Keil C for the Infineon C166. e.g.

Procedure TimerISR; interrupt 12;
Var Counter : LongInt; static;
Begin
  if P12.2 = 1 then
    Inc(Counter);
End;

Here are three specialities:
1) "interrupt 12" ... this should tell the compiler to automatically put this procedure to the interrupt vector table (or whatever the µC uses)
2) "static" ... this variable should be static. I think using "Const" instead of "Var" would do the job.
3) "P12.1" ... direct access to bits of bit addressable registers/memory

Additionally the TriCore has a second Peripheral processor inside, which has other opcode set and its own data and code memory. ISRs can be executed there instead of the main core CPU. Lots of interesting features, and I'd love to have them in FPC. :-) I would help to implement that. But, is it possible?

Another thing interesting me: can FPC give me a binary file instead of an executable. So that the first byte starts with real code, as a MS-DOS .com or .bin file did?

How can one avoid to use the System unit? I only want a few procedures, which don't need so many system functions. The Linux kernel itself doesn't use libc either. (BTW: It is not nice to see a tiny FPC program with 80kB executable, where a far more complex C program only has 7k. I don't care, but how to argue to others?)

Bye
Hansi

I'am too lazy to look up the web for the instruction set of TC1775 :) but what kind of instruction set does it use?

Some time ago I heard of a new internal structure to easily implement newer processors. Is that restructuration already in 1.1?

Yes, a lot is already done though it isn't finished yet.

No problem.

2) "static" ... this variable should be static. I think using "Const" instead of "Var" would do the job. 3) "P12.1" ... direct access to bits of bit addressable registers/memory

This is a little bit more difficult, but it is possible.

Possible is everything, it's a matter of doing the work :). A compiler port to another processor is always hard work, the necessary work depends on the complexity of the target processor. If you're seriously interessted, ask via fpc-devel or me in a personal email.

Another thing interesting me: can FPC give me a binary file instead of an executable. So that the first byte starts with real code, as a MS-DOS .com or .bin file did?

It simply depends on the linker you use. FPC itself (can) output(s) assembler so it's up
to you to use the right assembler and linker.

How can one avoid to use the System unit?

You can use a dummy system unit, for the basic types like integer etc. a tiny system unit is necessary. I guess it's already available in rtl/fakertl. For an example for a small system unit have a look at PalmOS System unit (rtl/palmos).

At least for go32v2 I can say that it contains the dos extender as well. Further,
pascal contains a lot of "hidden" code for run time error handling etc. This leads to a hello world size for win32 of 14kB (1.0.6, options -XX -Xs).

Hi,
Sunday, 09 June, 2002, 12:38:10, Johann Glaser wrote: [...]

When you wrote your OS with Delphi, I guess you made .exe files or at least .dll files. But therefore you have to implement a loader for it. Did you? Is it very difficult to write a loader for .exe, .dll or (far better) for ELF binaries?

Well, yes, I wanted to parse 'PE' (32bit flat) .exe and .dll executables, and it was messy I remember. Partly, because of lack of _proper_ info in MS world. Perhaps this got better by now with the help of open-source people. Anyway, I didn't try to provide much compatability, just wanted _something_ to work.

[...]

Well, actually interrupt handling on many (regular) systems involves much more stuff than just a handler pointer and a number. For example, think of shared IRQs, which are quite common. And, it is heavily platform-dependant. I definitely do not believe that it is a good idea for an abstract language compiler to deal with this internally. It is an operating system job. And, I see no reason why this could not be implemented nicely using existing compiler abilities. Ups, I guess I see one :)) Bit fields, perhaps? Would be nice to have them when manipulating some hardware-defined stuff. And, yet, this is not platform-dependant (I guess).

2) "static" ... this variable should be static. I think using "Const" instead of "Var" would do the job.

Isn't it enough to just declare it outside the procedure?

[...]

Another thing interesting me: can FPC give me a binary file instead of an executable. So that the first byte starts with real code, as a MS-DOS .com or .bin file did?

It's not that difficult to unpack 32-bit .exe to a plain memory image.

How can one avoid to use the System unit? I only want a few procedures,

I'm not yet familiar that much with FPC but no doubt a good compiler _must_ be able to compile some standalone unit without making external references. IIRC it is possible to make Delphi do it, for example. [...]

Nikolai Zhubr wrote

I see one :)) Bit fields, perhaps? Would be nice to have them when manipulating some hardware-defined stuff. And, yet, this is not platform-dependant (I guess).

A set is a bitfield, although only 4-byte and 32 byte sets are supported currently.

> How can one avoid to use the System unit? I only want a few procedures, I'm not yet familiar that much with FPC but no doubt a good compiler _must_ be able to compile some standalone unit without making external references. IIRC it is possible to make Delphi do it, for example.

You can't do it in FPC. You can compile your own minimalistic system unit (have a look at the template directory in the rtl sources) and make the compiler use that, but then you can't use a lot of language features (such as string operations), since these require helpers from the system unit.

Jonas

I already wrote a reply to "why pascal is not my favorite language", which seems to get quite a few hits, despite the fact that I havn't advertized it.

Put it this way.. pascal wasn't used very much when it was in the RFC stage. Borland's pascal came along and became the standard. All of the other newer pascals are more or less compliant. (in fact, delphi/kylix is the least compliant when you look at stuff like CRT unit support).

so if I can compile the same program under FPK, Turbo7, PurePascal, VirtualPascal, and Delphi.. it's pretty standard to me. Turbo lacks some older things, and Delphi lacks some newer things. The things delphi lacks have already been added by various programmers, and the things turbo and pure lack, I have written a lot of compatability libraries to address. (although I can't magically add compiler keywords, etc.!)

-- noah

I'am too lazy to look up the web for the instruction set of TC1775 :) but what kind of instruction set does it use?

Some time ago I heard of a new internal structure to easily implement newer processors. Is that restructuration already in 1.1?

Yes, a lot is already done though it isn't finished yet.

No problem.

2) "static" ... this variable should be static. I think using "Const" instead of "Var" would do the job. 3) "P12.1" ... direct access to bits of bit addressable registers/memory

This is a little bit more difficult, but it is possible.

Possible is everything, it's a matter of doing the work :). A compiler port to another processor is always hard work, the necessary work depends on the complexity of the target processor. If you're seriously interessted, ask via fpc-devel or me in a personal email.

Another thing interesting me: can FPC give me a binary file instead of an executable. So that the first byte starts with real code, as a MS-DOS .com or .bin file did?

It simply depends on the linker you use. FPC itself (can) output(s) assembler so it's up
to you to use the right assembler and linker.

How can one avoid to use the System unit?

You can use a dummy system unit, for the basic types like integer etc. a tiny system unit is necessary. I guess it's already available in rtl/fakertl. For an example for a small system unit have a look at PalmOS System unit (rtl/palmos).

At least for go32v2 I can say that it contains the dos extender as well. Further,
pascal contains a lot of "hidden" code for run time error handling etc. This leads to a hello world size for win32 of 14kB (1.0.6, options -XX -Xs).

Hi!

I'am too lazy to look up the web for the instruction set of TC1775 :) but what kind of instruction set does it use?

It is quite different to the i386 instruction set. First, it is RISC with Load/Store architecture. But it has far more instuctions than the i386. :-) They have some additional opcodes for bit operations, arithmetic (very much different behaviour on different data types, including saturation), ... But, the instructions are very interesting and useful.

A problem might be the register handling. There are A0..A15 as address registers and D0..D15 for data. Each 32 bit wide. When doing a "CALL" _some_ of them are saved into the "Context Save Area". A "Linked jump" is like the Call on 8086, without context saving. And normal "Jumps" are there too. Conditional ones too.

I don't know how the compiler can handle all that specialities, but, on the i386 there are other specialities, so, I guess, that won't be _that_ a big problem.

Yes, a lot is already done though it isn't finished yet.

Ah, great. Does that mean an Itanium port is easily possible as well? :-)

I want to mention, that there are two different interrupt service providers in the chip. :-) The normal CPU, for which standard opcodes can be used. In the Interrupt Vector Table (which is like that one in the 8051, so not an address is there, but code. Some instructions can be kept there. If one needs more, a jump to somewhere else can be made.

Another thing is the special Peripheral Control Processor. It has opcodes too, with lots of common instructions, but very different from the main CPU core. It is there to do easy interrupt handling, like querying the AD converter and writing the value to a RAM region. Therefore it would be extremely nice, to have this as a normal interrupt procedure within a .pas file. Sure, only a subset of constructs can be used, but it would be nice! Veery nice! ;-)

Thinking of the Keil C compiler they have all this mentioned extentions for the 8051 and the C166 µC. I think, inventing a new syntax for such things is not necessary, "P12.4" is enough.

BTW: There are nice instructions to copy bit fields. You have a 32 bit value, and say, you want bits 7..23, so it takes them and moves to another register, beginning at bit 0. Such "bit stream take" operations would be nice too for Pascal. It can combine two registers to a 64 bit value and take bits across the border! Very nice for shift and rotate operations!

SIMD instructions are there too. And it can work with "real" valued variables in 1.31 and 1.15 format. The range is -1.0..+1.0-1LSB. Perhaps such a data type for Pascal would be nice too. A FFT is easily implemented because of the cyclic buffer and the bitreversed addressing modes. And block adjust for a lot real values at once (for fixed point FFT) is availaible too.

Min, Max instructions are there too. *cantstopbeingenthusiastic* :-)

It simply depends on the linker you use. FPC itself (can) output(s) assembler so it's up to you to use the right assembler and linker.

Ah, I see. Fine, I'll investigate from this point.

Does that mean that a port to another processor has to have the interface to the selected assembler, so that the opcodes, special commands, ... fit together? So, the i386 output module uses AT&T assembler style, the TriCore output module use a totally different style?

You can use a dummy system unit, for the basic types like integer etc. a tiny system unit is necessary. I guess it's already available in rtl/fakertl. For an example for a small system unit have a look at PalmOS System unit (rtl/palmos).

Great! Can such a system unit consist of 0 bytes of code? Only type declarations in, no code?

Bye
Hansi

Since this message does fit into fpc-devel, I sent it to fpc-devel as well and I think we should continue the discussion there.

This isn't a real problem :)

Could be support by some kind of intristic functions which are inlined by the compiler.

A problem might be the register handling. There are A0..A15 as address registers and D0..D15 for data. Each 32 bit wide. When doing a "CALL" _some_ of them are saved into the "Context Save Area".

This do some other processors as well. It's only a matter of the calling conventions which differs anyway from processor to processor.

No.

> Yes, a lot is already done though it isn't finished yet. Ah, great. Does that mean an Itanium port is easily possible as well? :-)

I'am already working on an iA64 (Itanium is one particular implementation of the iA64 architecture)
port though it is delayed because I want to do the x86-64 port first because it seems to be the
more important archiecture in the short term.

Should be possible, i.e. for the compiler it mainly means the instruction set is limited in certain areas of the code.

And you do it call RISC ;) ?

The first step to support a new processor is to
implement the similar files to i386\cpubase.pas, i386\cpuinfo.pas and i386\cpuasm.pas. After this the assembler write can be implemented and the code generator which is the most work probably ...

Does that mean that a port to another processor has to have the interface to the selected assembler, so that the opcodes, special commands, ... fit together?

Yes.

So, the i386 output module uses AT&T assembler style, the TriCore output module use a totally different style?

Yes.

Theoretically yes, but some bytes of startup code would be nice so that the automatic initialzation of units can be done etc.