Linking C in Turbo Pascal or Borland Pascal? 
Author Message
 Linking C in Turbo Pascal or Borland Pascal?

I know that the TSFAQPAS files by Timo Salmi touch on this question, but
they answer by refering to books that are out of print, so here is my
question.

1. I know that you can write assembly language into a unit, but can you
put C code into it?

2. If so, can you do this for both Borland AND Turbo Pascal?

3. Is C faster than Turbo or Borland Pascal?

Thanks in advance.

--
Patrick D. Rockwell





Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?

Quote:

> I know that the TSFAQPAS files by Timo Salmi touch on this question,
> but they answer by refering to books that are out of print, so here
> is my question.

> 1. I know that you can write assembly language into a unit, but can
> you put C code into it?

Don't know

Quote:
> 2. If so, can you do this for both Borland AND Turbo Pascal?

If you can do it for one, there is no doubt that you can do it for the
other.

Quote:
> 3. Is C faster than Turbo or Borland Pascal?

About every modern, both C & Pascal, compiler generates better code
than a product that is almost a decade old and still generates 16-bit
code.

Robert
--
Robert AH Prins

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?



Quote:
> I know that the TSFAQPAS files by Timo Salmi touch on this question,
but
> they answer by refering to books that are out of print, so here is
my
> question.

> 1. I know that you can write assembly language into a unit, but can
you
> put C code into it?

The assembler in TP is built into the Pascal compiler. There is no C
compiler in the Pascal compiler though so- no. I suppose you could do
some wierd mucking around with conditional compilation stuff, put the
C code in a comment and use the C preprocessor to have the C compiler
avoid the Pascal, so that it's physically possible for one file to
have a Pascal unit and some C source at the same time, and be compiled
by separate compilers but there wouldn't be much point IMHO.

FP



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?


Quote:

>I know that the TSFAQPAS files by Timo Salmi touch on this question, but
>they answer by refering to books that are out of print, so here is my
>question.

>1. I know that you can write assembly language into a unit, but can you
>put C code into it?

>2. If so, can you do this for both Borland AND Turbo Pascal?

>3. Is C faster than Turbo or Borland Pascal?

>Thanks in advance.

For Borland Pascal DPMI mode, you should AIUI put the C into a DLL.
Care will be needed with anything that might invoke a C library call.

AIUI, TP & BP are reasonably fast, and so is C.  The quality of the
algorithm will generally be more important.

--

 Web <URL: http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 PAS, EXE in <URL: http://www.merlyn.demon.co.uk/programs/> - see 00index.txt.
 Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm  &c.



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?


Quote:


> > I know that the TSFAQPAS files by Timo Salmi touch on this question,
> > but they answer by refering to books that are out of print, so here
> > is my question.

> > 1. I know that you can write assembly language into a unit, but can
> > you put C code into it?

> Don't know

Yes, you can, you can create OBJ files using TASM and/or TurboC.

[sNIP]

Quote:
> > 3. Is C faster than Turbo or Borland Pascal?

> About every modern, both C & Pascal, compiler generates better code
> than a product that is almost a decade old and still generates 16-bit
> code.

This is a "void(*argument)(void)". You can only link 16bit code to 16bit
applications statically with the well-known linkers, and you will have to
use thunking when using DLLs; you can, however, use 32-Bit registers in asm
code even in TP.

--
Rudolf Polzer
REBOUNCE - http://www.rebounce.de.vu
I wish I was what I was when I wished I was what I am now.

R&auml;tsel:
1
11
21
1211
111221
312211
13112221
1113213211
??????????????



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?

Quote:

> 1. I know that you can write assembly language into a unit, but can you
> put C code into it?

