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.

Robert
--
Robert AH Prins
pr...@bigfoot.com

"Patrick D. Rockwell" <prockw...@thegrid.net> wrote in message
news:3A107A89.1EBDDE11@thegrid.net...

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

[sNIP]

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

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).

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.

sorry to recover all that :)

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.

Unfortunately :-(

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.

;-)

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.

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

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.

- 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.

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).

"Marco van de Voort" <mar...@toad.stack.nl> wrote in message
news:slrn91orum.240k.marcov@toad.stack.nl...

[..CUT..]

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.

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.

[ 32-bit TP7 ]

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