Hello,

I found a nice Pascal Tutorial for beginners on the net: http://web.mit.edu/taoyue/www/tutorials/pascal/

Please put this link into your link-list.

Looks good. A pity OOP (Objects/Classes) isn't treated. I've added the link, thanks for posting this.

Michael.

Michael Van Canneyt wrote

> I found a nice Pascal Tutorial for beginners on the net: > http://web.mit.edu/taoyue/www/tutorials/pascal/

Can also be downloaded:
http://web.mit.edu/taoyue/www/tutorials/learn-pascal.zip

Looks good. A pity OOP (Objects/Classes) isn't treated.

It tries to stick to the standard; allthough it doesn't.

BTW. are there plans to make FreePascal compatible to standard Pascal? I think at least the unextended standard (ISO 7185 from 1990) should be supported in full.

Andreas K. Foerster wrote

BTW. are there plans to make FreePascal compatible to standard Pascal? I think at least the unextended standard (ISO 7185 from 1990) should be supported in full.

The reason standard Pascal isn't supported, has many causes

a) GPC already supports it in full
b) the original reason FPC was started, was because Borland didn't want to make a 32bit Turbo Pascal. As such, FPC was initially aimed at people who wanted a 32bit TP, not people who want to program in standard Pascal c) no-one who works on the compiler is interested in writing standard Pascal programs

Jonas

First: _Why?_

There has been some discussion about this before. True standards compliancy is out of the question.

Running an average program could be possible, for that there are about 4 or 5 features, 3 or 4 of which need compiler support:

- interprocedural GOTO's (from child-procedures back to parent procs) This is more involved than it looks at a first glance.
- support of bitfield packing of records (could be omitted I think)
- new() for variant records. One can use this to only allocate mem for a certain variant, not the biggest size.
This essentially makes new() a procedure with an undefined number of paramters (since a record can have "infinitely")
Probably the less intrusive one of the extensions.
- using procedure variables before specifying the type first.

   (procedure x(y : procedure (z:longint));

RTL:
- Support for get^ and put^. There is a TP compatible implementation for that somewhere, so it would be pretty easy, using the objpas like construct to add it to system.

The big problem is that it is quite some lot of work, including the risk to introduce bugs into the compiler and with that holding up the next major release (which already has a lot of useful features).

_And more importantly pretty much for nothing_. Some schools might find it useful to teach in standard Pascal, but that is pretty much about it. The core members don't feel very strong about it, both for educational reasons (I myself learned it with TP, and my Pascal programming turned out reasonably well)
Real standard freaks will use a fully compliant (including ISO 100something) compiler anyway.

So the use pretty much turns into the ability to be able to put "implements BP and Delphi with some ISO extensions" on the website as definitions, which would only make some new munition to fuel another discussion about standards, C and the state of the world in the NGs.

---

CB Falconer (somebody from the ANSI group with some compiler) said he wanted to check out FPC, to implement the ISO features end of the coming summer, but I don't think he really has an idea of the size and complexity of the compiler.

Aitor Santamaría wrote

There's nothing that I myself miss on it, except for the ability to create 16-bit realmode DOS code, which seems to be considered beyond any possibility, because of the way pointers are handled (4 bits, always 32-bit offset).

The main problem is that in 16bit mode, only certain registers can be used to address memory (bx, si, di, bp, maybe sp too?). Because the code generator assumes all registers can be used to access memory, this would require a complete rewrite.

Jonas

Hi,

For those of us that haven't read the ISO spec of Pascal, what feature of Pascal from there currently unsupported would be nice to have? There's nothing that I myself miss on it, except for the ability to create 16-bit realmode DOS code, which seems to be considered beyond any possibility, because of the way pointers are handled (4 bits, always 32-bit offset).

Aitor

Sorry for typing fast and not stopping to read what I wrote.

I meant BYTES, not BITs

Marco van de Voort wrote:

And I didn't want to address you Marco, but to Andreas.

Aitor

Aitor Santamaría wrote

Does this mean that in 32bit ALL registers can be used to address memory?

On the 80x86 architecture, yes.

(just making sure, this is an unkown to me feature of 32-bit processors).

This has nothing to do with 32bit processors in general, although it also the case on the PowerPC. The m68k and I think also the Alpha have separate address registers.

Jonas

Does this mean that in 32bit ALL registers can be used to address memory? (just making sure, this is an unkown to me feature of 32-bit processors).

Aitor

There is nothing that justifies the work, except the bitpacking one (and IIRC that is also facultary in the standard).
BUT: This might better be implemented for FPC itself using directives or extensions that allow more control over packing, better than the ISO way.

The new() feature is not very intrusive I think, but applies to a case that is only theoretical. If somebody implemented it for ISO pascal, maybe I'd have it enable outside a possible ISO mode too, but I wouldn't waste a split second time on it myself.

The others don't even have any merit, except the possibility to run some Standard Pascal code, which IMHO is without much merit either, since 90% of the non-Borland'ish code uses some kind of extension, including Extended Pascal.

I ran into that myself when trying to get Chipmunk basic running. (which uses HP Pascal extensions)

---
IMHO really useful features:
- internal linker *
- threadsafety *
- Free Vision copyright free *
- PIC for Unix.
- more flexible settype and/or bitpacking/fields.
- C++ classes compability

* currently worked on already, in various states of progress.

you wrote

I think also the Alpha have separate address registers.

No. It have seperate floating point registers though.

Aitor Santamaría wrote

For those of us that haven't read the ISO spec of Pascal, what feature of Pascal from there currently unsupported would be nice to have?

I just asked, if there are plans.
A simple "no" would have been enough. Sorry for asking!

It would be nice, if it's compatible with the standard one day, but it is not so important to me.

To answer your question: There is nothing really missing, but some things are simply very different from the standard, especially file handling.

Now I found, that simple things, are more compatible, as in TP. I found, that in the "case" statement the keyword "otherwise" is allowed, and not just "else" as in TP.

Michael Van Canneyt wrote

> I found a nice Pascal Tutorial for beginners on the net: > http://web.mit.edu/taoyue/www/tutorials/pascal/

[...]

I've added the link, thanks for posting this.

Thanks,
but why did you skip the title-page?

Jonas Maebe wrote

b) the original reason FPC was started, was because Borland didn't want to make a 32bit Turbo Pascal. As such, FPC was initially aimed at people who wanted a 32bit TP, not people who want to program in standard Pascal

And I am so glad it was. The presence of Free Pascal has made it possible for me to port hundreds of my Turbo Pascal DOS apps to become 32-bit Windows Console apps with relatively little pain. Thank you, thank you!

- Rich