Not directly: you should use the C compiler (funny, isn't it?)
to create .obj, and then you can link the .obj the same way
as independant assembler sources. Just take care of the '_'
prepended to C names...

HOWEVER, the C runtime library (malloc, printf) is not usable
(because it is not linked in), so a fair amount of C code cannot
be linked.
And providing the services of the C runtime library is not
really easy to do (but it is doable).

Quote:
> 2. If so, can you do this for both Borland AND Turbo Pascal?

No difference here.

Quote:
> 3. Is C faster than Turbo or Borland Pascal?

As a compiler (compile time), definitively no, Turbo deserves
its name because it compiles much faster. As a result, you usualy
develop faster, BTW. Or you can research better algorithms for
the critical parts (this is where the profiler comes handy).

As for the produced code: intrinsically, C and Pascal constructs
will provide more or less the same underlying (i.e., before
optimisation) code; so it's optimisation which really matters
here. The best C compilers, when optimizing, provide better
code that TP/BP does (but it takes hours instead of seconds to
compile). This is no secret that TP/BP compiler is not much
optimizing.

Antoine



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?


Quote:

> > 1. I know that you can write assembly language into a unit, but can you
> > put C code into it?

"put c code into it" the only way is to use a compiled obj that has been
compiled.. (from memory by useing the {$o filename} or {$i filename}
directive?  mind you you "could" design a prepreocessor for c or pascal that
would only compile one language or the other. but that's to much hassle..
just grab the code that you want .. make it into a procedure and compile it.
tp7 etc can do "c style" procedure calling with a command.. look at the tp7
help files if you have them.. other wise grab a copy of it.. it should be
abandon ware in the us.. as it's old enuff now. (2 years?) so all talk of
pirateing is null and void if your in the us.

sorry to recover all that :)

Quote:
> HOWEVER, the C runtime library (malloc, printf) is not usable
> (because it is not linked in), so a fair amount of C code cannot
> be linked.

eh? oh that's right c is a "dumb" compiler..

Quote:
> And providing the services of the C runtime library is not
> really easy to do (but it is doable).
> > 3. Is C faster than Turbo or Borland Pascal?

> As a compiler (compile time), definitively no, Turbo deserves
> its name because it compiles much faster. As a result, you usualy
> develop faster, BTW. Or you can research better algorithms for
> the critical parts (this is where the profiler comes handy).
> As for the produced code: intrinsically, C and Pascal constructs
> will provide more or less the same underlying (i.e., before
> optimisation) code; so it's optimisation which really matters
> here. The best C compilers, when optimizing, provide better
> code that TP/BP does (but it takes hours instead of seconds to
> compile). This is no secret that TP/BP compiler is not much
> optimizing.

Well in the "old" days :) tp shat all over most/all c compilers for
speed+size+code optimization but now adays the c boys have
tweaked,broken,fixed,twaked again etc and got better if not the same as tp.

I remember seeing time/size comparasans between the diffrent compilers and
tp v7 was fast+small.

The underlying design of pascal is that it's a ONE pass compiler i.e you
read in a char at a time or line at a time and you don't need to re check
any code to make a compiled exe from pascal code. c on the other hand is a
multi pass compiler .. which is why some people say it's better than pascal
coz it can do funkyer things, but this comes at a cose.. where as pascal
code is designed for non ambigous interpretation and thus quick compileing,
c/c++ dosen't have this "limitation" but is dog slow to compile... but in
the end it really just comes down to your style.

The only problem with tp7 is the lack of 386+ compileing options.. it stopps
at 286.. while most c compilers around then had started introduceing 386
stuff. (I'm talking umm 1990 I think :)



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?

Quote:




> > > 1. I know that you can write assembly language into a unit, but can you
> > > put C code into it?

> > HOWEVER, the C runtime library (malloc, printf) is not usable
> > (because it is not linked in), so a fair amount of C code cannot
> > be linked.
> eh? oh that's right c is a "dumb" compiler..

Please, be fair! Imagine you have a Turbo Pascal compiler that produces
.obj (like Delphi 2+ does). Do you imagine that the resulting .obj
will mix well with the C runtime library? It won't.

Quote:
> > > 3. Is C faster than Turbo or Borland Pascal?

> Well in the "old" days :) tp shat all over most/all c compilers for
> speed+size+code optimization

Regarding speed of the produced binaries, this is definitively wrong.
Regarding size, mileage may vary, but with big projects C binaries
tended to end smaller (with small programs, the bigger size of the
C library did not compensate for the optimisation).

Quote:
> but now adays the c boys have tweaked,broken,fixed,twaked again etc
> and got better if not the same as tp.

My impression is not that C compilers did improve in the area of
speed of compilation. In fact, my everyday experience is plain
reverse.

