Hi, Iron Helix! B-) Hi, all!

Anyways, I noticed how GNU Pascal is lacking a standard Pascallian library, and am interested in writing it. I would do so in DGJPP C (not C++: too hard to interface with pascal (i think)),

Correct.

NASM assembly,

If you use NASM assembly, you lose portability. Then your unit can only be used on the Intel x86 platform and not, for instance, on a Sun workstation. (My girlfriend has one.;-)

and possibly something else...however, I would need a few things first:

1. your approval

Be welcome! :-) But first have a look on what is already there (ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/) and what is needed (see below for one suggestion).

2. A standard (borland or watcom or something) Pascal library

reference (or one of each type to write multiple libraries :), with descriptions of what each does etc.

I have never seen a Watcom Pascal compiler. The only de-facto standard I have seen in Pascal libraries are Borland's ones.

3. A knowledge of how GNU Pascal calling convention works: (it should

interface nicely with DJGPP-C type, right?),

GPC has exactly the same calling conventions as GCC (= DJGPP-C).

offsets that function paramaters are passed at (i.e. are 16-bit #'s passed as 32-bit #'s), etc.

Exactly like in GCC.

4. A quick reference of GNU Pascal supported pointer types (far, near,

huge),

Flat. ;-) That's the only reasonable model in the 32-bit world.

(See the DJGPP FAQ list, section 17.7.)

supported data types,

Everything from ISO-7185 Standard Pascal, plus BP7-style objects, Strings and Schemata like in ISO-10206 Extended Pascal.

how structures are setup 5) A reference of how the filetypes in the libraries are setup

You mean: A reference about the internal representation of structured types and file types? Well, this information is of course available, but ...

Serious question: *Why* do you need this kind of information?

From the DOS world, you are probably used to situations that can

only be mastered by tricking around limitations of the system. For instance, if you want to pass a nested function as a parameter to another function, you must go assembler in BP. (Turbo Vision works like this.) If you want to exchange data between C and Pascal programs, you must take care of the memory model, the way how the stack is used by the various languages, and so on.

Things like these are not necessary with GPC. The compiler does them for you! 8-)

If given the above, I would write a full-featured library for use with GNU Pascal (or, at least, get pretty darn close :) that would be almost 100% compatible with normal Pascal libraries, and I would also maintain it, too :) Yes, I realize that this may be a huge task (how long did it take them to write the DJGPP2 libc? :), and that it would take a little while, but hey, it sounds interesting :) and you could take that little 'con' out of the cons section. In addition, non-C (but Pascal) programmers could use your compiler because you'd have a similar-to-Pascal-lib, and they wouldn't have to 'decipher' the c reference :).

NOTE: Just in case I wasn't clear, what I meant by writing a "standard Pascal lib" is writing the lib that is to Pascal as libc is to DJGPP :)

There is no library in Pascal that corresponds to `libc'. The closest thing is GPC's run-time library which implements Pascal's `writeln' and such. But that one is ready and working well. ;-)

But there *are* some "standard" libraries expected by everyone coming from the Borland (Turbo) Pascal background. Some of them already have been written (see the BPcompat package, available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/), but there is one big project remaining: Turbo Vision.

We have the source of a Turbo-Vision-compatible library, but it needs a lot of work to become usable with GNU Pascal.

Borland's Turbo Vision uses a lot of assembly. We would go another way and put our version of Free Vision on the solid fundament of the `ncurses' (or `pdcurses') library. This way, it will be usable on *any* system from plain DOS to the fastest workstations available. (-: And since you already know DJGPP and it's GCC, you should not be afraid of working with those C libraries ... ;-)

If you are interested, please let us know, so we can work out the details.

Oh, and on the side, wouldn't it be an interesting thing to write a GNU Basic compiler that was _FAST_, had unsigned numbers, had more needed functions that aren't able to be made/used (i.e. an 'asm'-like command ;), used pointers, and some more stuff like being almost completely compatible with existing QBASIC programs and compiler-commands (i.e. '#include') and some more stuff? If you guys would want to do the lex. analyzer/compiler/etc. part, I'd write the library that would be the _FAST_ version of the normal BASIC lib...we could help BASIC programmers out there do alot better :) even tho it still wouldn't be as good as C...

If we write a GNU Basic compiler it will produce *exactly* the same very-well-optimized code as GNU C does - or GNU Pascal for that matter. `#include' and such would be no problem since GNU's C-Compatible Compiler Proprocessor (CCCP) can do this job.

BUT: Do not underestimate the task of writing a lexer/parser/ etc.! I do not expect to find the time to write such a thing in the middle-near future.

If you want to get an impression of the size of this task, be invited to have a look at the relevant parts of the GPC source code: `gpc-lex.c' is the lexical analyzer (written in C); `parse.y' is the parser (written in Bison).

Anyways, thanx for your time.

You are offering your time to contribute to this project. Be welcome!

Greetings,

Peter