brugarolas / ptoc Goto Github PK
View Code? Open in Web Editor NEWThis project forked from knizhnik/ptoc
Pascal to C++ converter
ptoc's Introduction
<HTML>
<HEAD>
<TITLE>Pascal to C/C++ converter</TITLE>
<UL>
<LI><A HREF = "#about">About PtoC</A>
<LI><A HREF = "#installation">PtoC installation</A>
<LI><A HREF = "#paslib">Pascal runtime library emulation</A>
<OL>
<LI><A HREF = "#paslib.arrays">Arrays</A>
<LI><A HREF = "#paslib.sets">Sets</A>
<LI><A HREF = "#paslib.math">Mathematical functions</A>
<LI><A HREF = "#paslib.io">Input/Output</A>
</OL>
<LI><A HREF = "#winbgi">BGI emulation</A>
<LI><A HREF = "#structure">Structure of converter</A>
<LI><A HREF = "#cganal">Nested functions and call graph analysis</A>
<LI><A HREF = "#name conflicts">Resolving name conflicts</A>
<LI><A HREF = "#C parameters">Passing parameters in C</A>
<LI><A HREF = "#C++ parameters">Passing parameters in C++</A>
<LI><A HREF = "#C functions">Calling of C functions</A>
<LI><A HREF = "#assignment">Array assignments</A>
<LI><A HREF = "#string">Conversion of Turbo Pascal strings</A>
<LI><A HREF = "#porting">Some porting problems</A>
<OL>
<LI><A HREF = "#integer">Representation of integer types</A>
<LI><A HREF = "#set">Implementation of Pascal sets</A>
<LI><A HREF = "#enum">Enumeration types</A>
</OL>
<LI><A HREF = "#style">Style of converted sources</A>
<LI><A HREF = "#modules">Includes in ANSII Pascal</A>
<LI><A HREF = "#options">PtoC options</A>
<LI><A HREF = "#bugs">Known bugs</A>
<LI><A HREF = "#distribution">PtoC distribution</A>
</UL>
<BODY>
<HR>
<H2><A NAME = "about">About PtoC</A></H2>
This is yet another Pascal to C/C++ converter. The primary idea of this
converter is to produce readable and supportable code which
preserves style of original code as far as possible.<P>
Converter recognizes Pascal dialects which are compatible with
Turbo Pascal 4.0/5.0 and ISO Pascal standard - IEC 7185:1990(E)
(including conformant arrays). At this moment it was tested
with Turbo Pascal, Oregon Pascal, Sun Pascal and HP Pascal.<P>
Converter can produce both C++ and C output. Using of C++ language allows
to encapsulate some Pascal types and constructions into C++ classes.
So mapping between Pascal and C++ becomes more direct
then between Pascal and C. I use C++ templates to implement Pascal arrays
and files. Special template classes are used for conformant arrays.
C++ like streams are used to implement Pascal IO routines.
The same runtime library is used both for C and C++.<P>
Now PtoC recognizes Turbo Pascal's extensions, such as units,
strings, some special types and operations. Turbo Pascal extensions are
supported only for C++ language.<P>
At this moment PtoC successfully converts more than 400,000 lines
of Oregon Pascal to C (from RSX to OpenVMS). To test C++ translation and
conversion of Turbo Pascal extensions I convert BGIDEMO.PAS and LISTER.PAS
files from Turbo Pascal distribution and also convert some
numeric programs written on Turbo Pascal by my friends.
To check quality of conversion please look in file
<A HREF = "examples/bgidemo.cxx">bgidemo.cxx</A> which was produces from
original Borland <HREF = "examples/bgidemo.cxx">bgidemo.pas</A> without
any manual changes. Moreover it is possible to compile it, link with
WinBGI library and run it under Windows or X-Windows.<P>
<H2><A NAME = "installation">PtoC installation</A></H2>
To build PtoC just try <CODE>make</CODE>. Converter consists of two
executable files: <CODE>ptoc</CODE> - converter itself and
<CODE>cganal</CODE> - analyzer of call graph, runtime library
<CODE>libptoc.a</CODE>, configuration file for converter <CODE>ptoc.cfg</CODE>,
Pascal header for converter <CODE>ptoc.pas</CODE>
(<CODE>tptoc.pas</CODE> for Turbo Pascal) and include file for all converted
sources <CODE>ptoc.h</CODE>. To run converter you should only specify path to
directory with <CODE>ptoc</CODE> and <CODE>cganal</CODE>. To compile and link
converted files you should specify for compiler and linker path to header
file <CODE>ptoc.h</CODE> and library <CODE>libptoc.a</CODE>.<P>
I compile PtoC at Unix with GCC or CXX (Digital C++ compiler).
I hope that many other C++ compilers also can do it.
In MS-Windows I use Microsoft Visual C++ 5.0. You should
either explicitly specify name of makefile: <CODE>nmake -f makefile.mvc</CODE>
or use <CODE>make.bat</CODE> which do exactly the same.
Also makefile for Borland C++ <CODE>makefile.bcc</CODE> is prepared.
To invoke Borland linker issue command <CODE>make.exe -f makefile.bcc</CODE>
(<CODE>.exe</CODE> extension is significant, otherwise <CODE>make.bat</CODE>
will be executed)<P>
I have used converter in following way:
<PRE>
rm */*.[ch] call.grp
for name in */*.pas
do
$(PTOC_DIR)ptoc -I include -h -in $name -c -analyze -intset -init -unsigned
done
$(PTOC_DIR)cganal
</PRE>
In directory <CODE>examples</CODE> there are several Pascal files and
makefile which converts and compiles this files.
Examples will be build also by issuing <CODE>make</CODE> command.
You can look in this makefile at the examples of using PTOC
and compiling converted code.
To compile sources produced from Turbo Pascal files,
do not forget to specify <CODE>-DTURBO_PASCAL</CODE> option.<P>
Directory WinBGI contains source and header file for
BGI emulator for MS-Windows as well as makefile for Microsoft Visual C++
(makefile.mvc) and Borland C++ (makefile.bcc) to build this library.
Directory Xbgi contains sources of BGI emulator for X-Windows.<P>
Directory "vms" contains VMS specific versions of Pascal
runtime library emulation module "io.c".<P>
If you want to make some changes in scanner or parser you need
GNU bison and flex. For MS-Windows you can download this tools
for example from
<A HREF="ftp.keme.co.uk/pub/winsite-mirror/win95/programr/flexbison.zip">
flexbison.zip</A>.
File produced by GNU flex contains reference to <CODE>unistd.h</CODE>.
At Windows you can either remove this reference or create file
with this name.<P>
<H2><A NAME = "paslib">Pascal runtime library emulation</A></H2>
<H3><A NAME = "paslib.arrays">Arrays</A></H3>
All Pascal arrays in C are stored as zero based (first element has
offset 0). Low value of Pascal array bounds is subtracted from index
expression. When array is passed to conformant array parameter or
to input/output functions Pascal array bounds are passed before array
pointer. Low bound is always passed as it was mentioned in Pascal
array definition (symbolic constant or integer literal).
High bound is calculated depending on value of low bound (if it is
explicit constant) and whether variable is formal parameter.
if variable is not formal parameter and low bound is either 0 or 1
macro <CODE>items(x)</CODE> is used to calculate high array bound:
<PRE>
#define items(x) (sizeof(x)/sizeof(*(x)))
procedure foo(a : array [l1..h1,l2..h2:integer] of char); external;
var a : array [1..10,-10..10] of char;
begin foo(a); end;
==>
foo(const int l1, const int h2, const int l2, const int h2,
char* arr);
char a[10][21];
{ foo(1, items(a), -10, items(*a), *a); }
</PRE>
If left operand is not formal parameter and hence 'sizeof' operation
can be used to obtain array size two macros are used to copy and
compare array:
<PRE>
#define arrcmp(a,b) memcmp(a, b, sizeof(a))
#define arrcpy(a,b) memcpy(a, b, sizeof(a))
</PRE>
If left operand is formal parameter sizeof operator is applied to it's
type:
<PRE>
foo(str5 s) {
memcpy(s, "12345", sizeof(str5));
}
</PRE>
When string is passed as actual parameter for conformant array macro
<CODE>array(s)</CODE> is used to calculate bounds of string:
<PRE>
#define array(s) 1, sizeof(s)-1, (s)
</PRE>
PtoC provides special type <CODE>zero_terminated_string</CODE>
for passing zero terminated strings to C functions.
Consider for example the following definition of function:
<PRE>
function putenv(s : zero_terminated_string); external;
</PRE>
This function can be called in the following way:
<PRE>
procedure foo(a : array [1..10] of char);
begin
putenv('VERSION=1');
putenv(a);
end;
==>
void foo(array<1,10,char> a)
{
putenv("VERSION=1");
putenv(lpsz(a));
}
</PRE>
Function <CODE>lpsz(a)</CODE> converts array to zero terminated string.
This function use static circular buffers for coping array elements
to it and appending '\0' symbols at the end.<P>
In C++ arrays are implemented by following template C++ classes:<P>
<DL>
<DT><CODE>array<low_bound, high_bound, type></CODE><DD>
One dimensional array with fixed bounds.
<DT><CODE>conf_array<type></CODE><DD>
Conformant array.
for more details.
<DT><CODE>matrix<low_1, high_1, low_2, high_2, type></CODE><DD>
Two dimensional array with fixed bounds.
<DT><CODE>conf_matrix<type></CODE><DD>
Conformant two dimensional array.
</DL>
See <A HREF = "#C++ parameters">Passing parameters in C++</A> for
more details about passing of array parameters.<P>
Methods of classes <CODE>array, conf_array, matrix, conf_matrix</CODE>
performs bounds checking by means of <CODE>assert()</CODE> statement.
If, for example, array index is out of bounds, assertion will fail and
program will be abnormally terminated. To avoid asserts overhead
you should define <CODE>NDEBUG</CODE> macro (pass <CODE>-DNDEBUG</CODE>
options to the C++ compiler).<P>
<H3><A NAME = "paslib.sets">Sets</A></H3>
By default converter use single set type for all Pascal sets.
This set type can handle sets with card up to 256 elements
(consequently size of set is 256/8 = 32 bytes). Following functions
implement Pascal operations with sets:
<PRE>
boolean subset(set a, set b); /* if a is subset of b */
boolean inset(SetElemType elem, set s);
boolean equivalent(set a, set b);
set join(set a, set b);
set difference(set a, set b);
set intersect(set a, set b);
</PRE>
There is a special constructor for set constants: setof().
This function takes varying number of arguments each of them
is either set element or range of elements, defined by macro range(a,b).
List of elements should be terminated with <CODE>eos</CODE>
(end of set) constant:
<PRE>
s := [' ', '!', '?', '_', '0'..'9', 'a'..'z'];
==>
s = setof(' ', '!', '?', '_', range('0','9'), range('a','z'), eos);
</PRE>
In C++ work with Pascal sets is encapsulated in <CODE>set_template</CODE>
class. Instantiation of this class with constant <CODE>MAX_SET_CARD</CODE>
as parameter is used as standard Pascal <CODE>set</CODE>.
Sets of enumerations are created by <CODE>set_of_enum(e)</CODE> macro:
<PRE>
typedef set_template<MAX_SET_CARD> set;
#define set_of_enum(e) set_template<last_##e>
</PRE>
<H3><A NAME = "paslib.math">Mathematical functions</A></H3>
This is one to one correspondence between Pascal and C mathematical
functions:<P>
<TABLE BORDER WIDTH=60%>
<TR BGCOLOR="#A0A0A0"><TH>Pascal</TH> <TH>C</TH></TR>
<TR><TD>sin</TD> <TD>sin</TD></TR>
<TR><TD>cos</TD> <TD>cos</TD></TR>
<TR><TD>tan</TD> <TD>tan</TD></TR>
<TR><TD>arctan</TD> <TD>atan</TD></TR>
<TR><TD>ln</TD> <TD>log</TD></TR>
<TR><TD>sqrt</TD> <TD>sqrt</TD></TR>
</TABLE><P>
Functions <CODE>trunc(), pred(), succ(), bitsize(), odd(), chr(), ord()</CODE>
are implemented by macros in the following way:
<PRE>
#define trunc(x) ((integer)(x))
#define pred(type,x) ((type)((x) - 1))
#define succ(type,x) ((type)((x) + 1))
#define bitsize(x) (sizeof(x)*8)
#define odd(x) ((x) & 1)
#define chr(n) ((char)(n))
#define ord(c) ((int)(unsigned char)(c))
</PRE>
Round function is implemented as
<PRE>
trunc(x+0.5) x >= 0
round(x) =
trunc(x-0.5) x < 0
</PRE>
Pascal function <CODE>size(x)</CODE> is replaced with C operator
<CODE>sizeof(x)</CODE>.
<H3><A NAME = "paslib.io">Input/Output</A></H3>
We use standard C io library to emulate Pascal input/output.
Pascal file type is emulated by C macro file(r) which defines structure
containing file descriptor and current record. There are following
fields in file descriptor: pointer to C FILE structure, file name,
last IO-operation error status, open mode, file status (and FAB pointer
for OpenVMS system). Special macros are used for all Pascal
file accessing procedures which scatter file structure fields
and call corresponding functions. Bellow there is a table
specifying mapping between Pascal functions, macros and C functions:<P>
<TABLE BORDER WIDTH="63%">
<CAPTION>Mapping between Pascal and C I/O functions</CAPTION>
<TR BGCOLOR="#A0A0A0"><TH>Pascal</TH> <TH>C macro</TH> <TH>C function</TH></TR>
<TR><TD>rewrite</TD> <TD>rewrite</TD> <TD>pio_rewrite_file</TD></TR>
<TR><TD>reset</TD> <TD>reset</TD> <TD>pio_reset_file</TD></TR>
<TR><TD>get</TD> <TD>get</TD> <TD>pio_get_record</TD></TR>
<TR><TD>put</TD> <TD>put</TD> <TD>pio_put_record</TD></TR>
<TR><TD>eof</TD> <TD>eof</TD> <TD>pio_check_end_of_file</TD></TR>
<TR><TD>read</TD> <TD>sread</TD> <TD>pio_read_record (1)</TD></TR>
<TR><TD>write</TD> <TD>swrite</TD> <TD>pio_write_record (1)</TD></TR>
<TR><TD>close</TD> <TD>close</TD> <TD>pio_close</TD></TR>
<TR><TD>seek</TD> <TD>seek</TD> <TD>pio_seek_file</TD></TR>
<TR><TD>rename</TD> <TD>rename</TD> <TD>pio_rename_file</TD></TR>
<TR><TD>break</TD> <TD>flush</TD> <TD>pio_flush_file (2)</TD></TR>
<TR><TD>delete</TD> <TD>delete_file</TD> <TD>pio_delete_file (2)</TD></TR>
<TR><TD>iostatus</TD> <TD>iostatus</TD> <TD>pio_iostatus (2)</TD></TR>
<TR><TD>ioerror</TD> <TD>ioerror</TD> <TD>pio_ioerror (2) </TD></TR>
<TR><TD>noioerror</TD> <TD>noioerror</TD> <TD>pio_ignore_error (2)</TD></TR>
<TR><TD>-</TD> <TD>scopy</TD> <TD>pio_copy_record (3)</TD></TR>
<TR><TD>-</TD> <TD>access</TD> <TD>pio_access_recprd(3)</TD></TR>
<TR><TD>-</TD> <TD>store</TD> <TD>pio_store_record (3)</TD></TR>
</TABLE>
<OL>
<LI> read and write with first file parameter
<LI> Oregon Pascal extensions
<LI> This macros are used for translation of some Pascal constructions.
</OL>
Let the following variable are defined:
<PRE>
type rec = record ... end;
var f, g : file of rec;
r : rec;
</PRE>
Then translation translation for the following construction will be:
<PRE>
r := f^;
f^ := r;
f^ := g^;
==>
r = *access(f);
store(f, r);
scopy(f, g);
</PRE>
We use lazy evaluation strategy for implementing Pascal file access.
Current record is red from disc only when it is accessed.
To handle current state of current record two flags are used:
<CODE>fs_record_defined</CODE> and <CODE>fs_next_pos</CODE>. First flag is used
to mark record which is either red from disk or was assigned
a value. Flag <CODE>fs_next_pos</CODE> is set when pointer in file
is moved to position after current record. There is the
following invariant: flag <CODE>fs_next_pos</CODE> is set only when
flag <CODE>fs_record_defined</CODE> is set. A table below shows state
of this flags after execution of some functions: <P>
<TABLE BORDER>
<CAPTION>Flags settings</CAPTION>
<TR BGCOLOR="#A0A0A0"><TH>function</TH> <TH>fs_next_pos</TH> <TH>fs_record_defined</TH></TR>
<TR><TD>pio_rewrite_file</TD> <TD>0</TD> <TD>0</TD></TR>
<TR><TD>pio_reset_file</TD> <TD>0</TD> <TD>0</TD></TR>
<TR><TD>pio_get_record</TD> <TD>0</TD> <TD>0</TD></TR>
<TR><TD>pio_put_record</TD> <TD>0</TD> <TD>0</TD></TR>
<TR><TD>pio_read_record</TD> <TD>0</TD> <TD>0</TD></TR>
<TR><TD>pio_write_record</TD> <TD>0</TD> <TD>0</TD></TR>
<TR><TD>pio_seek_file</TD> <TD>0</TD> <TD>0</TD></TR>
<TR><TD>pio_copy_record</TD> <TD>0</TD> <TD>0</TD></TR>
<TR><TD>pio_access_record</TD> <TD>1</TD> <TD>1</TD></TR>
<TR><TD>pio_store_record</TD> <TD>0</TD> <TD>1</TD></TR>
</TABLE><P>
Pascal write and read procedures working with text files are
replaced with <CODE>twrite</CODE> and <CODE>tread</CODE> C functions when
first parameter is file and <CODE>cwrite</CODE> and <CODE>cread</CODE> when
console input/output is used.
This functions receive printf-like format string and varying
number of arguments. Format string can include arbitrary text
and format specifiers:<P>
<TABLE BORDER>
<CAPTION>Format specifiers for read and write operations</CAPTION>
<TR BGCOLOR="#A0A0A0"><TH>type</TH> <TH>read</TH> <TH>write</TH></TR>
<TR><TD>integer</TD> <TD>%i</TD> <TD>%i<P>
%<width>i</TD></TR>
<TR><TD>real</TD> <TD>%f</TD> <TD>%f<P>
%<width>f<P>
%<width>.<precision>f</TD></TR>
<TR><TD>char[]<P>(array of char)</TD> <TD>%s</TD> <TD>%s<P>
%<width>s</TD></TR>
<TR><TD>char*<P>const ok := 'ok'<P> (zero terminated string)</TD>
<TD>-</TD>
<TD>%z<P>%<width>z</TD></TR>
<TR><TD>short<P>unsigned short<P>[-32768..32767]<P>[0..65535]</TD>
<TD>%W</TD> <TD>-</TD></TR>
<TR><TD>char<P>unsigned char<P>[-128..127]<P>[0..255]</TD>
<TD>%B</TD> <TD>-</TD></TR>
</TABLE><P>
where <B><<I>width</I>></B> and <B><<I>precision</I>></B>
is either literal specified in
format string either symbol <CODE>'*'</CODE>. In former case value of this
qualifiers is specified <EMP>AFTER</EMP> (unlike C) corresponding parameter:
<PRE>
write(x:5:2); ==> cwrite("%5.2f",x);
write(x:w:p); ==> cwrite("%*.*f",x,w,p);
</PRE>
For symbols not preceding with <CODE>%</CODE> action performed
by read and write are:<P>
<TABLE BORDER>
<TR><TH>read</TH> <TH>write</TH></TR>
<TR><TD>
if character is <CODE>'\n'</CODE> then skip all input
character until newline character is reached;<P>
otherwise character is compared with next
input character and if not equal read operation fails</TD>
<TD>just output character</TD></TR>
</TABLE><P>
To output <CODE>%</CODE> character this symbol should be included in the
format string twice.<P>
Procedures <CODE>writeln()</CODE> and <CODE>readln()</CODE> are implemented
by the same functions but symbol <CODE>'\n'</CODE> is appended to the
formating string.<P>
Array arguments are passed to read and write function with low
and high bound specified before array pointer:
<PRE>
procedure foo(str : packed array [1..100] of char);
begin
writeln('str = ',str);
end;
==>
void foo(char str[100]) {
writec("str = %s\n", 1, 100, str);
}
</PRE>
In C++ template class <CODE>file<type></CODE> is used as wrapper
for these C <CODE>pio_</CODE> functions. PtoC uses <CODE>streamio</CODE>
like interface for converting Pascal IO operation in C++:
<PRE>
type
rec = record
code : integer;
name : array [1..10] of char;
end;
const
pi = 3.14;
var
f : file of rec;
r : rec;
begin
writeln('Hello world');
writeln('pi = ', pi:10:5);
write(f, r);
read(f, r);
r := f^;
f^ := r;
readln;
end.
==>
struct rec {
integer code;
array<1,10,char> name;
};
const real pi = 3.14;
file<rec> f;
rec r;
main()
{
output << "Hello world" << NL;
output << "pi = " << format(pi, 10, 5) << NL;
f << r;
f >> r;
r = *f;
store(f, r);
input >> NL;
return EXOT_SUCCESS;
}
</PRE><P>
The following table summirize rules of translation Pascal IO constructions
to C++:
<TABLE BORDER>
<TR BGCOLOR="#A0A0A0"><TH>Pascal construction</TH> <TH>C++ construction</TH></TR>
<TR><TD ALIGN="LEFT">
write(expr1, expr2, ..., exprN)<P>
writeln(expr1, ..., exprN)<P>
write(f, expr1, ..., exprN)<P>
writeln(f, expr1, ..., exprN)</TD>
<TD ALIGN="LEFT">
output << expr1 << expr2 << ... << exprN;<P>
output << expr1 << ... << exprN << NL;<P>
f << expr1 << ... << exprN;<P>
f << expr1 << ... << exprN << NL;</TD>
</TR>
<TR><TD ALIGN="LEFT">
read(lvalue1, lvalue2, ..., lvalueN)<P>
readln(lvalue1, ..., lvalueN)<P>
read(f, lvalue1, ..., lvalueN)<P>
readln(f, lvalue1, ..., lvalueN)</TD>
<TD ALIGN="LEFT">
input >> lvalue1 >> lvalue2 >> ... >> lvalueN;<P>
input >> lvalue1 >> ... >> lvalueN >> NL;<P>
f >> lvalue1 >> ... >> lvalueN;<P>
f >> lvalue1 >> ... >> lvalueN >> NL;<P>
</TR>
<TR><TD ALIGN="LEFT">
write(string_expr:width)<P>
write(integer_expr:width)<P>
write(real_expr:width:precision)</TD>
<TD ALIGN="LEFT">
output << format(string_expr, width);<P>
output << format(integer_expr, width);<P>
output << format(real_expr, width, precision);</TD>
</TR>
<TR>
<TD ALIGN="LEFT">file_variable^</TD>
<TD ALIGN="LEFT">*file_variable</TD>
</TR>
<TR>
<TD ALIGN="LEFT">file_variable^ := expr</TD>
<TD ALIGN="LEFT">store(file_variable, expr);</TD>
</TR>
</TABLE>
<H2><A NAME = "winbgi">BGI emulation</A></H2>
PtoC now provides emulation libraries of Borland Graphics Interface (BGI)
for X-Windows and Windows-95/NT are included in this distribution
(BGI emulators can be also used without converter for C programs using BGI).
I found source code of BGI emulator for X-Windows in Internet,
so I only have to do some changes and fix few bugs.
Unfortunately this emulation library is not fully completed and
tested, also not all BGI functionality is supported.
And BGI emulator for MS-Windows I created myself (in Internet I found
only commercial products). I called this library WinBGI.<P>
WinBGI strictly emulates most of BGI functions
(except using of non-standard drivers). Also may be mapping of fonts
is not correct. But as far as sources are also available, you can
easily customize them for your application. Unfortunately direct work
with palette colors (setpalette, setbkcolor, write and putimage modes other
than COPYPUT) is supported only for 256-colors Windows mode.
Also I have used this library for only few programs (bgidemo is
certainly the most complex one) so I can't guaranty that all
functions always work properly. I am also sorry for the lack of
parameter checking in WinBGI functions. So summarizing all above:<P>
WinBGI advantages:
<OL>
<LI> Allows you to run your old Turbo-C DOS applications in 32-bit mode
in normal windows. So you can easily overcome all 64Kb limitations
and getting 32-bit application by simple recompilation !
<LI> Graphics is much faster with WinBGI (because native Win32 API
is used with minimal emulation overhead) in comparison with
original application running in DOS session under Windows
(especially at my PPro-200 with NT).
Also it seems to me that some things (like switching of graphical
pages) are not working properly in DOS mode under Windows-NT.
<LI> You can use WinBGI for creating non-event driven graphical applications.
For example if you want to write a program which only draws
graphic of functions, it is not so easy to do with windows.
You have to handle REDRAW messages, create timers to output next
graphics iteration... It seems to me that BGI is much more
comfortable for this purposes: you just draw lines or points and do
not worry about window system at all...
</OL><P>
WinBGI shortcomings:
<OL>
<LI> Handling of Windows events is done in BGI functions
<CODE>kbhit(). getch() and delay()</CODE>.
So to make your application work properly You should
periodically call one of this functions. For example,
the following program will not work with WinBGI:
<PRE>
initgraph(&hd, &hm, NULL);
while (1) putpixel(random(640), random(480), random(16));
closegraph();
</PRE>
Correct version of this program is:
<PRE>
initgraph(&hd, &hm, NULL);
while (!kbhit()) putpixel(random(640), random(480), random(16));
closegraph();
</PRE>
<LI> To handle REDRAW message WinBGI has to perform drawing twice:
at the screen and in the pixmap which can be used while redrawing.
I find that speed of drawing is still very fast but if you want to
make it even faster you can assign 0 to global variable
<CODE>bgiemu_handle_redraw</CODE>. In this case drawing is performed
only at the screen but correct redrawing is not possible.
If your application makes some kind of animation (constantly updates
pictures at the screen) then may be storing image in the pixmap is not
necessary, because your application will draw new picture instead of old
one.
<LI> Work with palette is possible only in 256-colors Windows mode.
I don't know how to solve this problem with Win32
(I am not going to use DirectX).
<LI> It is still not so good tested and not all BGI functionality
is precisely simulated. I am hope that current version of WinBGI
can satisfy requirements of most simple Turbo-C graphics applications.
</OL><P>
By default WinBGI emulates VGA device with VGAHI (640x480) mode.
Default mode parameter can be changed using <CODE>bgiemu_default_mode</CODE>
variable. Special new mode VGAMAX is supported by WinBGI, causing
creation of maximized window. To use this mode you should either
change value of <CODE>bgiemu_default_mode</CODE> variable to
<CODE>VGAMAX</CODE> and specify <CODE>DETECT</CODE> device type,
or specify <CODE>VGA</CODE> device type and <CODE>VGAMAX</CODE> mode.<P>
I am using Microsoft Visual C++ 5.0 to compile this application.
To build library and BGIDEMO example you should only issue command
<CODE>nmake -f makefile.mvc</CODE>.
As a result you will have library <CODE>winbgi.lib</CODE>,
header file <CODE>graphics.h</CODE>.<P>
<H2><A NAME = "structure">Structure of converter</A></H2>
Below there is a short description of converter itself:
<UL>
<LI> Scanner <A HREF = "lex.l">"lex.l"</A> is written using LEX.
It produces list of all tokens including comments and white spaces.
<LI> Parser <A HREF = "parser.y">parser.y</A> is written using YACC.
Parser takes from list of tokens created by scanner all tokens except
separators and creates object tree (classes are described in
<A HREF = "trnod.h">trnod.h</A> which nodes contain references to tokens.
All names are inserted in global name table
<A HREF = "nmtbl.h">nmtbl.h</A>.
<LI> Attributes are assigned to tree nodes by executing virtual method
<CODE>attrib()</CODE> <A HREF = "trnod.cxx">trnod.cxx</A>.
At this step symbol table <A HREF = "bring.h">bring.h</A> is created.
Classes for type expressions are implemented in
<A HREF = "tpexpr.cxx">tpexpr.cxx</A>.
<LI> Virtual method <CODE>translate()</CODE> is recursively called for all
nodes in tree <A HREF = "trnod.cxx">trnod.cxx</A>. This methods perform
conversion of input tokens (modify value, swap tokens, add new tokens)
and as a result prepare output list of tokens.
<LI> All tokens from output list of tokens are printed to target file
with intelligent preserving position and layout of tokens
<A HREF = "token.cxx">token.cxx</A>.
</UL><P>
<H2><A NAME = "cganal">Nested functions and call graph analysis</A></H2>
Converter can perform global call graph analyze in order to recognize
non-recursive functions and making static variables of such functions which
are accessed by nested functions. If you specify <CODE>-analyze</CODE> option,
converter appends to file "call.grp" information about callers and callees.
After conversion of all files special utility <CODE>cganal</CODE> can be used
to produced transitive closure of call graph and output list
of recursive procedures in file "recur.prc". When you run converter
once again (with <CODE>-analyze</CODE> option) information from this file is
used to mark recursive procedures.
This approach greatly increase readability of program as no extra
arguments need to be passed to nested functions.<P>
<H2><A NAME = "name conflicts">Resolving name conflicts</A></H2>
Resolving of names conflicts is controlled by file
<A HREF = "ptoc.cfg">ptoc.cfg</A> which is loaded by converter at startup.
This file specifies reserved symbols (C and C++ keywords),
names of functions from C standard library, names of macros defined by
converter, and mapping of names for some functions from pascal runtime.<P>
<H2><A NAME = "C parameters">Passing parameters in C</A></H2>
When converter produces C code, it doesn't copy arrays which are
passed by value. Instead of this converter declare such arrays as
<CODE>const</CODE>, so any attempt to modify contents of such array cause
C compiler warning or error. It seems to me, that there are usually few places
in program where procedure modifies array which is passed by value.
As a rule absence of VAR qualifier means that procedure only access
but not modify contents of the array. So we decide that efficient generation
of this most common is more important then some amount of manual job
which is necessary to correct places where array has to be copied.
You should only rename formal parameter, create local variable with original
name and copy value to it:
<PRE>
foo(str20 const name) {
...
}
=>
foo(str20 name_) {
str20 name;
memcpy(name, name_, sizeof(name));
...
}
</PRE>
<H2><A NAME = "C++ parameters">Passing parameters in C++</A></H2>
As far as Pascal arrays are represented in C++ by special class,
there is no problem with array parameter passing as in C.
But as far as arrays passed by value are very rarely modified
in called procedure, PtoC optimizes passing of arrays by value.
If array parameter, passed by value, is not changed in procedure
and is not passed by reference to another procedure, then PtoC
doesn't create copy of the array. This optimization can be
suppressed by <CODE>-copy</CODE> option. When this option is specified,
PtoC strictly emulates Pascal call semantic for arrays passed by value
(always create copy of the array). I don't know reasons of using this
options.<P>
PtoC implements conformant array by template class
<CODE>conf_array</CODE>. PtoC uses special macro
<CODE>copy_conformant_array()</CODE> to create copy of conformant array
passed by value when this array is modified within procedure or
option <CODE>-copy</CODE> is specified. This macro uses
<CODE>alloca()</CODE> function from C library, which allocates space from
the system stack.<P>
PtoC uses macro <CODE>as(type, string-constant)</CODE> for passing
string constant to the parameter of <CODE>array of char</CODE> type.
As far as PtoC wants to make it possible to initialize arrays
by means of C aggregate construction <CODE>{...}</CODE>, it is impossible
for array class to have constructor. That is why macro <CODE>as()</CODE>,
which calls method <CODE>array::make(char const* str)</CODE>, is used for
passing string constant as parameter. If size of string constant is less
than size of target parameter, then string is padded with spaces.
If size of string constant is greater than size of target parameter, then
string is truncated to the size of parameter.<P>
<H2><A NAME = "C functions">Calling of C functions</A></H2>
Sometimes C functions need to be called from Pascal code.
Sun Pascal has special "<CODE>EXTERNAL C</CODE>" qualifier for C procedures
called from Pascal. PtoC recognize this qualifier and treat it as
C (not C++) function declaration. There are some specific items
of conversion of declarations and calls of such functions:
<UL>
<LI><B>Zero terminated strings.</B>
Many C functions accept zero terminated strings
parameters. As far as character arrays in Pascal are not zero terminated,
some conversion of string should be done. PtoC provides function
<CODE>lpsz()</CODE>, which copies characters from Pascal array to internal
static cyclic buffer and appends them with <CODE>'\0'</CODE> symbol.
Passing of string literal requires no
conversion. Turbo Pascal <CODE>string</CODE> type can be implicitly converted
to zero terminated string without calling <CODE>lpsz()</CODE> method.
<LI><B>Variables passed by reference.</B>
When conversion to C++ is used, formal parameters declared with <CODE>VAR</CODE>
keyword are translated to C++ reference variables. So no explicit operation
to take address of actual parameter is required. But as far as there are no
references in C, references should be replaced with pointers and
explicit operation <CODE>"&"</CODE> is needed for actual parameters.
<LI><B>Array passing</B>.
Arrays in C are treated as pointers. When C++ is used as target language and
function is declared with <CODE>"EXTERNAL C"</CODE> qualifier, formal
parameter of such function belonging to array type are translated to
pointer of the array element type. Actual parameters are passed by means
of <CODE>body()</CODE> method, which returns pointer to the array elements.
</UL>
The following examples illustrate these items:
<PRE>
type smallstr = array [1..64] of char;
procedure foo(var x : integer; a : smallstr; b : zero_terminated_string);
external c;
var
i : integer;
s : smallstr;
begin
foo(i, s, s);
foo(i, 'abc', 'xyz');
end.
----------------------------------------------
typedef array<1,64,char> smallstr;
extern "C" void foo(integer* x, char* a, char* b);
int main()
{
integer i;
smallstr s;
foo(&i, s.body(), lpsz(s));
foo(&i, "abc", "xyz");
return EXIT_SUCCESS;
}
</PRE>
<H2><A NAME = "assignment">Array assignments</A></H2>
Some C++ compilers don't allow classes with any assignment operators
to be members of unions (for correct implementation it is only
necessary that such classes should not redefine DEFAULT assignment operator).
As far as arrays can be members of variant components in Pascal,
converter can generate code without using of assignment operator for
string and character constants. If your specify <CODE>-assign</CODE> option,
converter will use <CODE>assign(str)</CODE> method of array instead of
<CODE>operator =</CODE> for assignment of string and character constants to
array. But PtoC still use default <CODE>operator=</CODE> generated by compiler
for assignment of one array to another. To compile code produced
with <CODE>-assign</CODE> option, pass <CODE>-DNO_ARRAY_ASSIGN_OPERATOR</CODE>
option to C++ compiler.<P>
PtoC translates assignment of string constant to variable of
fixed array type by means of <CODE>as(type, string-constant)</CODE> macro,
which performs conversion of string constant to the type of destination
variable. If size of string constant is less
than the size of the destination variable, then string is padded with spaces.
If size of string constant is greater than size of the destination variable,
then the string is truncated to the size of destination variable,<P>
<H2><A NAME = "string">Conversion of Turbo Pascal strings</A></H2>
For conversion of Turbo Pascal classes <CODE>string</CODE> and
<CODE>varying_string</CODE> were designed to represent correspondent
Pascal types. This classes
have constructors and assignment operators and so they can not
be initialized using C aggregates notation {} and can not be used
as components of unions (GCC allows to initialize classes with constructors
with {}). To avoid this problem either manually replace such places
with C arrays or use option <CODE>-cstring</CODE> of compiler.
When this option is set converter replaces type of string
component of records or arrays with C pointer to zero terminated string
<CODE>const char*</CODE>. This approach works well only when this types are
used to declare constants.<P>
<H2><A NAME = "porting">Some porting problems</A></H2>
<H3><A NAME = "integer">Representation of integer type</A></H3>
When your are porting application from 16-bit architecture platform
you may want to preserve integer size (2 bytes). In this case
you can face with two problems: one is that pointers will not
more fit into such integers. Converter can't help your in this
case. You should change types of some variables and records fields.
And second problem is less obvious. In language C <CODE>short</CODE> and
<CODE>char</CODE> operands are converted to <CODE>int</CODE> type before
operation takes place.
So if you you compare for equality variables of signed and unsigned type
declared in Pascal as
<PRE>
type
word : -32768..32767
uword : 0..65535
var
v1 : word;
v2 : uword;
</PRE>
containing the same value (for example 40000) then result will be
false (unlike original application) !
This is because variable with signed type will be
converted to integer with sign extension while variable with unsigned
type - without sign extension. To help to deal with this problem
converter provides option <CODE>-unsigned</CODE>, which force converter to
insert explicit type conversion in such operations. Lets look at the
translation the following Pascal construction with and without
<CODE>-unsigned</CODE> option:<P>
<TABLE BORDER>
<TR BGCOLOR="#A0A0A0"><TH>Pascal</TH>
<TH>C without <CODE>-unsigned</CODE></TH>
<TH>C with <CODE>-unsigned</CODE></TH></TR>
<TR><TD>if v1 = v2 then ...</TD>
<TD>if (v1 == v2) ...</TD>
<TD>if ((uword)v1 == v2) ...</TD>
</TABLE><P>
It is not recommended to use 2-byte C types for representing
INTEGER and WORD Turbo Pascal types, because structures and functions
of BGI emulation library deal with original C <CODE>int</CODE> type.
Also I see no much sense in using short types for converted
Turbo Pascal applications because in this case you can not receive benefits
of 32-bit architecture, it is better to run original application.<P>
<H3><A NAME = "set">Implementation of Pascal sets</A></H3>
Sometimes it is necessary to preserve original size of data structure.
For example if structure is mapped to another structure by means of union
(record with variants in Pascal) or is extracted from file. There are
two options in converter which can help you in this case. First
option is <CODE>-intset</CODE>, which order converter to generate short sets
(2 or 4 bytes) for sets of enumeration types, Operations with
short sets are implemented by macros using bit arithmetic.
(so they are significantly faster than operations with universal sets).
Disadvantage of using short sets is that adding elements to enumeration
may cause problems in future.<P>
<H3><A NAME = "enum">Enumeration types</A></H3>
And another option is <CODE>-smallenum</CODE>.
The problem is that <CODE>enum</CODE> type in C is treated by many compilers
as integers and there are no ways to make compiler use less bytes for their
representation. When you specify option <CODE>-smallenum</CODE> converter
replaces original enumeration type definition with
<CODE>unsigned char</CODE> or <CODE>unsigned short</CODE>
definitions according to number of elements in enumeration. So construction
<PRE>
colors = (red, green, blue);
</PRE>
will be translated to
<PRE>
typedef unsigned char colors;
enum {red, green, blue};
</PRE>
Size of <CODE>colors</CODE> type will be 1.
And without <CODE>-smallenum</CODE> size of <CODE>colors</CODE>
type depends on compiler and usually will be equal to the
size of integer (4):
<PRE>
enum colors {red, green, blue};
</PRE>
<H2><A NAME = "style">Style of converted sources</A></H2>
As was mentioned above converter tries to preserve original
indentation of converted sources. But if Pascal sources are not properly
aligned you can reformat produced C code using some indentation
utility, for example GNU indent, which is freely distributed
(GNU indent has one interesting bug: it fails to work with
files with empty comments <CODE>/**/</CODE> which are produced from popular
Pascal <CODE>{}</CODE> comments. To avoid this problem just replace such
comments with <CODE>/* */</CODE> or something else).<P>
<H2><A NAME = "modules">Includes in ANSII Pascal</A></H2>
PtoC supports %include operator (used in Oregon Pascal).
This operator works like C #include directive, performing text substitution.
This operator can be used in one of the following forms:
<PRE>
%include file { "file.pas" will be included }
%include '../../file.inc' { "../../file.inc" will be included }
%include file.con ; { "file.con" will be included }
</PRE>
The statements above will be converted to
<PRE>
#include "file.h"
#include "../../file_inc.h"
#include "file_con.h"
</PRE>
If several files include the file with variables declarations,
then this variables will be multiple defined. This problem
can be solved either by passing option to linker to merge symbols
with the name (most linkers have such option), either by using
<CODE>-extern</CODE> option. Specifying <CODE>-extern</CODE> option tells
the converter to prepend each variable declaration in included file by
<CODE>EXTERN</CODE> qualifier. <CODE>EXTERN</CODE> is defined as
<CODE>extern</CODE> in ptoc.h and is redefined to <CODE>""</CODE>
(empty string) if:<P>
<OL>
<LI> included file name without extension is the same as name of
converted file without extension
<LI> included file name extension is ".var"
</OL>
<H2><A NAME = "options">PtoC options</A></H2>
<DL>
<DT>-I [.]<DD>
Include path (colon separated directory list). PtoC will search for included
Pascal files in all specified directories.
<DT>-in<DD>
Input Pascal file. Exactly one input file should be specified for PtoC.
Keyword <CODE>-in</CODE> can be skipped if name of the file doesn't start
with minus sign.
<DT>-out<DD>
Name of output C/C++ file. If output file name is not specified, PtoC
will creates file with the same name as source Pascal file with extension
replaced with ".cxx" (or with one specified by <CODE>-suf</CODE> option).
<DT>-suf [.cxx]<DD>
Output C/C++ file name suffix.
<DT>-c<DD>
Translate into ANSI C. By default converter produce C++ output.
<DT>-assign<DD>
Do not use assignment operators for array. Use method
<CODE>array::assign()</CODE> instead.
See <A HREF = "#assignment">Array assignments</A>
<DT>-analyze<DD>
Analyze call graph to find non-recursive functions.
Makes <CODE>static</CODE> all variables from non-recursive functions,
which are accessed from nested functions.
See <A HREF = "#cganal">Nested functions and call graph analysis</A>
<DT>-intset<DD>
Use integer types for short sets of enumerations.
See <A HREF = "#set">Implementation of Pascal sets</A>
<DT>-init<DD>
Call pio_initialize() function from main(). Invocation of this function
performs initialization of Pascal runtime library structures.
This functions must be called in VMS and for Turbo Pascal if ParamStr
or ExitProc variables are used.
<DT>-smallenum<DD>
Use for enumerated types as small bytes as possible.
See <A HREF = "#enum">Enumeration types</A>
<DT>-unsigned<DD>
Generate correct code for sign/unsigned comparisons when application
is ported from 16-bit architecture to 32/64 bit platform with
preserving size of integer type (2 bytes).
See <A HREF = "#integer">Representation of integer types</A>
<DT>-h<DD>
Output only not existed header files.
By default PtoC performs conversion and output of all included files.
This option tells PtoC not to output existed files.
<DT>-turbo<DD>
Recognize Turbo Pascal extensions.
<DT>-cstring<DD>
Use <CODE>char*</CODE> type for string fields in records and arrays.
<DT>-nological<DD>
Use <CODE>|</CODE> and <CODE>&</CODE> instead of <CODE>||</CODE> and
<CODE>&&</CODE> for boolean operations.
<DT>-extern<DD>
Declare all variables from included files with <CODE>EXTERN</CODE> qualifier.
<DT>-preserve<DD>
Preserve case of identifiers.
By default PtoC translates all names to lowercase. If you prefer
to preserve original style of using uppercase and lowercase
letters, then use this option.
<DT>-nested<DD>
Nested comments. Do not mix <CODE>(* *)</CODE> and <CODE>{ }</CODE> comments.
By default PtoC consider <CODE>(* ... }</CODE> as valid comment.
Setting this option makes it possible to enclose one type of comments
insize another one: <CODE>(* outside comment { inside comment } *)</CODE>.
This rule is the same as in Turbo Pascal, so
this option is implicitly set by <CODE>-turbo</CODE> option.
<DT>-copy<DD>
This option is meaningful only for C++ conversion. When this option is set,
PtoC strictly emulates Pascal call semantic for arrays passed by value
(always create array copy). By default PtoC optimizes passing of array
parameter by value. Array parameter is copied only if it is changed
within procedure or it is passed by reference to another procedure.
See <A HREF = "#C++ parameters">Passing parameters in C++</A>
<DT>-pascall []<DD>
Specify modifier (pascal, WINAPI...) for converted functions.
<DT>-comment_tags<DD>
Place in comments tags of Pascal variant records. By default
PtoC just skip this tags and doesn't output them to C file.
in comments tags of Pascal variant records. By default
PtoC just skip this tags and doesn't output them to C file.
<DT>-namespace<DD>
Place Turbo Pascal units in separate namespaces:
<PRE>
unit foo;
interface
var
a : integer;
implementation
end.
---------------------------------------------
namespace foo {
integer a;
}
unsing namespace foo;
</PRE>
</DL><P>
<H2><A NAME = "bugs">Known bugs</A></H2>
<UL>
<LI> Arrays with dimension greater than 2 should be written in form
<PRE>
array [l1..h1] of array [l2..h2] of array [l3..h3] of something
instead of
array [l1..h1,l2..h2,l3..h3] of something
</PRE>
<LI> Converter translates ranges in case statement in the following manner:
<PRE>
case x of switch (x) {
'a'..'z': => case RANGE_26('a','z'):
0..9: case RANGE_10(0,9):
-100..100: case -100 ... 100;
low..high: case low ... high;
end; }
</PRE>
Unfortunately '...' C extension is supported only by GCC.
<LI> <CODE>CHAR</CODE> type in Turbo Pascal is unsigned and in most
implementations of C/C++ by default is signed. To avoid the problem
with comparison of chars with code greater than 127 use option of
C++ compiler forcing <CODE>char</CODE> type to be unsigned.
<LI> The following Turbo Pascal contructions are not recognized by PtoC:
segment prefixes (<CODE>$0000:$1000</CODE>), explicit address specification
for variable (<CODE>ABSOLUTE</CODE> statement), inline assembler,
<CODE>INTERRUPT</CODE> quilifier in function or procedure definition.
Only the following Turbo Pascal compiler directives are recognized by PtoC:
<CODE>$I, $IFDEF, $ELSE, $ENDIF, $IFNDEF, $DEFINE, $IFOPT</CODE>. Other are
treated as normal comments.
</OL>
<H2><A NAME = "distribution">PtoC distribution</A></H2>
PtoC is shareware and is distributed in the hope to be useful.
Your are free to use this converter, modify the sources
and do with this converter everything else you want.
Also feel free to ask me any questions about the converter
and BGI emulator for Windows. Shareware status doesn't mean
lack of support. I will do my best to fix all reported bugs
and will help you to tune PtoC to fit your requirements.
Also e-mail support is guaranteed.
<HR>
<P ALIGN="CENTER"><A HREF="http://www.garret.ru/~knizhnik">
<B>Look for new version at my homepage</B></A><B> | </B>
<A HREF="mailto:[email protected]">
<B>E-mail me about bugs and problems</B></A></P>
</BODY>
</HTML>
ptoc's People
Contributors
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.