Unfortunately :-(

Quote:
> I remember seeing time/size comparasans between the diffrent
> compilers and tp v7 was fast+small.

See above. Either the competitors were restricted to M$-Basic,
or the test programs were restricted to Hello, World.

Quote:
> The underlying design of pascal is that it's a ONE pass compiler i.e you
> read in a char at a time or line at a time and you don't need to re check
> any code to make a compiled exe from pascal code.

AFAIK, TP4+ is a 2-pass "compiler" (one pass is compiling, the
second is linking). C compilers OTOH are 1.5+1 pass: when compiling, it
needs a supplementary partial pass to re-read (and re-tokenise) the ".h"
of the included modules; linking is comparable to TP in spirit.
Previous C compilers did have (gcc still has, for some months) a
supplementary pass at the very beginning, named the pre-processor.

A bigger point is the format of the intermediary files: C traditionnaly
rely on the openness of the architecture here, which includes many
unnecessary bells and whistles. OTOH, TP use a private format that
is tailored to its behaviour, and much more efficient.
The tradeoff is that it is difficult to merge the outputs of both.

Quote:
> The only problem with tp7 is the lack of 386+ compileing options.. it
> stopps at 286.. while most c compilers around then had started
> introduceing 386 stuff. (I'm talking umm 1990 I think :)

The real optimisation here is to go 32-bit. As such, TP7 do have
it, but it is not branded by Borland. Its name are FreePascal,
TMT, and Virtual Pascal (in alphabetic order! I hope I did not
miss anybody important, sorry if I don't).

Antoine



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?
Antoine Leca:

Quote:
> AFAIK, TP4+ is a 2-pass "compiler" (one pass is compiling, the
> second is linking).

No, it has 6 compiling passes (editing, compiling, linking, running,
debugging, drinking a coffee).

;-)

Seriously, I would say there is *one* pass (producing a .TPU or,
for a program, an object code in memory that will be linked).
For smart recompilation, maybe there is a little re-read in a
source using an unit to be recompiled. The TP6 ASM source is not well
commented, then it would need some hermeneutic interpretation.

Quote:
> The real optimisation here is to go 32-bit. As such, TP7 do have
> it, but it is not branded by Borland. Its name are FreePascal,
> TMT, and Virtual Pascal (in alphabetic order! I hope I did not
> miss anybody important, sorry if I don't).

I fear you forgot GNU Pascal. Mind your mail box ;-)
______________________________________________________
Gautier  --  http://members.nbci.com/gdemont/gsoft.htm

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?

Quote:


>> Well in the "old" days :) tp shat all over most/all c compilers for
>> speed+size+code optimization

>Regarding speed of the produced binaries, this is definitively wrong.
>Regarding size, mileage may vary, but with big projects C binaries
>tended to end smaller (with small programs, the bigger size of the
>C library did not compensate for the optimisation).

Interesting. Can you name examples, on what generic 16-bit C compilers from
the era do better?

Probably TopSpeed, but the M2 version I used  wasn't as slow as a C compiler,
but I never used its C compiler

Quote:
>My impression is not that C compilers did improve in the area of
>speed of compilation. In fact, my everyday experience is plain
>reverse.

Any compiler including
FPC is also slower than BP :-) But I've seen over 100.000 lines in 10 seconds
on a K6-2 500 (recompiling itself with optimisations, but with most sources
cached in my 64 MB probably, so this is an extreme value)

Quote:
>> The underlying design of pascal is that it's a ONE pass compiler i.e you
>> read in a char at a time or line at a time and you don't need to re check
>> any code to make a compiled exe from pascal code.

>AFAIK, TP4+ is a 2-pass "compiler" (one pass is compiling, the
>second is linking). C compilers OTOH are 1.5+1 pass: when compiling, it
>needs a supplementary partial pass to re-read (and re-tokenise) the ".h"
>of the included modules; linking is comparable to TP in spirit.

2 and 2.5 passes??!??

1 scanning (preprocessing, external in C mostly)
2 parsing  (building tree)
3 semantic analysis (ok, simpler in C :-)
3 tree level optimization (small in FPC atm. Need new CG and datastructs for
that. )
4 code generation
5 assembler generator
6 assembler optimiser
7 assembler writer      (pipe in gcc, internal stream when using binwriter
                   like in fpc or BP)
8 assembler step
(for binary only)
9 linker.
(for some fileformats only, and in theory it could be in the linker)
10 binary preprocessors (some types of debug info, chmod'ing, icons and
resourcetables in Win32)

On the other hand TP does its own (though more limited preprocessing), which
a C compiler already has done externally.

Quote:
>Previous C compilers did have (gcc still has, for some months) a
>supplementary pass at the very beginning, named the pre-processor.

Gcc's deadly slowlyness, stemms IMHO from two reasons:

- reparsing headers for *each* file. (Though this could be cached by saving
enabled defines and checked defines in the header, together with some
dependancy info in the cached header)
- (more important IMHO) No internal makefiles, preprocessor, assembler.
   Reinitialise entire compiler,preprocessor, assembler for *each* file.

When adding the binary writer to FPC (thus making external assembling
optional), speed increased 2-4 fold.

Quote:
>A bigger point is the format of the intermediary files: C traditionnaly
>rely on the openness of the architecture here, which includes many
>unnecessary bells and whistles.

Afaik, no object formats are defined in the language standard, so I think
this argument is not valid.

Quote:
>OTOH, TP use a private format that
>is tailored to its behaviour, and much more efficient.
>The tradeoff is that it is difficult to merge the outputs of both.

Also a bit odd. Two different C compilers that use different formats on the
same processor are also incompatible.

Quote:
>> The only problem with tp7 is the lack of 386+ compileing options.. it
>> stopps at 286.. while most c compilers around then had started
>> introduceing 386 stuff. (I'm talking umm 1990 I think :)
>The real optimisation here is to go 32-bit. As such, TP7 do have
>it, but it is not branded by Borland. Its name are FreePascal,
>TMT, and Virtual Pascal (in alphabetic order! I hope I did not
>miss anybody important, sorry if I don't).

But I fully agree with that. GPC too of course.


Mon, 12 May 2003 09:16:06 GMT  
 Linking C in Turbo Pascal or Borland Pascal?

Quote:

> AFAIK, TP4+ is a 2-pass "compiler" (one pass is compiling, the
> second is linking).

Linking is *NOT* a compiler pass.

Quote:
> C compilers OTOH are 1.5+1 pass: when compiling, it
> needs a supplementary partial pass to re-read (and re-tokenise) the ".h"
> of the included modules; linking is comparable to TP in spirit.

The number of passes can depend on the amount of optimization,
but in any case, there's no such thing as a 0.5 pass.

Quote:
> Previous C compilers did have (gcc still has, for some months) a
> supplementary pass at the very beginning, named the pre-processor.

Pre-processor is a different animal.


Mon, 12 May 2003 12:33:28 GMT  
 Linking C in Turbo Pascal or Borland Pascal?

Quote:

> > AFAIK, TP4+ is a 2-pass "compiler" (one pass is compiling, the
> > second is linking).

> Linking is *NOT* a compiler pass.

Linking is part of compiler's job, and needs a whole pass
thoughout the object intermediary code to collect the links
to establish (I neglect the recursive part of the linked in
libraries here). Both C and TP4+ runs this job as a separate
task done *after* the main compilation to binary object code.
Hence my formula.

I was answering a point that C compilers are multi-pass while
TP be mono-pass. The preprocessor pass of C disappeared in the
MS-DOS world around 1982, and the process became integrated
(that is, in direct flux) a few years later, producing .OBJ
without any intermediary state. About the same moment in time,
TP went from a all-in-one organisation (up to v.3) into a
two-stage approach which divide clearly between compiling and
linking. So at that time, there have been more or less the
same number of passes (subject to what is discussed below).

Quote:
> > C compilers OTOH are 1.5+1 pass: when compiling, it
> > needs a supplementary partial pass to re-read (and re-tokenise)
> > the ".h" of the included modules; linking is comparable to TP
> > in spirit.

> The number of passes can depend on the amount of optimization,

Yes, for global optimisations. I stand corrected here.

Quote:
> but in any case, there's no such thing as a 0.5 pass.

My point was that with C, you have to re-tokenise the ".h" every
time you include the module (precompiled headers may help here),
in order to get the interface. OTOH, .TPU keeps the interface
in compiled form. So I use the fractal term to explain that in C,
you have to repeatedly process the first part (interface) of
every module, while with TP this processing is transparent.

Quote:
> > Previous C compilers did have (gcc still has, for some months) a
> > supplementary pass at the very beginning, named the pre-processor.

> Pre-processor is a different animal.

Looks like very much like a supplementary pass to me, when the
output of the pre-processor is stored on disk to be re-read
from the beginning by the parser... And C definitively needs a
preprocessor, which is quite distinct from the main compiler.

Antoine



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?



Quote:
> >> Well in the "old" days :) tp shat all over most/all c compilers for
> >> speed+size+code optimization
> >Regarding speed of the produced binaries, this is definitively wrong.
> >Regarding size, mileage may vary, but with big projects C binaries
> >tended to end smaller (with small programs, the bigger size of the
> >C library did not compensate for the optimisation).

I'm sorry I'm speaking from a dos point of view. and tpv7

Quote:
> Interesting. Can you name examples, on what generic 16-bit C compilers
from
> the era do better?
> Probably TopSpeed, but the M2 version I used  wasn't as slow as a C
compiler,
> but I never used its C compiler

I under stood that c did maths quicker I think.. but with the nature of tp
string handeling and c string handeling, tp beat it in arears such as this..
c may be fast but tp screams because of it's "limited" design concepts such
as max 255 string sizes etc. a loop/indexing rou{*filter*} is faster than a
conditional/jmp on the intel..

Quote:
> >My impression is not that C compilers did improve in the area of
> >speed of compilation. In fact, my everyday experience is plain
> >reverse.
> Any compiler including
> FPC is also slower than BP :-) But I've seen over 100.000 lines in 10
seconds
> on a K6-2 500 (recompiling itself with optimisations, but with most
sources
> cached in my 64 MB probably, so this is an extreme value)

heh that sounds {*filter*} fast :)

Quote:
> >> The underlying design of pascal is that it's a ONE pass compiler i.e
you
> >> read in a char at a time or line at a time and you don't need to re
check
> >> any code to make a compiled exe from pascal code.
> >AFAIK, TP4+ is a 2-pass "compiler" (one pass is compiling, the
> >second is linking). C compilers OTOH are 1.5+1 pass: when compiling, it
> >needs a supplementary partial pass to re-read (and re-tokenise) the ".h"
> >of the included modules; linking is comparable to TP in spirit.

yeah but "linking" isen't in my opinion a "pass" if you code your compiler
for pascal right.
all that "linking" dose is add an exe header and so on if you don't make
.com files. so I don't think thats the compiler it's the os's fault so
"linking" is joing your compiler code to the os's format of executable.

[..CUT..]

Quote:
> 3 semantic analysis (ok, simpler in C :-)
> 3 tree level optimization (small in FPC atm. Need new CG and datastructs
for
> that. )
> 4 code generation
> 5 assembler generator
> 6 assembler optimiser
> 7 assembler writer (pipe in gcc, internal stream when using binwriter
>    like in fpc or BP)
> 8 assembler step
> (for binary only)
> 9 linker.
> (for some fileformats only, and in theory it could be in the linker)
> 10 binary preprocessors (some types of debug info, chmod'ing, icons and
> resourcetables in Win32)
> On the other hand TP does its own (though more limited preprocessing),
which
> a C compiler already has done externally.

yeah but that's for units? which each are one pass compiled code :) (or at
least that's what I thort :)

Quote:
> >Previous C compilers did have (gcc still has, for some months) a
> >supplementary pass at the very beginning, named the pre-processor.

umm gcc has allwayse had this?

- Show quoted text -

Quote:
> Gcc's deadly slowlyness, stemms IMHO from two reasons:
> - reparsing headers for *each* file. (Though this could be cached by
saving
> enabled defines and checked defines in the header, together with some
> dependancy info in the cached header)
> - (more important IMHO) No internal makefiles, preprocessor, assembler.
>    Reinitialise entire compiler,preprocessor, assembler for *each* file.

> When adding the binary writer to FPC (thus making external assembling
> optional), speed increased 2-4 fold.
JOY!
> >A bigger point is the format of the intermediary files: C traditionnaly
> >rely on the openness of the architecture here, which includes many
> >unnecessary bells and whistles.
> Afaik, no object formats are defined in the language standard, so I think
> this argument is not valid.
> >OTOH, TP use a private format that
> >is tailored to its behaviour, and much more efficient.
> >The tradeoff is that it is difficult to merge the outputs of both.

So c/c++ should use it's own for the cpu/sustem it compileing for. As it
dose

Quote:
> Also a bit odd. Two different C compilers that use different formats on
the
> same processor are also incompatible.
> >> The only problem with tp7 is the lack of 386+ compileing options.. it
> >> stopps at 286.. while most c compilers around then had started
> >> introduceing 386 stuff. (I'm talking umm 1990 I think :)
> >The real optimisation here is to go 32-bit. As such, TP7 do have
> >it, but it is not branded by Borland. Its name are FreePascal,
> >TMT, and Virtual Pascal (in alphabetic order! I hope I did not
> >miss anybody important, sorry if I don't).
> But I fully agree with that. GPC too of course.

No .. I have in my collection of tp7 stuff a protected mode package for tp7
that was called
"swallow" I think (I could check the name but can't be stuffed).It's made by
some shareware guy.


Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?

Quote:



> >> Well in the "old" days :) tp shat all over most/all c compilers for
> >> speed+size+code optimization

> >Regarding speed of the produced binaries, this is definitively wrong.
> >Regarding size, mileage may vary, but with big projects C binaries
> >tended to end smaller (with small programs, the bigger size of the
> >C library did not compensate for the optimisation).

> Interesting. Can you name examples, on what generic 16-bit C compilers from
> the era do better?

Examples of what?
Speed of produced binary: you take *any* algorithm, and my take is that
98 times out of 100, more than 80% of the .EXE produced by 16-bit
C compilers (in large model, obviously) will perform better than TP7 .EXE.
This is so because TP7 do very very few optimisations.

Size: my take here is that the core code (what you wrote yourself, as
opposed to the RTL) is, again due to optimisations, smaller in C
than it is with TP7 (And VC++1.5 optimises a lot better than BC++
does; I never get a chance to test better compilers from Metaware,
Watcom or anywhere else). Since the RTL, and libraries in general, are
much bigger with C than with TP, the overall result can vary, but
the trend when projects increase (that is, when you have to do a lot
more work yourself) is that the C code size increases slower.

Quote:
> >My impression is not that C compilers did improve in the area of
> >speed of compilation. In fact, my everyday experience is plain
> >reverse.

Sorry for the no-no. I said that the compilers are running slower than
they did, and this evolution is repeating again and again (so next
compilers will be slower). Fortunately, new hardware runs much quicker,
so the overall result is more than usable.

Quote:
> >> The underlying design of pascal is that it's a ONE pass compiler i.e you
> >> read in a char at a time or line at a time and you don't need to re check
> >> any code to make a compiled exe from pascal code.

> >AFAIK, TP4+ is a 2-pass "compiler" (one pass is compiling, the
> >second is linking). C compilers OTOH are 1.5+1 pass: when compiling, it
> >needs a supplementary partial pass to re-read (and re-tokenise) the ".h"
> >of the included modules; linking is comparable to TP in spirit.

> 2 and 2.5 passes??!??

> 1 scanning (preprocessing, external in C mostly)
> 2 parsing  (building tree)

<snip>

We speak of different things. You speak about phases. Vortex and I speak
about the number of times you have to analyse the beast, in order to go
from the user source to the object code. "Multiple passes" means that
there are intermediary storage of the intermediary products, while
monopass means that there are not and that the .EXE is incrementally
produced as soon as each new character is read.

See my other post about details about the .5 notation.

Quote:
> 1 scanning (preprocessing, external in C mostly)

1 and 2 are often directly linked.

Quote:
> 2 parsing  (building tree)

Where are 2 and 3a unlinked (that is, with a intermediate storage)?

Quote:
> 3 semantic analysis (ok, simpler in C :-)

Again, where is that unlinked? Or do I misunderstand what you
are talking about tree level optimisation (if you mean
strength reduction here, then TP has it too...)

Quote:
> 3 tree level optimization (small in FPC atm. Need new CG and
> datastructs for that. )

Here take place the global optimisations I was forgetting.

Quote:
> 4 code generation

What is the difference between 4 and 5? I mean, is there
really a generic code generator that writes (on memory) some
generic code for some virtual machine, which is then processed
by a dedicated tool that targets a defined architecture?
Looks like weird.

Quote:
> 5 assembler generator

A number of C compilers generate directly binary code. There are
few reasons to do differently, but some of them are still in force:
- need to review easilly what the code generator produces (should
  not be a point if tools were not evolving constantly, 'cause
  that is just a point for the developpers of the compiler...)
- need to embeed easily assembly code (with "as" at the end, assembler
  code is copied directly to the output

Quote:
> 6 assembler optimiser

Huh? You mean, some are optimising directly on the assembly
source rather than on the intermediary code produced by step 4?
I know this *is* possible (and probably it is the traditional
design of V7 and/or pcc), but it does not look like the best
option to me, particularly when you have such a detailled
scheme as the one you drew.

Quote:
> 7 assembler writer      (pipe in gcc, internal stream when using binwriter
>                    like in fpc or BP)

What's this? Are you implying that the output of #6 is stored
in some ways in memory (or on file?), and then is readed
and a different process which itself produces the assembly text?

Quote:
> 8 assembler step
> (for binary only)
> 9 linker.
> (for some fileformats only, and in theory it could be in the linker)
> 10 binary preprocessors (some types of debug info, chmod'ing, icons and
> resourcetables in Win32)

Often, there is no pass over the entire file, but just appending
of datas at the right place and adjustiment of pointers.

Quote:
> >A bigger point is the format of the intermediary files: C traditionnaly
> >rely on the openness of the architecture here, which includes many
> >unnecessary bells and whistles.

> Afaik, no object formats are defined in the language standard, so I think
> this argument is not valid.

Practically, it holds: the C compilers that compete with TP did produce
.OBJ, and relocatable OMF is a so weird format that it turns to be a
major hindrance to them. Unfortunately (?), the few C compilers that
forget about that, and use proprietary format, never succeed. I think
openness was a requisite when you use C (for example, I often used
both M$ CL and TC/BC, the latter for developping and the former for the
release because of the quality of the resulting code; C portability
is a major point here).

Quote:
> >OTOH, TP use a private format that
> >is tailored to its behaviour, and much more efficient.
> >The tradeoff is that it is difficult to merge the outputs of both.

> Also a bit odd. Two different C compilers that use different formats
> on the same processor are also incompatible.

Very true (you did try to merge 32-bit M$ with BCC, didn't you?)

[ 32-bit TP7 ]

Quote:
> >Its name are FreePascal,
> >TMT, and Virtual Pascal (in alphabetic order! I hope I did not
> >miss anybody important, sorry if I don't).

> But I fully agree with that. GPC too of course.

GPC is good at BP7 compatibility too? I was not aware of that.
Perhaps is it time to look at it, so...

Antoine



Wed, 18 Jun 1902 08:00:00 GMT  
 Linking C in Turbo Pascal or Borland Pascal?
Marco van de Voort:

Quote:
> Gcc's deadly slowlyness, stemms IMHO from two reasons:

> - reparsing headers for *each* file. (Though this could be cached by saving
> enabled defines and checked defines in the header, together with some
> dependancy info in the cached header)
> - (more important IMHO) No internal makefiles, preprocessor, assembler.
>    Reinitialise entire compiler,preprocessor, assembler for *each* file.

You can add - at least for the Ada95 front-end of GCC - a re-parsing of
the body (=implementation) part if you have a pragma Inline for *one*
procedure and you have switched the cross-unit inlining option!
Slow compilation (on a <= Pentium-S) but a must for having even more
speed in the code...

____________________________________________________
Gautier  --  http://members.nbci.com/gdemont/e3d.htm

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Linking (turbo) C in Borland pascal 7.0

2. difference between TURBO PASCAL & BORLAND PASCAL

3. difference between TURBO PASCAL & BORLAND PASCAL

4. Pascal genie/ Borland turbo pascal

5. I would like to know the difference between Borland Pascal 7.0 and Turbo Pascal 7.0

6. WTB: Turbo Pascal (or Borland Pascal) v7 DOS

7. WTB: Turbo Pascal (or Borland Pascal) v7 DOS

8. turbo pascal/borland pascal

9. Borland Turbo Pascal vs Pascal with Objects

10. Turbo Pascal 7.0 vs Borland Pascal 7.0

11. WTD - Borland/Turbo Pascal Manuals/SW Especially Turbo Vision

12. Linking Borlan C function to a Borland Pascal Program

 

 
Powered by phpBB® Forum Software