- Gpc - gnu.de

gpi-hash.c segfaults
by Bill Currie 22 Jul '97

22 Jul '97

I just applied both sets of patches to gpc to take it up to 970721 (hopefully properly) and unfortunatly, gpc still segfaults in get_uid. After some searching of the code for gpi-hash.c, and having a good look at my code that causes gpc to crash, I realised that there is no provision for REMOVING symbols (trees?) from the hash table. I thought of looking for this because the files that cause me problems re-use parameter names or record member names. If a tree that has been put in the hash table is ever destroyed (I don't know if this happens as I don't know the internals of gpc), it seems a pointer to the destroyed tree/hash bucket will still exist in the hash table. This could very easily be causing the invalid pointer dereferencing. Hmm, I just tried out my previous sample file (under windows 95) and got a crash as well, so my above reasoning may be incorrect. here is the stack dump: Exiting due to signal SIGSEGV Page fault at eip=000ee4d0, error=0004 eax=0c000000 ebx=000003f1 ecx=ff905350 edx=ec000009 esi=ff905350 edi=ff8e16a0 ebp=ff8de948 esp=ff8de944 program=C:\DJGPP\BIN\GPC1.EXE cs: sel=0117 base=82f23000 limit=ff975fff ds: sel=011f base=82f23000 limit=ff975fff es: sel=011f base=82f23000 limit=ff975fff fs: sel=00f7 base=0001d710 limit=0000ffff gs: sel=012f base=00000000 limit=ffffffff ss: sel=011f base=82f23000 limit=ff975fff Call frame traceback EIPs: 0x000ee4d0 _get_uid+32, line 134 of gpi-hash.c 0x000ee61a _hashed_save+34, line 197 of gpi-hash.c 0x000ebf30 _store_tree+24, line 1139 of module.c 0x000ec5a3 _store_tree+1675, line 1417 of module.c 0x000ee741 _flush_suspended+133, line 246 of gpi-hash.c 0x000ed89c _create_gpi_files+576, line 2290 of module.c 0x001113ef _yyparse+31247, line 5994 of parse.c 0x000c9de2 _compile_file+1510, line 2232 of toplev.c 0x000cc1b9 _main+3221, line 3938 of toplev.c 0x00120bc6 ___crt1_startup+290 the command line uses was:gpc -O2 -o foo.o -c foo.pas The test file is attached. Sigh, this is getting frustrating (and probably more so for you, Peter) Bill -- Leave others their otherness. The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: foo.pas Date: 17 Jul 1997, 15:04 Size: 381 bytes. Type: Program-source

1 0

Re: Bugs with integer() in packed records
by Peter Gerwinski 21 Jul '97

21 Jul '97

According to Frank Heckenbach: > > I found some bugs with the new integer() types in packed records. Fixed. The uuencoded gzipped diff below should also fix some other bugs. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125] 8< ---- gpc-970719-970721.diff.gz.uu ----------------------------------------- begin 644 gpc-970719-970721.diff.gz M'XL(`,EQTS,"`^Q<>7/;1K+_F_P4LXHW)D60(GA((K6.+5.4(Z]$ZHETG%0V M!8/`D$0$`E@<.M;V=W_=/8.+ARPYM?5*]:@XQ-5S]73_^I@!>G/=F?&`35V? MS3R#37UW@2?5SD']0.W4BL6>I+`<-K5L.+EW(V;H#O.YX3I!Z$=&R&ZM<,[> M6H'K*(R'^BQ0V$*_YI8S=96B[IALS']E<_V&LPGG#G,75AARL\;8R%UPYDY9 M..<!EPWH/F>19^I`P?Z,@I!-[HN3R+)-RYDA(3/<A0>4/I3_379&T--3GT.1 MI2JA!G['C2@455@!UK&`CA6+C%%7V?CXW8AAAYEY8['JE%W`72Q=LYQB$4:/ M=9L6C#IT_7MLX-UECP5NY!L<ANOY[HUE0H^1S.%P+]"!+'1=.RB6EGE"_$"^ MA/S.:D"#91JU!?S4;1LX4RR.7:9[GGTOQV%:TRG4,'.ARJ6NI--%548!C[F4 MC)!Y>FC,6=53B\4IY\1)*R2RJ6O;[BW>H":8CE/M16&M.)YSG&5'7_"E%J$+ MT"ATLHAE6-5GU0]-5AVPZAW;K;GB8+LS>6V;>!+S$\]!<J;6K&;HQCQ[#:,/ MHP!OX)ANN!]8KE,SJ!I/]P.>.Y_'A#./^U-Q2;,H;M=>OT[/XDIK>G1'IZ^- M&L[$KKR_6YN'"UOTE^8?3T)7-)<\.QN,QL?GYWAZ>OG/F^#=X`.>!QXW`C$, MGX8C>XZG?ACD!X(WY'#C`<3C,#Q/GJIXM*T)]3C#("HQ^=U2C#^JU/5Y]D&8 MO0!9<JJ[M=\-9?X'7KM>"'T(Q$/JL3P-]85'=84+V2/N[,HG,_Z[6FW](>HS M[,BDX;VN5(C`$/TT#(/Z+;O/G7]'EN##U';UL#873,Y>+"([M&!\HD$XV17# MC!P3>(5L%,RZ@WFBHVT!9,0]MD)>XW>>F)N)?BU.@EO!/<.H-FH'M0;\)Z0^ MU8\];^_XP_CGX=4(;Z97Q6JUNI:L,)Y'[#W@"U-97>W6Z_"/J4!5K%0J^3H* MH\AA[R.;-9"BVVYW&_MPTCDHOGG#JG6ESBJJTFBP-V^*E2L^LX*0^X@B/=>[ M]ZW9/!0@C")UJ0>&;A<KKQ[S5ZP4*^^CZVN=_6+YH>YPIUAAS/`YX2>@B81` M?F=P#U7>!7RPL7D3P!A47T'ZB1[`M2M0[ETO!K8:UG[)L:OON`\H$5Q;V>J1 M9XYK\J!F\JDB\(1:`[P4PKC'%W=[BL`Z:AJ>F*ZQA[640G?&H8PO[`?PN?I> MU[VR(.=W(7<"ZX8#!BY<`!HK.Q[`?AJY+,-N8))`=MC/W/K3S/,`@:=J@Q4# MC5>RL*XPO%M--$->2^6@X6`]RR-BI1PO\T,M+W%APUB)IT`+:+"'/=H58\9+ M4=DNL?[8!K/U)_O%M=WKN7N39[U5G>O!O&8HZ?E<5&-8OF'SZB2:XM,E9F(E M"3_A)`)>&+(UF^D1C,H/8@G1)RX8;;+<>A!8,T=8.,N',4NY12'V=+"Y:&PJ MTRB,0/D-Z36@F4PD.C9=IS[G8/FGX2T:O:D+6J_C%+#2Z>BT7-L:E:U1>5Y& M1?C(YR";PB0DUZN&)7F4M1?U1K?>[#:EO4A-2TI\X4IBE:G[W<9!MZZFQD55 MFFA<FDTR+D@*9$B-%$BOJHPMH3C[AX<W:K/XQIO(L:K@M7('L/PGA(/"+I.V MK0L>[2UA6DT^N.H?GUST:Z=GYWWM_/BWX8<QP<QX>#+LQLY[3$M2",XH"FL7 MA0Y$-]2`7`-%-:Y+Y2[YK*!_W"%G%T,`!`7VZ77W9;:6\!Y$[!IKH7A`,S0# M@`<K,%VP6.BG^M:-!4CC(^,8U0^N+=11``C^B,B[J9DRT<2]`U.L"<!;`+5L M(5\I1#HWX"!;$&E`M\"WAS@!J[C1?4MWP)PO4%#2[L=PW04=`%G4YEP'N2R! M$0`9-C6!Q,E=&.)_N.\R+*.%^H18#[5_!/^<`A@$4A<`&&P,@"QX^O<8@P#= M(A`FAJBP./3UM>R%P+C[KN@D$&LPSFGD&*C&FFY@V*(M]/L)SXR^2PWK&":P M3V^FKON2V3>Z'<FP$5HUN!GYP/6XUD#T=:ICN-"%3C@F0#3B`\X-S!G%?**N M6LJT#?UQ7,TRN[(#D2P[X+<O,5;1J?A.7&9'C-US+0>D.T"+$\"$P53HPA!. MK3LA*9-H%L23`W&AC1,C1BX*:*85&#X@A*,+`9"C`(R`"#,@V*.VA2@"`H,P MVC92T@`];=#_V*5H%`'\$W#L):MBU+4@JSGALN\D/28W[",&IA,-[`Y@)'24 MVR8,1_<=BM8<&`KW?6#X`F/+F90'+`@2K5T[[JT#?`JP`ZBM6&W`=BZX><5U M>X<&OW/NHE4.Z4X\>.P?N$<0UH?(`V!0Y&F1(XR]AM5@E1CM^Q!<ROL.](%) M(a)1__=MG7?K\X&WRY./[U#^V7X_,/?6(M&^DA8%`*18UVMW7P9"AB12;U'P>+ M?02FNO8-1RT%_IB:G&[13S,R9+RJ+W345QUDQMPZ%5NGXGDY%6M,K/`*5A^L MNAFK-.1"7.@^:[28V@(][%*@FO,WUI3*1[50JME)'8^VJJ@M5L'#/OH>K&!4 M/5^?+?2:@6I;K#9KV309N_4Q\>>(-"/`*UE(=DRI+])9;X\%T23)--78V`4# M@X8V+)(P1BB?(L;"`>\R2D\!"0'[W(UL#&N9Z;N>AQG&8SMPE8SN&<P*BE6( MH6P(*W4FS"VY-JST#AB!&!X@2HMXJ@Q1YE\=`_*AD.F!O(I#+WDI3;.\$A9) M7B1:"7`K8'`*`@87HH]PDM15*<3U5`JRCDHA+<^P/!T#'KJ>K#'V3+(76&LV MC-SBYQ8_GQ=^8BPB<0U/5S$2[Q;&$6?'GH\)OD8=\4T]7$9%HLL&8&JW>=!M M9[)[346MLTI3:=8)!8O@YZ$.$&P@(DQP24+F0.+%"WIPZ_J@,J!P&$OX+.#@ M\B!<5-G9P@-7'F"/Z!86>)S@!?8QC8.K#+(RX(WKAWO6`@]LRG5,OJ#O564C MCP-=Y&$GR-4K5BYMW4F6>H!U*M`M_R%=E9T"F&*J#9UD`6L02TQXJ,<"7Q-T ME]R?ZQZ$.J@.;V$PZ&4&80104?IT3!'$2X5]\MP`#K5:K4S><EBU'-FE4Y$N MHI[E>R,:&,UQ8",(ZQQTUXFURTRP'"N$N,*">(E(*G^9>]C*_T10)>7(+!,J MPE,_[L&E#'FX#+7BZ`4"REE$S6+Z+)!,ZMD02_'X:CCY$^S"GH$WV1FZK1`F MX=,MP&X!]ED!;-8]D%"9\QA6`#?[M("QH0@,R1UM=ELKP)NGSSFB\*]^F,V` MM3$#UD;XK>[MLAZ5!+"93@%6?1<7?F6Z@A8X`)>+5<;2Q1=6ZI49@Q!U*3E] MFB2G%5!63),_7'MV^6:E?HJ!O]4``,P8T9;T&XZ@H&$^C8XT6[#8@L6S`HML M$EBJ=_;6*EADGZZ"17L%+'+T&6\-UVP;W68K`Q;M5I/BUO@$?3;YM[L7GUK@ MPI0HM75Q-A!)+5;";%@Y(<:_'W]DXZM^7^L-3^#Y6OHR>_4*1'C<?]>_TGHC MB-8+F8(?!J.S=X/^25PY/82_UU@$R;7S<99(8>L;20IV,P4?H!?Y;NQ&:6T_ M*K*ZIW<D*?G8GN0X^N5+S,;C7S>S?0/GEXJLY_PCF+]YV&O;45B8*YL?^,8B M&5Y]>QJ^ITO9PH_N4X;1(M]<VJ&-7CJXM6#JT!;10LA.^:C(?@"'&C0%C"+: MU+SVT'B&O_2O3L^''Z$)J'EKMK9FZ]F9+;'JD#$SXL9ZDR6>/69Q=SUU`Z@[ MN&"[UK=%1:/@$V)'L?)#KF-`JSO)ZAMYHKUTF^0:5U?M'!XJV$:#?IOTVZ+? M]C==X`=JJY*/^Q=<W%YOZ]YN<>)9XD2\.R&CW_&M]5@1/WTL6B3T*^YM-A9N M-]K[R@&KT+%5SWJW&1\KXSJ1[4=/Z7*(OM*5ALX!N@$%Z8VEI&Y">]4_/B=" M(EOUQU8)R46E?0/L5;S/0M`IC&Z#/U$I?":G)7$?1&7B\;(SE_&=AE<G9P/9 MSIH.EQ]%F_.+V>>D#&#NR8/;2Y34T=HE)/:XB>OVN'L.'"9![,)X059ODV5S M20\29UN&%>*N@9"2K+>T1=XW+0>WS.$R?BU3@'839O\>"%0J;/7O>P*6K!_Y M.%?U(7^59O/;T<-ZQ_7!PN6U0]X<4:SCSW=&%LO=?CR7GNS8"VU86]&CG'Q1 M?BVS8L'=X/*S*FA`Y!BXNPO=_USYK[2?)*.[2R-G?WNU''31I=!#V:FLHE+W M+Z_ZO;/1V7"0K67IP6HUFY18O!?AQ(845S9N76&1`H7QVBRK:92=GW'P0JH_ ML9XN%1(O<!L-WLBKI3P/T?EQ^"UMG0&H$_N#\$+#/;/KNGN4%%YB4%P-B-O: M@#4M&`,KM::RTF!XJ?5_O;Q2DJYD45;.5R$MMQ&0O\;6@]L!3RW)9\)]G.N_ MQ<J"7LP@5M&RL$7MPZ:R#[9H7]U7.HDI\CGN=!+AI;;0_6L--Y$?H6,HY4=( M+NGWU1G5FAB4-<_\>1"CQP_6U.3T;HZ03ME4:67;83Q2*$L3\`..#\7$<<-< M,/LY'G2,X%J\)PO;Q2`XD;`>58S>MUCEL6YXM8<;Y,#E<VW<LTY^[ZUEV^#W M!L!X/=W@-94<Z]0%QQIHQ5/C+?:FN9,_#0T=>[&]*QV#.*FGW9$#AT?RUE<< M8QRM9P<9,]UP<2L$</B7X=F),-DQ![;^^-8??V;^>+RI)?&?DUTN:WSQ^-GC M//&$.KLIH-%5][NM]N:X_8+VZ+`@\FBYN:2;IH5SA>ZD7$(J+Z\A?><:U7]S MY0F'UC@@C,)##%%!4+OF]V!(ZDE6$&]/<;<49Z4?`["O@?4?#O65@@"\$!6N MA0LA-CJ7TIW."65Z2^`:KO1KP*L)-\$V.JS"U'JC53Z"GO\`J`\L9)=7PUY_ M--(&X+N5'`7M"C#M7P1DD65J'G0QX*$&YU`%/`4#"14`!6WDJ!_@P)KU0SDP M`G]W.M7`/_>.T@O?>VK7T5):"^BYAOP%(`>],ZXU'!(WRTNF!J0[1P$,7"T+ M%6]Q>8O+SPJ7XXV*$DO3/9#+F!P_>0PBKZ/%/0('W4;CT7C\3>05"=).&_[? M5[X;AEO5[2Z`K?K_?U5_N3E9ZFVRY7E9^>6#Q^A^3)IUQ=K=]B&^:)*H?JL- MX2?8=3HVQ8)_(4TT7!Z/>C(AJ(UZ/_<OCG-!^HL7M"@J"KQXD83T&(:Y#G=" MS8>($\@4^:Z19IEH]`L%#+&_,'#T\(TAS05%T4/7AYN%S^S%/RR,V7["^H(( M1`("T^3-)[$+O02.R==OO1Y%SREM6J`8=)1]R^IVSO'=(_'2%GXG`]\Z<N3K M6UU1!A,=4_:)2`!I].2%+OR4QA3*.P:X-;(.2[QQ)8I1@@/3EOB:5;:<?!^G M%E/NB1/T@22OR4T[^7`%IQ3%OSU'1C<I<9-D;K()E2DV=I3>I*SGU-9GVNU< M#S5/[.C\D;W53C31!B4+ZN6T"$MB[=).1!M"Y<QDWNG"5\H$=RB_%1>=REQ. M1BJR`M(L9XE)1))\BI`5R1&1$RI-928."B;EOHH3RK*L\N"[>PX2<<Y#!MZQ M#EJOI<FO4IF%N$?90/L#EB46J^3=N0SCX@G,K>S+[&B>#<CSTP^#WOAL.)`I MA`S_B3.K7:&BF3YG>;"D<V*>M<C1_7M0*%8Z/CFYDHFN%TV1`,DS%-@3+?B* M:L7JUQ`%OH*Z?OGV6XA`=21CH+;:4I4.OORRWU'4@W7++/D<]$F_=ZX-CB]B MI@TO^U?'@Q,</$1#@G4!;71&_$@!IQG+7:X`97H2I7\N"OS?5B$F^?&](L_B MX58+A>\5=<HC/KEHUKQLU!"6(,2J-7J,9I#<MEHM6AYL'6(0+TSAUU1VOX@W M5]G+TLM4'Z0.N(+[],K5R_)++/E9L(HZ,OAP#E84ABI[^FTF9%<<-ZG/DH$> MOGW?[XUSM2U57,X9]TP'X&&20$9ME#GJ5OM`,*33B'<#YN0PY`OO*+[W-3,) M57$K_P(P*Q'_E#CO#[*OX=L`K)2PAZ0V%=ME3<'VDFE=KC:+B_F_1[>W,C&K M?%D&7\&"AP$Z,_M9?13(^DB94J1,B7DY/%14%2:FW:S'"!MS+)DA,("8TD<[ MJ`7A(I0#DRM>+_;+Y:.4V',]F]]P8&8=%")G+>0@7OPC)+/0?OJ$4\BXYL^8 MZY:#*OR-"8(?ZFVJ3YG.?)^HL(?^GMJO_ROI28%IXFGO^N.+_@4)DFZ$$0`> M!``@.OA">8)(V[!X&Q8_L[`8;O%@+R534[*'GJ\+G3>0TIN.[R&@!B15#[K- M>K?17(a)VF-Q7.?W^F?M!5LRL=9#_I%S'ZT1\8Q'?IL/]I:]ARS:CA=TVHOR/N M,;7!&DUH3VZ*;!>KU.'E0DOC:W2Z]48ROG7T2T/:3S(&#,>T7Z<E#CQ(WQ[^ M(118!I,?O4S>Y$S]-7$C^/T/]DHNE"!G&@?I2N[GG3?&CB)0;8>$D[XY9OS] ML^X$5O>P\Y7]_;/C!B&PT-C%BQ[^W.#/,5V?T>\E_)S]:Y6!TFF.F1@/$IER MV&VWNHW##4Q,"CZ!D6F9AYG9ZBB'K`*_,(62#VA$IJZ_6/8",5**[U_U3_M7 M_4&OGUV,CA>V5S<ZB"5P]`2DJ]MI(_?I-Q.=(4$VN@BB2:XD8ZOML%)O>'%Y MWO]UI2EE=0K,R1U]2T6*,7Y!$+D)"M/$+S>I]0TS$)=[P@0D11[F?Z?>06'& M@_A(U-)^CJD'86<(,Z('"[2&"MLYJJI'.Y*/:E,E!:<#E880:QB%H,00-28Q MI@@BD34UAA$I*C\%:_A^,VXXN.<A??]5M&IR_+X.+N7%'U>=W.%N(ZA5D4>` M$-SG/*4W?&&$CGM;6^4W3D/,;?&BD,,:'93WQK[$J?U5;HM23^"U++#*Z<,, MIQMUE5A-QX/#-;S6)[3Z*UG;.B09%0=)+`4/T02_[(/?F0#?[HZ57`]\5M=3 M%6;0PF7\,1Y/P>_X<425`OE.I1)>HPJ]/?\GGI97N0:P;%9IEU>6=P2X^[BK M%'G7V""IV;)/X&"NV,-\;!YVQ$HL'M7#K/[.7)2S('`-2P]QTY#(QXC],I6E M;3.4!47='7X8G)#R=I.*0(@_XB=N/6[J#N"Z`M)+.=V(/IB8)-9DWM3A%GV_ M,<F?KN&I3"@D'`6V#-P;UMC'CPNTZ_*3H.LXFI1<P\_F)GZFA1[F9JM]*-+? MATJCDVCP.PN_7Z:G:1!\HX#6P9`/3@CA`5KM^+&2V[N%"OM)&L*8XB45ML(: MI5!H4O;%I.SO9Y!CA%^3I)UXD8_?8J/&^)U8@A,V5'P.TIU"3QQ.'Z),QBIZ M08MC^!EG^ERR^!8+&M((O$/Z@*<U!4.-:K(&,,#KU"=!5NR',`I@'?H9(/;- M#9,4EWO"%"5%'IX@M;E/[@8=6\W$X9`QDGL-!DL5B'&@-I"EXD!T<4C,,EL= MK1LKP+F@+W`B3VU^1V#<765'[@-@&V"TK6Z`T5SA5<:H]0V,R9=;<2]C#!&^ M&$DO_*KMA#-@KYBU6("G"2"@X:8+3:0"I.FOD\N!AX::%$H0@;YPA$Y%#@W& M()-8$^ZUPSS%/7W`U9J2?0L3^<*=+&(K:7P'Y0\(.'X`E:93;9(54!L=Z+3X MYF^2A/CI)U;Z>3@::V_/QB/M$OR>CV<G?0U<("("JBI$\#Z(L`C7V'IBL7^7 M*NV*1$9N[V.%1O2_[5U;4QO'$GXVOV*B%R-T,;*$L)7P@(FQE2(<%Y)]SINR MH`4VD78I78RI%/_]S-?=<UOM2LCD)55VE0N0=GIZ>V9Z>GJ^[C[7NVZ63AYH M:?&],1Q3^D-29?:-U%BOW@7RCTRQBY.#E,'KR/S1)'+D!:ZM0%3+$.28KZ6/ MKZ*I^?&5<,*:P<2*IZ^L,[D=*GJZH"_S].I:6)"'R"R#TUG"JH'BL@ZZO?9! MB6HP[;90#;;)!HNBTR&#0O]HM8+IC\/S%-.50%<_G!X_G![_*J<'IR<3SX/) M=Y9W9_#G3P$"R),Y',#;,%'N_B%M"_*3%A,CH"UX^_Z6LW1#O7LV("Q'Y/"& M(8ATDG1FX<2=YG0RK^XTU![?P.$$&TT$#J#\3*)-9[N0"13Q91&BADA1)]=$ MA?HC4E^.+\BM:I*ZQO8V!(KNU_[@Y**O-2)P\+@.![@1T*,]8\(]BQTBI/\F M=CR"W\64EO6.H`W2K&X,29#F\^(#=E;YE"Q0#D!!48PX&A-/T5A+?D%4;!D, M]S(O@9?ZUEC>4?HE<ZP4SNCZ];3_O\^?SOJ#(:=7Y4G1VF_19HV?[99WU"A] M)XK+('<!;URA9\%\Z7#WQN<M+GQ^>JYEI]>$<Z6/3LZ.!X/`MTY]^($Z'-!" MP_2R_;(GH1SA]3"Y)=1K%TMS5)[8-G\7;=K:*!&],$ZUHAU^O/C/YP\?:4OV M6'@M+/!?OZQEJ/4,AEI/9:@5,!2O96C_&0SM;V9(O((]]]@X@QL$^9CY1OV1 MQY7N.$Q(#,^;1P$9Z!.;-F#A(.BV.FYRTMO9VY!>#CS\:L]>19%-"UL._]4D M(PPA)5+6*HSNBN:+!Q,Q?A[?]^Q,VZHE96-VIK3?OP)9M:L^+69?HID"U'KE MWZX^$^JE/HYF8]VD6M!Z0..B"=35,+HYQ=J=&UJZM4WLAM:U[^Y;TL(5TMC$ MP2<#(G`IIT%(E3!35R>F>%(V.X$X04L3>O=)910[%+0.1,(4>D>.X!`[D?=Z M0H<BUO0IQG"6?[/O)A2PIC92K(?R?A?(JN!M5T=I55@E#'R(%[_K,XP3\P`& MLC_RS$")<'];,A9F&GUCT]I+.7L?2PIRZ8.-`79`>"20D]S/1Z[_OH]16&.> M7V!/ZHP3G6.1F3SFM!'^P4R\],CY_*`WR\/<,M'<-&Q6?'FQ::G!Q"X1VW^Y M7QIU<"=D=*^6!][B'7<>VJCN49K$"VU?05-BZW8YZ%4E22=)&E>,P4(UN^#? MX=R3\?5U<I50EF`GD-LH1>D2PLNEZF(X\!!.8'.<^?XM2?W[-8G@Q8ZG=\TG M+);<U(:,"O5`K7QN^^K$/>>UH"21*1(6T[P@24O^>V\FK)>V1\[)?3MISYVX M/6I6\-\G;G_^WLZRY<VM"#^;0>$8L$@S2-!E_B`(!/!]DT5=S:.OL0FY]<`$ MM(MV.W0/U^D>&C\DX]]4@ZU*O=(0TSR7^G%T:AKKHUET%=N<@:RGFM+44!AD M&)(I5C(7YB&/)6??SS6UMC)GBMHK,L<)\(\QLW:U%%I@(V*K-H;55S92UZ*3 MY]4=XS5D^709'MU]>U!_4X)D)&$+A54HGT0C%[2SX;QGQ^<?1N^.!^\M(Q*S M6XA.R?6TAL#/#IOH6<[^$\7PE-)W"8D7B<(/[`YAB>LPH-+`C=TB'H]\+OR> MZVLI;?S'DOAXW#]7N]%=A$.$60MO.G09>]@R8PV03:'M.$APJ\>JAH^UYBJ` ME5"RD'6=5Q]<?=&C)-8M!YNS;M&JY=T23M4%%7(\U6LEU?L=`32Y@M8,-:4D MH:ZG)TJY4HFG*#<Q&"B>^!](a)T.VGDC'A!HBV74H(+SL"H_&E1J566L2^5-6J M%N_-Y^@1*@2^`0=UDL/O;*F/N(GN9OZ@S\A3HC>YCQY(D?%P'^ZWZZVW&.]V MI]YJ6^4G`?PRYLHE/>#(=77E+"[9&'$2X!HH8W7YP)GNX?V;N<QW>\8Q/HNG M<GLD^HL+?6G&3663(*?)QF9%:B\@P,Z;Y%J*DZ7+Z:46TY3Q+$2;232]5WUE M?Y_$Z8W6G8TC%\"!J'GYUOX"%2./_G2$\VS#XE\%&4*W$BG<+5I(Y):U0.*? M[!=5@R/\V_SBX_N=A)2>&-F,?4TTW2L&'4C,"+5:S7[XB%\>O<0@)G_?(LNX M0I"9K508Q])4%F^G%)2%2UI1A`D$Q@[]\:Y&5R\!!%=2L8BZ.6RW",39.3SP M,T`$!U9SBI9UW*"3)<VZ9J`%]P*(Y9[ZG#9<[N]@IXW5C39MZ%90[\;-L%V. MRFX_Y0,UUX5%M1B>,9/DDHP0JU\*+7XF0D8H64`9H>V+C!@V$XP#$;H@QY@Z MX0M1Z*^%>.6`F[#E9)MARA8RO%$0J;`W4C:7,;T0)'(/9P:NSK]FR=C8$]1- MX0OF7(a)ES6*M3UI.F[!)6+D4L*+M&<R/VRO]3M-X1F9,CN,DLL[L50%9'E;J_ M$>O.M!ZHAIOP*N"7YRJ5-'R@S]&2C4('#G*T>%IV.6=_Y_!--XS>H!ASK!6A MFZ1<R8.#O`SABEX[E:H)PW!SF&`O2/%!1QQ16Y*D0RI!86HMT\`*\!_TCY+7 MT/66(<!HQED:$RKFS^S2/Y]L>-2.NX1\Z(/F)+G2W]T#``&._0.";%?>[D2' M&23`8N1#LR1?KK7!G0\G'$$#SY3^Z!+^;7Q.7I*B_C+\9E70LN5S\*:6<ZM M.3Z+[Z($:(0ZBC#+9B%I>L(,/"L,>?;0I3;J_[*.7(*EMUM4Q[5VT.[H7[K> MU#D>#-Y?#`E<7DFUP)97MRM;M*1ZJ/"D1D\-EIW6U7HM5=D_['U@O,:A2I<O M?S8[E%J;5Z<A7FC;H8_?NAB>*=@[4#6QW+EZWZ?A`SSI>-CCJ9YN^&9$37<) MUDDI"H#FKU.C-*,5PGVZ@N$1&VAE=LPUZ3W!4X[%('.\G3R+CGL%FY@!=X$C M_C:?BH$5AYXB#EY/#X_UBOZ*Z_3K._B9R,B6-Q5=D%Q;+1Z1@4`5*3@P1,_/ MQ80W**U5$7!DF]'5_'V"*KWQ0FYE)(a)0SU6?-6TT%E4(2E)C`F5R_.3['T8$ MU59TT<;^Z][B?T;OGCX*M,*,Y'>DH'\X#U;*D+07;(.N:G11UA*PA'6&^)SV MH3VQ@.Q=-O=#I/A(:T?+PCMSC]F=(!RKT)2(%IA*#9I*5,\=C@]MA7T^'_7/ M^\/1\&-_$,IZ^_9ETEJFE/%CA*'C=W([DO^=E^SI4;0`(ZY>OQ7(52=G;^5+ M!>I-]W<@M1>5^HM)AK!#SG?FQJC^XL6^O_L64)"*@AZ5,E*;*%&I%Q3FTH3H MAMIOK*AY;?VK2.-QMD1\T4KK3:\AS8G_,AJUS:)@,FHM&;7C&[[`NKSG`LU: ML?64VZAW*3W=73R9H/Y--;"G"C@8C6B-P8P*%UM]_T>RF!$D7\70B1`"!+( M(_@DCQ4)`86Y@A'=WNMV"!A9BS]L]3I^XAB@^$(TWU/`?%MB^0(H7YC%$\$ ?\MD4LMO`^+9#\175!'@ZAF\K")_:^3_)^'>RP88````` ` end

1 0

Bugs with integer() in packed records
by Frank Heckenbach 21 Jul '97

21 Jul '97

I found some bugs with the new integer() types in packed records. The following program writes 5: program x; var x:packed record x:cardinal(64); end; begin writeln(sizeof(x)) end. The next one says "constant out of range": program x; var x:packed record x:cardinal(64); end; begin x.x:=0 end. (The errors do not seem to be related to my very expressive choice of identifiers... ;-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: It's back! (prior parameter's size)
by Peter Gerwinski 20 Jul '97

20 Jul '97

According to Bill Currie: > C:\source\mpt1352\port>gpc -c -O2 foo.pas > foo.pas: In function `Dectobin': > foo.pas:6: prior parameter's size depends on `Binary' The patch below should fix this bug. (And others.:-) Please check. > However, if I uncomment out BinToDec, gpc aborts in fix_lexical_addr, > stack trace attached. This error vanished, too. I was sure they were independent! Okay, never mind ... ;-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125] 8< ---- gpc-970714-970719.diff.gz.uu ---------------------------------------- begin 644 gpc-970714-970719.diff.gz M'XL(`'E5T3,"`^U;ZW/:2!+_;-7]$5W>W(:7"&`<#+D\"":)]QSLPB39K;TM M118#S%I(6CV,V=W\[]?=,P*!P7%R=57^`)48:1X]/3W3OW[,T)G8WEA$,/)# M&`<.C$)_2(a)]FLU%I5.MEP^CH%M*#D73Q8>XGX-@>A,+QO2@.$R>&F8PG\%I& MOE<"$=OCJ`13^TI(;^27#-L;PD#\#!/[6L"E$![X4QG'8E@&N/"G`OP1Q!,1 M"3V`'0I(@J&-+>#W)(KA<FY<)M(=2F],#<'QIP&V#+'_+YH9U9YK0X%=UD@B M!7$CG"16)&1$-*;(F&$`,*LP:+^]`&(8AM<2S!&\QU+J79:>8>#LB?90XJQC M/YS3`&_/.Q#Y2>@(G&X0^M=RB!Q3,T]@661CL]CWW<C(K<N$Y4%RB<6-K.&` M>9ZU1'G:KHN2,8R!#W80N',]CZ$<C9#"V$>2:ZPLEXM))I%(I;28(01V[$S` M#*J&,1*")2EC;C;R7=>?40$/`38M=9#$96,P$;3*GCT5:R,B"S@H,FE0'S!# M,#\<@-D#\P8*95]]N?Y8O[M#>DCE2<^X<T9R7'9L9Y)]Q]G'240%-*=K$4;2 M]\H.DPGL,!(KSY.TX3@0X4B]\BJJXO++E\NGE&C93F[X\:53II4HZ/)">1)/ M7<4OKS\]Q+X:;E%WTKL8M$]/Z?'-^;^OH[>]#_0<!<*)U#1"GH[FG![#.%J= M"!7HZ:832.?A!(%^K-*W*R^9XXR`N,?EK[+D_&8RZY-L19Q]P;WDF87RKTYI M\AN]^T&,/$2JDCG6C[$]#9A6/-4<":^@:\;BUZI9_TW1<]QDR--[62QR`T?Q MZ3@.\ZW9%]X?B51R&+F^'9<G2LC9EVGBQA+GIP;$AX*:9N(-458D1B6L&UPG M_G8E0D;*L8Q%6=P$:FTN[2OU$,V"C"H\"9XHY#K%;8C%V7?#-,TM3?<N[!A^ M2ERH-J%:;]7KK6H5GYL-HU@LKM/9NT@\;ERK0*76JE1;]:9J_.H5F-72$12K MI8,#>/7*,-_C=J@>:-+-!E2/6H<5@',1BQ#>BA`U,+J2\*^`"LKCM.!5XDD3 ML41XY:%X812)/61M0:9VV*HWOIV,4=PKL`2&PG'+3HM`TW>OA85V8&:'0ROP MI8<4<GFJ&B:.1@![BEL"`1<Q9H@T`($5;`T,B!R1''M3X:7P2[LVQM>(WT.! MP.@/151>&7^$J]H">TC8B2`:^_$\0,1&B/&2Z:4(+7]D10@34]L:RL@)<2-X M-M+,Y4O,@8PV55NV0Q",C1@3`YS$HC86ND<NGV6%QG6N2!C(-JHLT@C'"4TG M(C$0P2!>IS2$=N^8^<"MNU*.EI%`58T4V]F1%'S-6S"R"4];,".DC>VKU,"A M-'!!6&PVC!+/(=55T\5][TI'QF@8'#05(a)`*T49DLQ3.CCNV&PA[.82)"44*# MR\O%G7TDCCM"&XB4,$SE>()65C!%,C[4]MH.I7WI"LL/K;2EEJKE^98<MB"P M>MU/+<7'2'HRFEBTGY9B17OKEJ/6%O&WT$[.T#*%:&!H^W[V<0:S$+7[<1DZ MQ$H8,2L.*QSS910'B8#J848#4$MKWZT!TIS8T806_5W[XIWUYD.O0XN=3AX^ M6\(;/D8="%S;P57%_<XNR9\B])6<VA&T770NYA#9<EA2WH7OX?I$(KQ6.WDL M8MP?\@]D70Z5LT4R(Y5@&JP6)70FR"@/?>SD^3$.BHWFZ#3$-!-BF4&D_K^" M"!B`<W^-/@D.X0H[8@\LZ_3!!KQJM&K?`32W./XN,HKC+%XE7I3P7APE)"/4 M-7*]4'[3P!4,039N&]1GTBW:]4@!()[YJ!6V7@+2@8B<FZ4BD)>$7F7+S.T\ MFYUG\V`]&]IPIHN@B"NMG9)LT6W_)EN[[N(<M.I'ZR[.:ON,EU-%P&E5&DLO MY^"HU(`B_T4W!_Y!NOH#?-3;1)GPR,"-[%AZLSQ'KI[6ZD9QK:Q1JQBTAQ9E MM?*1HM:]B4.T@R[&4*3C`3H:](U.1X(M,:BDN`K=BIW*[E3VH:KLTGAI%5L6 MW%;79=U]XI$MK9NM>J55K2Q5]>C@L%%Z"D7^;K*Z`CPIP!L_1/\>[:4?S%// M?7!F#7XY[[)G@MX,JEN@JSB=4(#3=N^M==SMG'(3M)D#\GLB(:81[3CT?B09 M9HDR),^-.QE%[OH*F6FC4R[)F_8IN(@`E69J>QPZ7/Z.P00E(71S^GB^9V:; MX&YPKBB08+**H]<))S1"@H,Y>;/8>HX@,<(BSU&.&$U-#:`[47!P@BZ7]SB& M*\^?D;L0LGL\YXR,^0(^"96YBGW=1SN#&6(XE4BXH[(6\],ZA7[XW2A5:UK. MQ*#RQ'62:H21"PJ=H@X684E'3+@&,Q2=[C-"(2'&RUB+\(EATD.!^C^'0NQ; M1.`9.8>\EOWU8$W+Z`E]T8I:[]LG/>MCNW_2[@T@AW3R2&A#C2:=)]I((11Q M$E(Z*'YFP!?$Y1W8[L#V88,M9196()(*MH$MU=T?;&^U;K8.\-_1$FP;M2IA M+7UIJ$4=5$D0A*=+L2EI`>?]L\$9Y'+4+(^:I]IS[CMMSWB1;5>"M'51(HF[ MDR:W1N`^=Z90M@UV[<MM>96U+CC$^F164B5?GQI#6S9'P\(TJ/23C:AD7_H) MQ<MD!>W0YE@.K=65F,_\<+CS#'=@]<#!:K&OER"3%FT&K+3VOI"UJ7VMTCHX M1-Q:@M;A80D=QJ+Z(M"BG2X=I;E_)+8KXSFKZ=X>Z^DZ**3M"53HD,Z*[7`L M8NX2;>OS@QPAH-)IFF&N]U?N%:4@-4;HO+2FN)'@.A%\H30F][`"^)8^RXSV M-W8,A>L'V_H4OVV6]R.R.LLMLBY^?9K?U%%/<^O*"@^!EU":CDH)LC-D%CEE MQ7*&:O#US45]+%=&\7TZTLZNU0[J:(B+_*V=\CWVL"_1<D2HY6Z:]F?GN?.N MW0<_1/_[1@Q-G<O'`,*FG#6[XNFGH%/\BYQQ65-&5YURUXAU?CBE[L_1K&$C MM`I3^/%'.&]?=-JG'&99Y_WN\<E%IW_R_J37'G2/K8M!_Z3W%G*#?K>K(K$< M>^/YO,J(;Z3*56L?'"B7'>E#[YX#;2)&G[___F[.62ZPMX<D<$]$$S]!DTN9 M[HD=!,)K@>W.['G$"1Z5:U]$;RQ.V/ZY%TN*CV<<$=V'T#99I0+:1N.^(DKY M`98,BN0"85:J`-QV8L3;S.D(1XN+<PE7>.-XH@^9TJW,%PKX2!\C99=[>'>? M2U%\2X=#K"('1YS+JQTTJSJ;M_P@5SFUI)VS8US2:]O%N/$YJ*E8G8N!<5L( MF?:9W4!=N2_I&)?EC=N;-BO`.[;4RIY`RJ@.J*"6FJ1U.;>F&%J[D.M].$5B MV+]$K4I0I6VP]QV=,L,)-Q*KG/^U/A%<T[8Z-U0791+T48E6@K#NRBNZ\0&= M,W37@%S7B(_L7NZ\U9VW^H"]U?3(=.%=I@6;/-6T[CZ'#IG6=,C+K0^A=M"J M55>\U'J3TFOX]RF#E/(R"$0-4]P(a)5!+FD4.#JN;Z"'5TA/N,\F:HC>17C1%- M.=:D0T`.8SFG%XH(/2!T):[)VM#!`[JETA-PTC]7J$/4<!2^W%$CC"Q6JTT- ME4:FP_(HN8?@EX?_&&:./L[$#J&05Z5Y,WW_D1C,PXL74,O#/^%]^V>+*0S: MKT\1&XMW]:UL[Z?B8YVWTQZE=F$HJ9O@O$=2((R08T9.56$'/#O@>;#`@S8Y M<<4"=M+7VZ"3UMPG--[8%K&IB9'QUC-."EFU^/:7Z<!]PI\5!.B^?]T]!J-X MNU#1X+`W6[@@^R]R@$,4[XN=2NY4\L&JI+['IG5)O]U62%UQVP4X;*[KXX:F M:/QKM58EFZ6JUNNDD/J;0WD5/YV*>,.%N%R>[M;1[;:0;SHMKOMHHQBI_FP' MZ8%BG<VARZ,#%;F0;1^<G/5T]&)R=WCT"`.)1P<46"S?-]S/(S+/U%`JA,@T M5^EQ#(`=V[42SP[GEA]`KGU\W+>Z/Y_W2SA`"2H<-+(LZN@'<<Y./ZR&;7<$ M56>O?^IV!BO36YMI/N6,^V8D@I4D!29#1\"+AG^EHN#5H'/>E6N!%)%2N*^N M&2)ZI!*G#^<88S$-4`JH&&',G2!'^4-U=\Z20W30)#HM(>3VZ<!UGV*RDK$U MF%?2),J<+%J)Z-8F6R).]E)F*B7(-%T\YA=K"]F983B*?&_MLIBB8H>NN/"5 MR1S?GRS=R241SF=I\"ZATD79EYV-V-F(!VLC^`IPZK2IE]L60I7?QV';T++9 MJJ.)R%Z\KU5JC(GJH:Z/7^F_NJ7"U\74]4^5!:/$FHOQ$$>%E!#F8%#=WJ5\ MFKPQDX!_'!1.^721:7E"#-6M4Y0718UKB39]\UO]IHJO!:LBNI)!=V$*<#*" MLX_=_J?^R:!+X$BWBDNI67JR3'XNKL03-VL)/2:4S@-7/&6=+]T0P%*$:YA; M3FISA%\88]Y578+%Q>PT4\=@375I,I7BQT4KA";.A&TWI#PJ&Y'SLY/>H*OR M@,;74H?+;OWNFVZ_V^MTM0E6ZUX[I#-W_$936%TSA6RM^MWV\5GO]!?(4<*/ MDXCI[9=EE<X#ZMLOZR0^GIVV!R>GW0TDEE5K)+*I8KZDPS&Y_K$::F&)-YVZ MA13A\KL+UV2Y":*5?'.!=L,^4M@GI,#MY\#G"Q[T,>^6\FKK)]E76I;%6I$P M*VFR?UW4"X>$SUOX;M+MY5@5T49O(ETW2$66Z?/%R*13F;<[4_"==]WW[6U> MBQHGK[9#K7'8Y'QVX^G12CX;5^!X^9L'>R4WLB%?KG5V*?EVK+29^Y5@)O@7 MB*A!9K8G76]+(O5#NPC\F;?\-4RYG"&W.-?8JH++$XNM3;1+J.6I[_5=Q+ZZ MRH9S0J3VPYB3S_H$(7-7(DIO_;$<1G2W307&2H[-1H/EV#QZFKK;R$J"S@\= M.FD/B![54<;RPR==S\'U_:LDL/AWA&JU/K9//^!RN=*[XD/43)<M,]3DB_=K MJ<6Q]V4ADB\J<]BH\U3JC<.GJT<<!<C)LBCS:G[&7?H81;6R,Z+$F2Q+\MG] M</[_6GFE>])3OZ^RZ,Y?+@6,_9Z8[>>_OC6^3D.?:V2TXX-GHG,;2[2)?ZY< 6<T3AT$]9V*"AD%;F\E^,>WRW2CP````` ` end

1 0

Re: It's back! (prior parameter's size)
by Peter Gerwinski 18 Jul '97

18 Jul '97

According to Bill Currie: > > C:\source\mpt1352\port>gpc -c -O2 foo.pas > foo.pas: In function `Dectobin': > foo.pas:6: prior parameter's size depends on `Binary' GNAAAAA! :-( > However, if I uncomment out BinToDec, gpc aborts in fix_lexical_addr, > stack trace attached. I can reproduce both bugs, and they seem to be independent. (The latter one vanishes when I comment out "#define HASH_EMBED" in `module.c', the first one doesn't.) We will see ... Thanks for the very helpful bug report, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

It's back! (prior parameter's size)
by Bill Currie 17 Jul '97

17 Jul '97

Using the attached code, gpc-970714 (with #define HASH_EMBED commented out in module.c), I get: C:\source\mpt1352\port>gpc -c -O2 foo.pas foo.pas: In function `Dectobin': foo.pas:6: prior parameter's size depends on `Binary' foo.pas:22: warning: return value of function not assigned However, if I uncomment out BinToDec, gpc aborts in fix_lexical_addr, stack trace attached. Bill -- Leave others their otherness. -------stack trace for abort (BinToDec uncommented) ----- _abort _fix_lexical_addr, line 4391 in file function.c _expand_expr, line 4292 in file expr.c _expand_expr, line 5235 in file expr.c _expand_expr, line 4659 in file expr.c _expand_expr, line 4886 in file expr.c _emit_library_call_value+1628 _expand_call+4891 _expand_expr, line 5189 in file expr.c _expand_expr_stmt+253 _rts_read, line 3409 in file util.c _build_rts_call, line 5232 in file util.c _yyparse, line 4574 in file parse.c _compile_file, line 2232 in file toplev.c _main, line 3938 in file toplev.c ___crt1_startup+290 start+465 unit TrunkUti; interface type wrkstring=string[255]; function BinToDec(Binary: string) : LongInt; function DecToBin(DecInput: string) : wrkstring; implementation function BinToDec(Binary: string) : LongInt; begin BinToDec:=0; end; function DecToBin(DecInput: string) : wrkstring; var DecNum : word; begin ReadStr(DecInput,DecNum); end; end.

1 1

Re: GPC Problem
by Peter Gerwinski 15 Jul '97

15 Jul '97

According to Phil Robertson: > > [Bug report: overkeen type-checking in gpc-970624 ...] > > Any ideas or fixes? The new beta, gpc-970714, just compiled your program without complaining. However thanks for the report and the example program; I added it to my test suite in order to ensure that this won't break again in the future. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

New GPC beta: gpc-970714
by Peter Gerwinski 15 Jul '97

15 Jul '97

Hello everybody! A new beta version of GNU Pascal is being uploaded to agnes: gpc-970714. This is merely a bug fixing release, but ... Faster GPI ========== Using a hashing algorithm instead of a linear search, the loading and retrieving of GPI files works much faster now, especially for Units (or Modules) with large Interface parts. The GNU Pascal development team welcomes a new member, Alexey Volokhov, who implemented this. Thanks, Alexey! Bug fixes and new compatibility features ======================================== Standard Pascal: * Subranges of enumerated types are now compatible with their host type. * GPC now performs compile-time range-checking when a constant value is assigned to something of a subrange type. UCSD (and Borland) Pascal: * For Units, `.gpm' files are no longer produced, only `.gpi' files are. (For Extended Pascal Modules, `.gpm' *and* `.gpi' files are produced.) * The `Concat' function is implemented now. Borland Pascal: * The `near' and `far' directives are now "implemented" (i.e. accepted and ignored) in GPC. Outside `--borland-pascal' mode, a warning is given. Extended Pascal: * When assigning a constant value to a String, GPC now checks whether it fits in the String's capacity. * Pointers to already discriminated schemata work now. * Schemata containing forward-referencing pointers work now. GNU extensions: * `Integer ( 8 )' types are more stable now, survive transport through a GPI file, and can be `writeln'ed up to a width of that of an `Integer', usually 32. * A new function `BitSizeOf' now returns the number of bits in some variable, including fields of a packed record. Miscellaneous: * Directives are now passed correctly from `specs' to the `gpc-cpp' preprocessor. * Casts between different Real types are now treated as conversions again. (This was broken in gpc-970624.) * Strings of unknown size in functions which are exported by a Unit work now. (This was the "prior parameter's size depends on `Foo'" bug.) * Indirect function calls are more stable now. A strange bug which showed up only occasionally and made GPC sometimes call a function when a function pointer was dereferenced and sometimes not, should have vanished now. (Please check!) Where to get it =============== The source is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/, files gpc-970714.tar.gz and gpc-970714.zip, together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. In order to prepare for the release of gpc-2.1, binaries are moved to a subdirectory `binary' of `beta', and some other things are being set up, so don't be confused if some files aren't located any more where they were on the day before. Acknowledgement =============== I thank Stephen Lindholm, Frank Heckenbach, Abimbola A. Olowofoyeku, Sven Hilscher, Bernhard Tschirren, and Bill Currie for finding the bugs. Please go on finding all bugs in gpc-970714! I may have overlooked some you already reported. (If so, please remind me by e-mail.;-) Once GPC is clean, we can release version 2.1 - and face neat new features (e.g. qualified import and identifiers, classes, interfaces, procedure overloading, ...) for 2.2! :) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GPC Problem
by Phil Robertson 15 Jul '97

15 Jul '97

In your latest "Beta Version (2.7.2.1)", I've run across the following problem: Command: gpc test.pas test.pas: In function `program_Test': test.pas:13: invalid operands to binary = test.pas:13: condition must be of Boolean type PROGRAM Test; TYPE Colors = (Yellow, Orange, Red, Purple, Green); VAR ThisColor : Colors; BEGIN ThisColor := Purple; IF ThisColor >= Yellow THEN BEGIN WRITELN ('>= Yellow'); IF ThisColor = Purple THEN (* THIS IS LINE 13 *) WRITELN ('Purple'); END; END. Any ideas or fixes? Phil ------------------------------------------------------------------------- Philip A. Robertson <phil_robertson(a)gilbarco.com> Gilbarco Inc. F-78 Phone (910) 547-5164 7300 W. Friendly Ave Fax (910) 292-8871 Greensboro, NC 27410 -------------------------------------------------------------------------

1 0

ARGH!! Segfalts in gpc-970714
by Bill Currie 15 Jul '97

15 Jul '97

Ok, this could very easily be something I've done (I had to make a slight chage to gpi-hash.c to get gpc to link for djgpp (patch attached)) but I get segmentation/page faults for the attached code whenever ANY ONE of the commented out sections of code are uncommented. (Yes, it's the same file as before, just trimmed down for the segfaults) Oh, and I had to rename rts-conf.h to rts-config.h and rts-vers.c to rts-version.c to build libgpc.a. I'll try rebuilding gpc/gcc from scratch to see if that helps. Ug, this is frustrating. Bill -- Leave others their otherness. *** gpi-hash.c.~ Mon Jul 7 21:44:56 1997 --- gpi-hash.c Tue Jul 15 15:44:22 1997 *************** *** 49,55 **** #endif ! extern unsigned long _end; /* integer type for void * representative */ #define IRP_TYPE long --- 49,59 ---- #endif ! extern unsigned long _end ! #ifdef __DJGPP__ ! __asm__("end") ! #endif ! ; /* integer type for void * representative */ #define IRP_TYPE long unit foo; interface type wrkstring=string[255]; function DecToBin( DecInput : string ) : wrkstring; implementation function DecToBin{( DecInput : string ) : wrkstring}; { converts a decimal string[ up to 256 ] into binary string } var TempStr : wrkstring; DecNum, Mask : word; Pos : byte; Err : integer; begin (* TempStr := '';*) mask := $8000; (* ReadStr(DecInput,DecNum);*) for Pos := 1 to 16 do begin (*if (mask and DecNum) > 0 then*) mask := mask; (* if (mask and DecNum) > 0 then TempStr := TempStr + '1' else TempStr := TempStr + '0'; mask := mask div 2;*) end; (* while (TempStr[1] = '0') and (length(TempStr) > 1) do { returns at least 0} delete(TempStr,1,1);*) DecToBin := TempStr; end; end.

1 0

970714 beta corrupted
by Bill Currie 15 Jul '97

15 Jul '97

The gpc-970714.tar.gz seems to be corrupted. gzip, djtar, and funzip all report (for funzip) `funzip error: invalid compressed data--format violated' and my editor (gzip aware) starts showing a forein (sp?) language ;) as the data falls apart. Tried dlding twice (netscape, maybey I should try ftp?) The .zip file is fine (except it has short names and all caps :(- ) I'll cope, but I thought I should report this problem. Bill -- Leave others their otherness.

1 1

Re: prior parameter's size depends on `Decinput'
by Peter Gerwinski 14 Jul '97

14 Jul '97

Hi, everybody! > trunkuti.pas: In function `Dectobin': > trunkuti.pas:332: prior parameter's size depends on `Decinput' > make.exe: *** [trunkuti.o] Error 1 I just fixed it. The problem is that the size of the `DecInput' parameter depends on its own actual value (the `Capacity' field of the string). Normally, GPC can handle this, but in this case, the second occurrence of > function DecToBin( DecInput : string ) : wrkstring; affected the size of the string type in the *first* occurrence. When GPC recycled this first occurrence to define the function, throwing away the second one, the size of the string went to Nirvana. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: prior parameter's size depends on `Decinput'
by Frank Heckenbach 14 Jul '97

14 Jul '97

Bill Currie wrote: > I've managed to reproduce the error in a smaller file. If I comment > out the parameters (or the body of the function) in the implementation > section, the error disapears. In the real file, the ReadStr causes an > abort when the implementation paramteters are commented out (interface > decl same as always). I cut down the program a bit more to the following: unit foo; interface procedure x(y:string); implementation procedure x(y:string); begin read(y) end; end. Oddly, the bug disappears when deleting "(y:string)" in the 2nd declaration. BTW: Bill, the ReadStr is not completely the same as BP's Val. Especially, the Err parameter is not handled like in BP, but read in as a second value. --

2 1

Re: Revised Cygwin32 licensing terms
by Frank Heckenbach 13 Jul '97

13 Jul '97

Jan-Jaap van der Heijden wrote: > > The new licensing terms for Cygwin32 permits anyone to make use of Cygwin32 > > without adhering to the GPL, and without being required to make their > > sources available, provided that in so doing they are not attempting to > > directly compete with Cygnus. Doesn't this contradict the GPL? Or does it refer only to "add-ons" that are not GPLed? --

2 1

Re: RTS runtime error checks.
by Frank Heckenbach 11 Jul '97

11 Jul '97

Phil Nelson wrote: > >Would it be a violation of the standards if we were to have two RTS > >libraries (libgpc.a and libgpc_g.a), where libgpc_g.a is linked if the > >'-g' compiler switch is used, and libgpc.a (no checks) otherwise? > > I would prefer to see the checks being standard and adding a flag to > get better performance. For example, if any -O flag is used, then > use the library without the checks. I'd even prefer yet another switch. Sometimes one wants optimization with checking on, and sometimes one even wants to distribute code (i.e. without -g) with checks, namely when the code is not time-critical, but it's important that it's correct (suid root :-)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Procedural Types
by Frank Heckenbach 11 Jul '97

11 Jul '97

Peter Gerwinski wrote: > Ah - now I have it! :-) With high probability that's another shape > of a known bug: You cannot assign procedures defined in a *program* > to procedural variables (or procedural pointers, like in your example). > :-( > > [...] > > These procedures are treated as local subprocedures of the main > program which is a procedure by itself. This is the source of > a lot of trouble, also in other contexts, What's the difference? The stack frame? If so, could it be possible to create a stub for each such procedure that sets up the correct stack frame and calls the "local" global procedure? > but it is necessary to > make some nonlocal `goto's work which are required by Extended > Pascal. (No, I don't use `goto', and I don't know more about > this, sorry. If I had a test program for these nonlocal `goto's, > I could try to make the other stuff work *without* breaking `goto'; > right now I don't dare to touch this. ;-) Perhaps something like the following (just guessing): program argh; label l; procedure p; begin writeln(1); goto l; writeln(2) end; begin writeln(3); p; writeln(4); l:writeln(5) end. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

prior parameter's size depends on `Decinput'
by Peter Gerwinski 11 Jul '97

11 Jul '97

According to Bill Currie: > > function DecToBin( DecInput : string ) : wrkstring; > [...] > trunkuti.pas: In function `Dectobin': > trunkuti.pas:332: prior parameter's size depends on `Decinput' > make.exe: *** [trunkuti.o] Error 1 Sorry, but I cannot reproduce the bug here. Please try to isolate the bug in a short, useless test program you can post here. Thanks for your cooperation, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 3

Re: Revised Cygwin32 licensing terms
by Jan-Jaap van der Heijden 11 Jul '97

11 Jul '97

On Tue, 8 Jul 1997, Gordon Irlam wrote: > > The new licensing terms for Cygwin32 permits anyone to make use of Cygwin32 > without adhering to the GPL, and without being required to make their > sources available, provided that in so doing they are not attempting to > directly compete with Cygnus. The reason we decided it was necessary to > prevent the use of Cygwin32 by companies that are competing directly with > Cygnus is explained below. > > Cygnus specializes in the provision of development tools for embedded > systems. Cygnus is responsible for perhaps 80% of all on going GCC > development, and 95% of all GDB development. We commercialize our > development efforts through our GNUPro compiler tool chain. Other people and > organizations contribute to, and benefits from our work. > Translating into readable English, I read here: "You are not allowed to create competing development tools based on cygwin32" How does this affect other GNU compilers, like GNU Pascal and GNU Fortran? I created and maintain the (cygwin32 based) win32 port of GNU Pascal. We will surely try to convert the world to Pascal ;-) Will it violate the new license terms to use cygwin32? J.J. van der Heijden --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

RTS runtime error checks.
by Jan-Jaap van der Heijden 11 Jul '97

11 Jul '97

Hello, The GPC runtime library (RTS) does quite a bit of checking at runtime. The ISO standards dictate this. However, these checks slow down GPC compiled programs. Would it be a violation of the standards if we were to have two RTS libraries (libgpc.a and libgpc_g.a), where libgpc_g.a is linked if the '-g' compiler switch is used, and libgpc.a (no checks) otherwise? This would combine the best of both worlds: checks are enabled when you debug your code, while production code has optimum speed. Let me know your opinions, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

3 2

prior parameter's size depends on `Decinput'
by Bill Currie 10 Jul '97

10 Jul '97

Ok, what the heck does this mean!!!??? (gpc-970624) trunkuti.pas: In function `Dectobin': trunkuti.pas:332: prior parameter's size depends on `Decinput' make.exe: *** [trunkuti.o] Error 1 This is the offending line (I don't think I can send the whole file for as I think it's confidential) function DecToBin( DecInput : string ) : wrkstring; Ancient borland legacy code I'm trying to port to gpc (comiled with 2.0). BTW thanks for the great work, most of the problems I had using 2.0 have gone!! Bill -- Leave others their otherness.

1 0

Re: Some new features
by Frank Heckenbach 10 Jul '97

10 Jul '97

Pierre Phaneuf wrote: > Frank: you could just do an include file with all the path options, and > you just change this file... That's how I do almost every thing (compiler > options and defines in a separate "config file" which I include > everywhere). Well, I could, but I think that's a bad idea! Things like paths do not belong into the source since they're system dependent. (I know that in C it's common to have to edit some source files or makefiles before compiling, but that's one of the many things I dislike about C.) For compiler options that affect the source (most of them), it's ok for me to put them into the source, but path options I'd like to see in system dependent things like scripts, aliases and/or environment variables... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: bugs, incompatibity, function attributes
by A.A. Olowofoyeku 09 Jul '97

09 Jul '97

Pierre Phaneuf wrote: > On Wed, 2 Jul 1997, The African Chief wrote: > > > 6. All classes to have the same ultimate ancestor object. > > This is done manually (by having all your objects inherit from TObject > somewhere). In Delphi, it doesn't need to be done manually. If you write; Type FooObj = Class end; It is *exactly* the same as if you had written; Type FooObj = Class(TObject) end; > Or maybe you mean we could do this: > > var > C: class; I am not sure you can do that, or that you should be able to do it. Warmest regards, The Chief --------- Dr. Abimbola A. Olowofoyeku (The African Chief and The Great Elephant) Keele University, England (Email: laa12(a)cc.keele.ac.uk) Author of: Chief's Installer Pro v3.60 for Win16 and Win32 Homepage: http://ourworld.compuserve.com/homepages/African_Chief/

1 0

Re: Delphi classes
by Frank Heckenbach 09 Jul '97

09 Jul '97

Peter Gerwinski wrote: > Well, `CommandEnabled' is > not a virtual method, and the body of `CommandEnabled' does never refer > to any data fields of the object. (So why it's a method then???) Or rather, why are the relevant variables global (argh!), and not fields of the correct objects? > How did Borland solve this problem in BP7? > > > const > T: PView = nil; > > ... > P^.Disabled := not T^.CommandEnabled(Command); > ... If I were them, I'd have "improved" the compiler to accept "P^.Disabled := not nil^.CommandEnabled(Command);" in order to save the variable... ;-) > It's great, isn't it? Now you see why I do not want to trust Delphi and > VCL and prefer to hack GPC instead ... : Gee, I guess that means Delphi was created by a staff of idiots. : -- : - Steve Teixeira : steixeira(a)corp.borland.com Yesterday in c.l.p.b.! NO JOKE! :-) (Subject: Re: Programming more, sleeping less. How do you stay awake?) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Delphi classes (Was: bugs, incompatibity, function attributes)
by Frank Heckenbach 09 Jul '97

09 Jul '97

The African Chief wrote: > >Sounds reasonable. So should we just change "asmname" to "name"? > >Or keep both? > > I think we should keep both. "Asmname" is intuitive, but > "name" is good for Delphi compatibility. Besides, removing "asmname" would break some existing programs (including a published one of mine)... > 2. [a] a Class instance becomes a pointer to the class; > (or is it that the Class itself is a pointer to an object/class?); I think the latter would be a more consistent interpretation (at least for us, even if Delphi does it otherwise). So "class" = "pointer to object", approximately... > e.g., "Var Foo : MyFoo" > = "Var Foo : ^MyFoo" in the current OOP model Saves declaring those "PFoo" types, OTOH makes it impossible to declare global or local objects variables (without the overhead of allocating memory). If we have objects and classes, the programmer can choose what (s)he prefers. > [b] the constructor does the heap allocation stuff, > e.g., "Foo := MyFoo.Create" > *allocates memory for Foo "(New, Foo)" > *calls Foo^.Create (constructor) So it's the same as "Foo := New(MyFoo, Create)" in BP? Why not! Shorter to type, perhaps easier to read (once one gets used to not looking for "New"). What about destructors? Does Delphi still use "Dispose", or has it another syntax too, or does it dispose of objects automatically. (C++, BTW, does the latter. It destroys e.g. local objects at the end of the function automatically. This is possible because in C++ every class has exactly one destructor. I guess they set the pointer to nil automatically at the beginning (and set it back to nil if the destructor is called manually), so they can easily find all local objects that "exist" and destroy them.) > *Foo now points to whatever > "Foo.Create" - should generate an exception > because Foo needs to be assigned to the > constructor AFAICS, calling a second constructor does not even have to be forbidden -- at least in gpc. Constructors can be called like normal methods from an initialized object, though this is certainly uncommon practice. > [c] deference it automatically; > e.g., "Foo.Bar := 12" (instead of "Foo^.Bar := 12") This reminds me of C++'s "reference types" (not only for objects, but for any types). I.e., a pointer internally, but dereferenced automatically when necessary. I think they could be quite useful sometimes, anyway, and if they'll be implemented (syntax?), we'd have "class" = "reference to object"... > 3. Allow virtual constructors (or at least, don't reject the > "virtual" directive in a "Class" constructor's definition) AFAIK, this is planned, anyway. > 4. Virtual methods to be overridden must be overriden > with the "override" directive; the "virtual" directive merely > creates a new method (or at least, don't reject the > "override" directive in a "Class" definition) Does this mean you have to use "virtual" for *every* method in Delphi, or what is meant by "create a new method"? > 5. Allow "Published" methods (or at least, don't reject the > "published" directive in a "Class" definition). Is this the same as "public" in C++ (= visible to everyone)? I, personally, would prefer "public", "protected" (=visible only to descendants) and "private" (=visible only to the type/class itself -- BTW, BP does it a bit differently, and extend the visibility of private methods to the whole unit it's declared in. I don't see any reason or advantage of this). So, perhaps we could allow all those keywords, including "published", in any order, also possibly repeated (unlike BP). > 6. All classes to have the same ultimate ancestor object. The same discussion as with objects recently... ;-) Is this really necessary (if so, for what?), or is it sufficient if all classes in a given library use the same ancestor by convention? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

4 4

Re: Some new features
by Peter Gerwinski 09 Jul '97

09 Jul '97

According to Frank Heckenbach: > According to myself (Peter Gerwinski): > > What about extending (*$executable-file-name="foo"*) to accept > > a directory? Or else (*$executable-path-name="/foo"*) and > > (*$object-path-name="/bar"*)? > > I don't agree. The *name* of the executable can be considered part of the > program. The *path* where it will be stored will be system dependent, so the > path, IMHO, does not belong into the source, but on the commandline (or into > a (system or user or project specific) config file, of course). A directive (*$Foo="Bar"*) is always equivalent to a command-line option `--foo="Bar"'. I was just thinking about reasonable names for these options. > > > - Passing the actual size for untyped (resp. void) parameters, so it can > > > be access with sizeof. > > var x:void -> like C > var/const x -> like BP BP does *not* pass the size of untyped parameters to the procedure. Changing GPC would break compatibility to both C and BP; the latter being unimportant because nobody will consider it a feature *not* to have the size of a variable. OTOH, many C libraries rely on a `void*' parameter *not* being followed by a `size' parameter. Instead of changing the meaning of `Var foo', we are IMHO better off when introducing a *safe* mechanism to pass variables of varying type (and number). Procedure overloading will be "half the rent". ;-) > For procedural variables, BP uses "@ProcVar" to cast them into a pointer(!!!). > gpc does not understand this, but the (more logical, IMHO) "Pointer(ProcVar)". > Unfortunately, BP doesn't accept the latter, so AFAICS there's yet no way that > works on both. :-( Since we can't change BP, we should make gpc recognize > "@ProcVar", perhaps also only in "--borland-pascal". Okay; I have put it on my list. Plan: Recognize it, but warn. With `--borland-pascal' (same as (*$borland-pascal*) :-), don't warn. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: bugs, incompatibity, function attributes
by The African Chief 09 Jul '97

09 Jul '97

On Wed, 2 Jul 1997 00:56:42 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: [...] >> 3. Delphi's "name" directive; >> This is exactly the same as GPC's "asmname" directive. We can >> implement this simply by also allowing just the use of "name" in any place >> where "asmname" would be allowed (i.e., we can dispense with the "asm" >> part of the "asmname" directive). That way, we get the best of both worlds! > >Sounds reasonable. So should we just change "asmname" to "name"? >Or keep both? I think we should keep both. "Asmname" is intuitive, but "name" is good for Delphi compatibility. / begin off-point On the question of Delphi compatibility, any chance of supporting Delphi's "Class" construct? I know that there are enough differences between "Class" and "Object" to make supporting "Class" a non-trivial exercise, but we could make a start. As a starting point, I suggest this (if it won't be too difficult, and if it won't distract you from other more pressing things); 1. Allow this to compile; Type MyFoo = Class { blah, blah } end; 2. [a] a Class instance becomes a pointer to the class; (or is it that the Class itself is a pointer to an object/class?); e.g., "Var Foo : MyFoo" = "Var Foo : ^MyFoo" in the current OOP model [b] the constructor does the heap allocation stuff, e.g., "Foo := MyFoo.Create" *allocates memory for Foo "(New, Foo)" *calls Foo^.Create (constructor) *Foo now points to whatever "Foo.Create" - should generate an exception because Foo needs to be assigned to the constructor [c] deference it automatically; e.g., "Foo.Bar := 12" (instead of "Foo^.Bar := 12") 3. Allow virtual constructors (or at least, don't reject the "virtual" directive in a "Class" constructor's definition) 4. Virtual methods to be overridden must be overriden with the "override" directive; the "virtual" directive merely creates a new method (or at least, don't reject the "override" directive in a "Class" definition) 5. Allow "Published" methods (or at least, don't reject the "published" directive in a "Class" definition). 6. All classes to have the same ultimate ancestor object. Of all these, numbers 1 and 2 are the most pressing (for me at least), and will go a long way to improving GPC's Delphi compatibility. The others are not that urgent and can come much later (perhaps they can be added to the "to do" list). Does this sound like too much of a distraction at present? / end off-point Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

2 1

Re: SH**! (Sorry) - Procedural Types
by Bernhard Tschirren 08 Jul '97

08 Jul '97

> >Okay, I succeeded to reproduce the bug under plain DOS. It does not show up >in an OS/2 DOS box nor in the Linux DOSemu. > >I am after it. Please relax. (-: YAY!! I just realised what is (probably) causing the problem. GPC supports two versions of procedural types - Borland and GPC. Unfortunately, GPC does not know which version it is compiling. For example: Var Proc = ^Procedure; [...Code...] Begin Proc = @SomeProcedure; [...More Code...] Proc^; Sometimes GPC, for some reason, parses this as a BP End; procedural type, so the ^ is not supposed to be there. It would compile OK if the ^ were removed! HOWEVER, the next time GPC might decide to parse it as a GPC version, so the ^ must be present. And that is all that there is to it! Simple! :-) Now, fixing it is a different story... Cya L8r ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

__cstring__ question & comment
by Peter Gerwinski 08 Jul '97

08 Jul '97

According to Ken Linder: > > the compiler will generate code to convert the string schema type to a real > CString with '/0' termination and everything... Am I right or was I seeing > things? (it is rather late here in Las Vegas, NV, USA) BTW, I am using ver > 2.0 GPC on Linux and when I tried it, got an 'incompatible type' error. No > suprise there :^} `CString' handling has been significantly improved since the days of gpc-2.0. Please take part in beta-testing gpc-970624, available at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/. > Why do we have __cstring__ anyway? It seems as though we could get away > with just declaring a type like: CString = ^Char Unless it does something > else I don't see yet |-) It's needed for compatibility with C, Borland Pascal, and Delphi. (For the latter cases it can also be called `PChar' now.) And, BTW, in gpc-970624 you can drop the underscores. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Delphi definitions and such...
by Peter Gerwinski 08 Jul '97

08 Jul '97

According to Ken Linder: > > I just thought we ought to get some definitions out of the way regarding Delphi. > > 1) Delphi > Development tool IDE) and compiler/linker/interactive debugger. > Strictly NOT platform independant. Only implemented OS (if you could call > it that :^) is the group of Windows OSs. (Although I did read that there is > an IBM AS400 version of Delphi (hmmm... interesting!)) Okay with me, but just to keep the confusion up, I must correct you below: > 2) Object Pascal > A superset of Borland Pascal. The language that is compiled by the > Delphi compiler. Through the utilization of the VCL, the Delphi IDE is > partialy built on Delphi. There is yet another Object Pascal which is an extension of ISO-10206 Extended Pascal. When saying "Object Pascal", I usually refer to this one, while I call the other thing "Delphi" - thus contradicting your definition #1. But I could live with speaking about the "Delphi language" here, reserving "Delphi" for the development environment. > This version of pascal is not standard but seems > to be an extension of ISO 7185. No, it does not include ISO-7185. It has some common things with ISO-7185, that's all. OTOH, Borland's versions of Pascal are extensions of UCSD-Pascal (with small exceptions). Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Delphi classes
by The African Chief 08 Jul '97

08 Jul '97

On Mon, 7 Jul 1997 17:55:36 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: [...] >This is the point where I must ask: What you mean with "Delphi"? > >So far, I have seen four definitions: > > 1. the language definition, > > 2. the compiler (including compiler switches and such), > > 3. the compiler and the VCL, or > > 4. the compiler, the VCL, and development tools (the IDE plus all > the tools for "visual programming"). > >When speaking about Delphi compatibility for GPC I refer to meaning >#1 above. #1 will suffice for me. >#2 is out of range, but one can work around this by using >(*$ifdef*)s for incompatible compiler switches. (* There is only one >thing in GPC preventing us from really doing so: the missing {$ifopt x+}. >That's still planned. *) Most people who want to have a Delphi-com- >patible system mean #4, but could live with #3, too. What I personally >aim is #1, but I am almost sure that once we have #1, somebody else >will create #3, and perhaps even #4. :-) I don't think #3 is of any use without #4 (i.e., why have the VCL without the IDE, the object inspector, and the object repository?). Realistically, if we can achieve #1 (i.e., support Delphi's "Object Pascal" language) then I think the rest will happen as people write their own classes, and maybe even a class library based on Object Pascal. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: SH**! (Sorry) - Procedural Types
by Peter Gerwinski 08 Jul '97

08 Jul '97

According to Bernhard Tschirren: > According to myself (Peter Gerwinski): > >Now we are in trouble: I cannot reproduce this bug, neither on DJGPP, nor > >on Linux. > [...] > Im using the latest beta GPC for DJGPP 2.01. The following tests were > compiled from a DOS shell under Windows 3.11, but they also occur when > running in pure DOS using CWSDPMI r3. [Lots of important information (thanks!) not repeated here ...] Okay, I succeeded to reproduce the bug under plain DOS. It does not show up in an OS/2 DOS box nor in the Linux DOSemu. I am after it. Please relax. (-: Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

__cstring__ question & comment
by Ken Linder 08 Jul '97

08 Jul '97

Morning All... I read somewhere, but can't find it now, where if I declare a proc something like this: procedure testme(aCString : __cstring__); and call it like this: var str1 : string (20); ... str1:='Just a TEST'; testme(str1); the compiler will generate code to convert the string schema type to a real CString with '/0' termination and everything... Am I right or was I seeing things? (it is rather late here in Las Vegas, NV, USA) BTW, I am using ver 2.0 GPC on Linux and when I tried it, got an 'incompatible type' error. No suprise there :^} Why do we have __cstring__ anyway? It seems as though we could get away with just declaring a type like: CString = ^Char Unless it does something else I don't see yet |-) Later... Ken L. kc7rad(a)vegasnet.net klinder(a)hn.com

1 0

Delphi definitions and such...
by Ken Linder 08 Jul '97

08 Jul '97

Hi all, I just thought we ought to get some definitions out of the way regarding Delphi. 1) Delphi Development tool IDE) and compiler/linker/interactive debugger. Strictly NOT platform independant. Only implemented OS (if you could call it that :^) is the group of Windows OSs. (Although I did read that there is an IBM AS400 version of Delphi (hmmm... interesting!)) 2) Object Pascal A superset of Borland Pascal. The language that is compiled by the Delphi compiler. Through the utilization of the VCL, the Delphi IDE is partialy built on Delphi. This version of pascal is not standard but seems to be an extension of ISO 7185. 3) VCL (Visual Component Library) Library that is both linkable into an executable and dynamicaly used by the Delphi IDE. It is written in Object Pascal. If anyone is interested, I could go a bit further and elaborate, but alas, I am behind on my ncurses/GPC programming! Later... Ken L. kc7rad(a)vegasnet.net klinder(a)hn.com

1 0

Re: Delphi classes
by Peter Gerwinski 07 Jul '97

07 Jul '97

According to The African Chief: > > If you don't use "override", then it creates a new method by the > same name, which replaces the original one. The full implications > of this are not clear to me yet, but they have caused me some > grief a few times (things not behaving as you expect). But I think that I have understood it now. :-) While `override' overrides a virtual method, i.e. replaces its entry in the VMT, `virtual' would create a new entry in the VMT, thus making the old method inaccessible - except when using this class through a pointer to a parent class. One example (I hope there aren't too many typos): Type FooClass = class Constructor Create; Procedure Bar; virtual; end (* FooClass *); Foo2Class = class ( FooClass ) Procedure Bar; override; end (* Foo2Class *); Foo3Class = class ( Foo2Class ) Procedure Bar; virtual; end (* Foo3Class *); Foo4Class = class ( Foo3Class ) Procedure Bar; override; end (* Foo4Class *); Var Foo: FooClass; Foo2: Foo2Class; Foo3: Foo3Class; Foo4: Foo4Class; ... Foo4:= Foo4Class.Create; Foo3:= Foo4; Foo2:= Foo4; Foo:= Foo4; Foo4.Bar; (* calls Foo4Class.Bar *) Foo3.Bar; (* calls Foo4Class.Bar which overrides Foo3Class.Bar *) Foo2.Bar; (* calls Foo2Class.Bar *) Foo1.Bar; (* calls Foo2Class.Bar which overrides FooClass.Bar *) That's my guess. If somebody really *knows* it, please tell me! > given this; "Procedure Foo (Bar:TObject)" > > In Delphi, Bar is a pointer (even though it is automatically deferenced). > In BP it is not a pointer (you would have to do "Bar: pObject", and then > do some magic to dereference it automatically, to achieve the same > thing). In BP (and GPC), you have to write "Procedure Foo ( Var Bar: tObject )" to get (almost) exactly the same: `Var' parameters are internally passed through a pointer which is implicitly dereferenced whenever you access the parameter. > >Sounds logical. But when does Delphi create objects by itself? > > When it manages the project, e,g., when you drag objects from > the repository onto your form - which is how most Delphi programs > are meant to be written. Then it's not Delphi (the compiler) who creates and destroys the objects but VCL which has this close interaction with the development tools. > Well, "Free" is written in ASM. So, maybe therein lies the magic. > I don't understand the ASM code, so I can't really comment on this. Well, as long as you know *exactly* what the compiler does, you can write and use `Free' - perhaps even as a virtual method. But I remember well a rather strange bug in one of my programs when I upgraded from TP6 to BP7 without replacing my heavily-modified Turbo Vision with the new version, and I finally discovered the following in `menus.pas' from Turbo Vision: function NewItem(Name, Param: TMenuStr; KeyCode: Word; Command: Word; AHelpCtx: Word; Next: PMenuItem): PMenuItem; var T: PView; P: PMenuItem; begin if (Name <> '') and (Command <> 0) then begin New(P); P^.Next := Next; P^.Name := NewStr(Name); P^.Command := Command; P^.Disabled := not T^.CommandEnabled(Command); P^.KeyCode := KeyCode; P^.HelpCtx := AHelpCtx; P^.Param := NewStr(Param); NewItem := P; end else NewItem := Next; end; Note that "T^.CommandEnabled(Command)" is called with `T' being an *uninitialized* local variable! So it was quite natural that my BP7-compiled protected-mode program barfed. But why did the same program accept it when compiled with TP6? Well, `CommandEnabled' is not a virtual method, and the body of `CommandEnabled' does never refer to any data fields of the object. (So why it's a method then???) Everything which happens with the implicit `Self' parameter then is that it is loaded into the `es:di' register pair ... which doesn't matter in real mode but causes a protection fault in protected mode if the `es' register does not get a valid selector. That's why the BP7 program crashed. So, everybody, don't use uninitialized local variables, especially not pointers! Yes, Borland, you too! How did Borland solve this problem in BP7? const T: PView = nil; ... P^.Disabled := not T^.CommandEnabled(Command); ... It's great, isn't it? Now you see why I do not want to trust Delphi and VCL and prefer to hack GPC instead ... Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

SHIT! (Sorry) - Procedural Types
by Bernhard Tschirren 07 Jul '97

07 Jul '97

>Now we are in trouble: I cannot reproduce this bug, neither on DJGPP, nor >on Linux. AARRRGGHHH! All procedures are defined in a unit! Whats worse, some test programs refuse to compile - but only sometimes!! As I said in the original mail, the problem is not CString or Function related - problems also occur with procedures. Im using the latest beta GPC for DJGPP 2.01. The following tests were compiled from a DOS shell under Windows 3.11, but they also occur when running in pure DOS using CWSDPMI r3. Below is the ACTUAL (no lie) screen shot of what just happened to me! [Including the habitual typing mistake - oops] <-------------- BEGIN SEENSHOT ------------------------> E:\DJGPP\GPC\BUG>q bug02\ gpc bug02.pas -o bug02.exe bug02.pas: In function `program_Bug02': bug02.pas:16: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug02.pas -o bug02.exe bug02.pas: In function `program_Bug02': bug02.pas:15: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug02.pas -o bug02.exe bug02.pas: In function `program_Bug02': bug02.pas:15: incompatible types in assignment bug02.pas:16: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug02.pas -o bug02.exe E:\DJGPP\GPC\BUG>bug02 OK OK 5460 5456 O OK 5460 5456 E:\DJGPP\GPC\BUG> <-------------- END SCREENSHOT ------------------------> What the @%^!? It compiled OK, but I forgot to use --automake! STRANGE! OK, here comes the source: BUG02.PAS: ---------- Program Bug02; Uses Bug02_U; {$X+} Var ProcRec : TProcRec; S1,S2 : CString; Begin ProcRec.Name1 := @NameFunc; ProcRec.Name2 := @NameFunc; S1 := ProcRec.Name1^; { Line 15 } S2 := ProcRec.Name1^; { Line 16 } WriteLn(ProcRec.Name1^); WriteLn(S1); WriteLn(Word(ProcRec.Name1)); { Testing Procedure Address } WriteLn(Word(S1)); { Testing CString Address } WriteLn; WriteLn(ProcRec.Name2^); WriteLn(S2); WriteLn(Word(ProcRec.Name2)); WriteLn(Word(S2)); WriteLn; End. BUG02_U.PAS: ------------ Unit Bug02_U; {$X+} Interface Type TProcRec = Record Name1 : ^Function : CString; Name2 : ^Function : CString; End; Function NameFunc : CString; Implementation Function NameFunc : CString; Begin NameFunc := 'OK'; End; End. <-----------------------------------------------------> This is one of those nightmare bugs because it shows up at random times. Hang on, Ive just had an --IDEA--! Please wait while I compile once more... DAMN - Its not unit related. Compiling the program below gave me the following error messages. NOTE: It compiled OK the first time!?!? <-------------- BEGIN SCREENSHOT ----------------------> E:\DJGPP\GPC\BUG>gpc bug03.pas -o bug03.exe E:\DJGPP\GPC\BUG>gpc bug03.pas -o bug03.exe bug03.pas: In function `program_Bug02': bug03.pas:24: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug03.pas -o bug03.exe bug03.pas: In function `program_Bug02': bug03.pas:24: incompatible types in assignment bug03.pas:25: incompatible types in assignment E:\DJGPP\GPC\BUG>gpc bug03.pas -o bug03.exe bug03.pas: In function `program_Bug02': bug03.pas:24: incompatible types in assignment bug03.pas:25: incompatible types in assignment E:\DJGPP\GPC\BUG>bug03 O OK 1408960 5456 OK OK 1408960 5456 E:\DJGPP\GPC\BUG> <-------------- END SCREENSHOT ------------------------> BUG03.PAS: ---------- Program Bug02; {$X+} Type TProcRec = Record Name1 : ^Function : CString; Name2 : ^Function : CString; End; Function NameFunc : CString; Begin NameFunc := 'OK'; End; Var ProcRec : TProcRec; S1,S2 : CString; Begin ProcRec.Name1 := @NameFunc; ProcRec.Name2 := @NameFunc; S1 := ProcRec.Name1^; { Line 24 } S2 := ProcRec.Name1^; { Line 25 } WriteLn(ProcRec.Name1^); WriteLn(S1); WriteLn(Word(ProcRec.Name1)); WriteLn(Word(S1)); WriteLn; WriteLn(ProcRec.Name2^); WriteLn(S2); WriteLn(Word(ProcRec.Name2)); WriteLn(Word(S2)); WriteLn; End. <---------------------------------------------------------------> I hope I dont cause too much headache with this bug report :~( I know how bad it is hunting down bugs. I had to fix a last minute bug over the weekend - The program was scheduled to be delivered to the client on Monday (Today). Luckily it was a success! Now Ive got a week of holiday - then I go back to UNI! Busy, busy, busy -- And Im only 18!! Whats to come of the future!! AAARRGGHHH! :-) Once again, Good Luck ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Delphi classes
by Peter Gerwinski 07 Jul '97

07 Jul '97

Hello Dave, hello everybody! According to David Fiddes: > According to myself (Peter Gerwinski): > >What Borland did with Delphi was to design the compiler to work > >together with exactly one library (VCL), exactly one set of development > >tools (object inspector etc.) on exactly one platform (Windows). I don't > >like this approach because it contradicts the general applicability of a > >compiler. > > NO WAY! The only odd thing about Delphi is the compiler portion. Sorry, but I don't understand this. I have the impression that we are referring to different things when speaking about "Delphi". Since I think it is important for future GPC development that I understand what Delphi really is, let me please pose some questions - and sorry, if they sound stupid. > The whole > system is designed to be cross platform(unlike C/C++,Pascal,et cetera) from > the ground up. What do you mean with "unlike C/C++, Pascal, etc."? These are language definitions, which do not say anything about the platform the compiler and/or the compiled program have to run on. The only platform- specific think I find in the language definitions is that all of them require some terminal I/O for implementation of the `writeln'/`printf'/etc. procedures /functions. > The only thing preventing it is that Borland is too > skint/not interested in doing it. Here I agree: If Borland wished, they could make Delphi platform-independent. What I meant above is that they decided in a quite early stage to support only the Windows platform, and now it's way too late to adapt VCL to support, say, X11 as well. I would be glad if somebody proved me wrong. > You can replace the VCL if you so wish > the only thing you lose is compatibility with the IDE. This is the point where I must ask: What you mean with "Delphi"? So far, I have seen four definitions: 1. the language definition, 2. the compiler (including compiler switches and such), 3. the compiler and the VCL, or 4. the compiler, the VCL, and development tools (the IDE plus all the tools for "visual programming"). When speaking about Delphi compatibility for GPC I refer to meaning #1 above. #2 is out of range, but one can work around this by using (*$ifdef*)s for incompatible compiler switches. (* There is only one thing in GPC preventing us from really doing so: the missing {$ifopt x+}. That's still planned. *) Most people who want to have a Delphi-com- patible system mean #4, but could live with #3, too. What I personally aim is #1, but I am almost sure that once we have #1, somebody else will create #3, and perhaps even #4. :-) > The Windows VCL > implementation could quite easily(and I mean this) Why do you think this would be easy? I doubt that it is, but (as I already wrote) I would be glad if somebody proved me wrong. > be swapped out and > replaced with an X-Windows-VCL, Mac-VCL, NEXT-VCL, etc,etc,etc. It should > be possible to build(as in compile) a standard(i.e. not using Windows fns > direct) Delphi application on any compatible compiler/processor/OS > combination without touching the source at ALL. You mean the source of the program, not that of VCL. You are probably right. The point where we disagree is the "quite easily" above. As far as I have understood Delphi's internals up to now (which is not much, sorry), you need a lot of compiler magic for a working VCL. (That's what I meant with the compiler being designed to work together with exactly VCL.) For example, when I create a Delphi project (Thanks, Larry!) with one form containing three `CheckBox'es, Delphi considers the following as the source of my program: -- project1.dpr -- program Project1; uses Forms, Unit1 in 'UNIT1.PAS' {Form1}; {$R *.RES} begin Application.CreateForm(TForm1, Form1); Application.Run; end. -- unit1.pas -- unit Unit1; interface uses SysUtils, WinTypes, WinProcs, Messages, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; type TForm1 = class(TForm) CheckBox1: TCheckBox; CheckBox2: TCheckBox; CheckBox3: TCheckBox; private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.DFM} end. >From this example I can learn that Delphi 1. allows to pass class types as arguments of procedures somehow (see the call to `Application.CreateForm'), and 2. allows some magic for the other parts of VCL to locate the data fields `CheckBox[1-3]' in `TForm1'. (* Is this the meaning of the famous `published'? *) While I can accept most general-purpose language extensions (#1 could be such a thing), I don't like compiler functionality specifically designed for one library - which I suspect in #2. Please correct me if I am wrong. > GNU-Delphi is a real > possibility. The only thing you would lose is the pretty IDE which, > naturally, remains the property of Borland...afterall, everyone has a > Windows box to do the initial development on. (* One of the reasons why I started with GPC was because I cannot stand Delphi's IDE ... ;*) Not everyone has one, but everyone who wants to use such a "GNU-Delphi" probably has. How should such a GNU-Delphi look like? > I would be really interested in a command line cross-compiler for Delphi > that would allow me to port my existing Delphi software to the Mac, (The Mac is likely to cause trouble here, because MacOS is not supported by GNU, AFAIK.) > X Windows,etc for nil effort. "Nil effort" isn't realistic - at least the compiler switches will have to be adapted - but let's aim "minimum effort". > I build educational software for a living > which gets sold to the general public/consumer(all PC based) and to > teachers/schools/colleges,etc which for various political reasons use a > wide variety of muck including Macs....I want to sell to these folk...these > folk want to buy from me...but they don't want to have to re-equip with > PCs.... ... which I can understand well ... > and doing serious development on anything other than Delphi is out > of the question as it would quadruple the lead time/number of staff > required to complete a given project. (* For me it's vice-versa: Using Delphi for serious development would quarter the time needed to produce a running program (10%), but would quadruple the time/number of staff required to get it stable (90%). ;*) > fyi, this is why I like GNU-Pascal. I hope - and am doing my best - that you won't be disappointed. > yours (rantingly), :-) Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: GNU Pascal preconfigured
by The African Chief 07 Jul '97

07 Jul '97

On Sat, 5 Jul 1997 16:20:07 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: [...] >What about another subdirectory `/easy/' from the same type as `/djgpp/' >containing all needed `.zip' files plus the installation program and >`README'? Having this, a user only needs to download the contents of >*one* directory. Better still, what about one ZIP file? Put all the relevant .ZIP files inside a single ZIP file, and that is all that the user needs to download. >If I remember right, The African Chief (Hi!:) Hi! >had planned to write something similar for Windows. Then >we could create more directories of this type, e.g. `/easy-dos/' >and `/easy-w32/', and change the text in `README' accordingly. Sounds okay to me. I planned to write an install script to be used with my installer (with a free registration given to the GPC team for the purpose of providing and installation routine for GPC distribution). I am still willing to do this - so (Peter and/or Jan-Jaap) if or when you need this, just drop me a note! Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Delphi classes
by The African Chief 07 Jul '97

07 Jul '97

On Fri, 4 Jul 1997 16:27:32 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >Marius Gedminas wrote: > >> In Delphi you can declare a method 'virtual' or 'dynamic' and when you want to >> override it in an descendant class, you must do it with 'override' directive. > >And what happens if you don't use "override"? If you don't use "override", then it creates a new method by the same name, which replaces the original one. The full implications of this are not clear to me yet, but they have caused me some grief a few times (things not behaving as you expect). >Peter Gerwinski wrote: > >> It's "class" = "reference to object". Fortunately, the GCC front-end >> is able to deal with such things, > >Fine! :-) (Front-end? Or back-end?) > >> so we "only" have to implement the >> syntax into GPC - and take care that it doesn't break other applications >> of reference types such as `Var' parameters and procedural variables. > >Yes. Are value and reference parameters of class type the same, then (in >Delphi)? Or do reference parameters pass a pointer/reference to the >reference, i.e. do they allow destroying and recreating the object? Who knows? > >Are pointers to classes allowed in Delphi, and what do they mean? If you mean this; Type MyFoo = Class end; Type pMyFoo = ^MyFoo; Var Foo : pMyFoo; - then the answer is "yes", this will be accepted in the sense that it will compile. However, when you run the program, I cannot tell you what will happen. I have not ever tried it, neither do I have any desire to do so. In fact, there is no point at all in doing something of that nature. >AFAICG, objects in Delphi are typically things like windows, editors, dialogs >and such "big things". Not at all. There are all sorts of classes, including collections, strings, maths, Zip/UnZip, etc. >> Delphi also supports both Objects and Classes - > >With the differences like I described them? I am not sure I remember how you described them. However the main difference is that Objects in Delphi are the same as the Objects in BP (and GPC). Classes are different, in the ways which have before been explained. > >> so it would be nice if we could as well. > >gpc will certainly not remove objects when classes are implemented. :-) > >> >> [b] the constructor does the heap allocation stuff, >> >> e.g., "Foo := MyFoo.Create" >> >> *allocates memory for Foo "(New, Foo)" >> >> *calls Foo^.Create (constructor) >> > >> >So it's the same as "Foo := New(MyFoo, Create)" in BP? >> >> More or less. > >I'd like to know it exactly. Is there any difference (besides the different >syntax, of course)? given this; "Procedure Foo (Bar:TObject)" In Delphi, Bar is a pointer (even though it is automatically deferenced). In BP it is not a pointer (you would have to do "Bar: pObject", and then do some magic to dereference it automatically, to achieve the same thing). > >> Delphi destroys all objects that it creates itself. However, >> if you manually create an object by calling its constructor, >> you have to destroy it yourself with a call to "Free". > >Sounds logical. But when does Delphi create objects by itself? When it manages the project, e,g., when you drag objects from the repository onto your form - which is how most Delphi programs are meant to be written. >AFAIK, gpc doesn't do this yet, so we'd have to adopt this as well!? We would need a Delphi-like IDE. >> Like I said, "Create" and "Destroy" are empty in TObject >> (i.e., they contain just an empty "begin end;" block). >> "Free" checks whether the pointer is Nil, and if it is not, >> it calls Destroy. > >Nice little "trick", but not very systematic. "Free" is a method of an >object, and this object can be "nil^"!? Technically, it works, but "Free" >must not be virtual (I guess it isn't in Delphi)! But as a clean way, I'd >prefer a procedure... (Or should we regard it as defined behaviour to call >a static method of a non-existing object if the method doesn't access any >fields of the object?) Well, "Free" is written in ASM. So, maybe therein lies the magic. I don't understand the ASM code, so I can't really comment on this. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Delphi classes
by The African Chief 07 Jul '97

07 Jul '97

On Sat, 5 Jul 1997 16:16:55 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: [...] >I understand this as follows (please correct me if I am wrong): > >The object inspector, a development tool, lets you specify values for >`published' variables interactively. After that, a copy of the object >is stored in a resource file read by the application. Like this, the >program can (and will) use an instance of the object with the fields >having these values. Yes, this is more or less the correct analysis. >> You can also attach specialized editors for >> complex properties. > >So you can extend this functionality of the object inspector. Yes, by writing your own "property editor" for your objects or data structures. Delphi's object inspector at the moment only works well with enumerated types, Pascal strings, and numerical types. If your object has properties which are records or pointers or other more complex data structures, you will need to write your own property editor for these structures, otherwise, you cannot "publish" those properties. They will have to be "public". Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Delphi classes
by The African Chief 07 Jul '97

07 Jul '97

On Sat, 5 Jul 1997 20:21:24 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >Ken Linder wrote: > >> The Object Inspector is a development tool that allows the developer to >> 'non-programaticaly' set the properties of an object before instantiation. >> Here is a quick example: >> >> ... >> published >> Caption : string; >> Status : (Maximized, Minimized, DontKnow); >> SomeNum : integer; >> ... >> Lets say the above is part of an object that can be 'dragged' onto the >> desired window. (Yes, I know I am talking Windows here) Selecting the >> object after it is dragged onto the window will make the 'object inspector' >> display all 'published' properties of that object. The object inspector >> will allow the programmer to enter some string for Caption, select one of >> the enumerated values for Status, and an integer for SomeNum. At run-time >> the object inspector don't exist. It is strictly part of the Delphi (and >> C++ builder) development tool. > >AFAI understand it, it's just some form of debugger, isn't it? (Typical for >all the Windoze hype to introduce new names for the same old things...?) >I think, changing values of object fields can be done with any debugger. The object inspector is not a form of debugger. It is a visual design tool, that allows the properties of an object to be set and changed without writing any source code (just change the values in the object inspector). Thus, it is possible (in theory) to write a fully fledged program without writing a single line of code. It all depends on the richness of your "components". >Anyway, so the difference between "published" and "public" is just relevant >to the debugger, not to the compiled program? It is relevant to the object inspector, at design time. The values which you set in the object inspector are preserved in the compiled program (just as if you had manually written the code to set those values before compiling the program). Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

GNU Pascal preconfigured
by Peter Gerwinski 07 Jul '97

07 Jul '97

According to Jan-Jaap van der Heijden: > > I have some preliminary stuff here to package GPC in an RPM. RPM is a > popular package manager in the Linux world. It makes upgrading a > binary distribution as easy as `rpm -U gpc-YYMMDD.i386.rpm' Hmm ... now it is as easy as `tar xzf gpc-YYMMDD.i386-linux.tar.gz'. I am probably missing something. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Procedural Types
by Peter Gerwinski 07 Jul '97

07 Jul '97

Hallo, Bernhard, hello, everybody! According to Bernhard Tschirren: > > [...] The following program > demonstrates this bug. In some (RANDOM!) cases, the program works, in others > it prints out only the first letter of the 'OK'. [...] (*$if 0 *) Now we are in trouble: I cannot reproduce this bug, neither on DJGPP, nor on Linux. I'd like to ask you to do further analysis on this: - Is the address returned by `Name1' and `Name2' the same? (It should be!) - What are the bytes pointed to by both returned `CString's? I mean something like the following: Program Bug02; Uses Bug02_U in 'b5u.pas'; {$X+} Type ByteArray = array [ 0..3 ] of Byte; ByteArrayPtr = ^ByteArray; Var ProcRec : TProcRec; P1, P2: CString; i: Integer; Function TheName : CString; Begin TheName := 'OK'; End; Begin ProcRec.Name1 := @TheName; ProcRec.Name2 := @TheName; P1:= ProcRec.Name1^; P2:= ProcRec.Name2^; writeln ( Integer ( P1 ) ); writeln ( Integer ( P2 ) ); writeln ( P1 ); writeln ( P2 ); for i:= 0 to 3 do write ( ByteArrayPtr ( P1 )^ [ i ] : 4 ); writeln; for i:= 0 to 3 do write ( ByteArrayPtr ( P2 )^ [ i ] : 4 ); writeln; End. On my system, the result is 5456 5456 OK OK 79 75 0 144 79 75 0 144 as it should be. (The 5456 and 144 are fixed, but arbitrary numbers.) (*$else *) Ah - now I have it! :-) With high probability that's another shape of a known bug: You cannot assign procedures defined in a *program* to procedural variables (or procedural pointers, like in your example). :-( To check this, please move `TheName' to a Unit (either `Bug02_u' or another one), and retry. <keeping fingers crossed> These procedures are treated as local subprocedures of the main program which is a procedure by itself. This is the source of a lot of trouble, also in other contexts, but it is necessary to make some nonlocal `goto's work which are required by Extended Pascal. (No, I don't use `goto', and I don't know more about this, sorry. If I had a test program for these nonlocal `goto's, I could try to make the other stuff work *without* breaking `goto'; right now I don't dare to touch this. ;-) (*$endif *) Thanks for your help, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Delphi classes
by David Fiddes 07 Jul '97

07 Jul '97

>What Borland did with Delphi was to design the compiler to work >together with exactly one library (VCL), exactly one set of development >tools (object inspector etc.) on exactly one platform (Windows). I don't >like this approach because it contradicts the general applicability of a >compiler. NO WAY! The only odd thing about Delphi is the compiler portion. The whole system is designed to be cross platform(unlike C/C++,Pascal,et cetera) from the ground up. The only thing preventing it is that Borland is too skint/not interested in doing it. You can replace the VCL if you so wish the only thing you lose is compatibility with the IDE. The Windows VCL implementation could quite easily(and I mean this) be swapped out and replaced with an X-Windows-VCL, Mac-VCL, NEXT-VCL, etc,etc,etc. It should be possible to build(as in compile) a standard(i.e. not using Windows fns direct) Delphi application on any compatible compiler/processor/OS combination without touching the source at ALL. GNU-Delphi is a real possibility. The only thing you would lose is the pretty IDE which, naturally, remains the property of Borland...afterall, everyone has a Windows box to do the initial development on. I would be really interested in a command line cross-compiler for Delphi that would allow me to port my existing Delphi software to the Mac, X Windows,etc for nil effort. I build educational software for a living which gets sold to the general public/consumer(all PC based) and to teachers/schools/colleges,etc which for various political reasons use a wide variety of muck including Macs....I want to sell to these folk...these folk want to buy from me...but they don't want to have to re-equip with PCs....and doing serious development on anything other than Delphi is out of the question as it would quadruple the lead time/number of staff required to complete a given project. fyi, this is why I like GNU-Pascal. yours (rantingly), Dave Dave Fiddes, CALM Software Production Officer Department of Mathematics, Heriot-Watt University, Edinburgh email D.J.Fiddes(a)hw.ac.uk - Tel: 0131-451-3251

1 0

"Easy install" GPC/djgpp release.
by Jan-Jaap van der Heijden 06 Jul '97

06 Jul '97

Hello all, I wrapped up a GPC distribution with all essential tools included, fitting on 1.44" disks. I reused the installation tool of djgpp V1.x. Although it looks a little aged, it does what it's supposed to do. URL: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/easy-djgpp/ Let me know what you think about it. JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

Re: Delphi classes
by Frank Heckenbach 06 Jul '97

06 Jul '97

Peter Gerwinski wrote: > > > New(Foo); > > > Foo.Create; > > > > If it's undefined in Delphi, it wouldn't hurt if there is a defined > > behaviour in gpc. :-) > > You cannot `New' a class because it is a reference, no pointer. > The above should be a syntax error in GPC as well as in Delphi. I meant the "Foo.Create" which could be allowed in gpc, I overlooked the "New(Foo)" line which in fact wouldn't make much sense. > That's the anti-motivating part of compatibility: All this is intended *not* > to be used. Yes, but we basically have the choices to say "you must convert this and this and that before your programs will compile with gpc, then they won't compile with BP anymore, but you can do much better things", or "you can just compile most of your BP programs with gpc, and once you're convinced that gpc really does its job, you can make use of more advanced features as fast as you want to" -- I guess most BP users would accept only the latter way... > > Nice little "trick", but not very systematic. "Free" is a method of an > > object, and this object can be "nil^"!? Technically, it works, but "Free" > > must not be virtual (I guess it isn't in Delphi)! But as a clean way, I'd > > prefer a procedure... (Or should we regard it as defined behaviour to call > > a static method of a non-existing object if the method doesn't access any > > fields of the object?) > > Sorry, but this nice little trick is purest brain-damage! Doesn't matter since Delphi runs only under Windoze -- there's nothing to damage... ;-) > - Dereferencing a `Nil' pointer should yield a runtime error. Both BP > and GPC don't check this, but this is a bug in the compiler to be > eliminated when we implement runtime checks into GPC. A very good idea! > - Releasing the storage of an object while a method of it is running > is idiocy. It should yield a runtime error, too, but this is too > hard to detect for the compiler. True. But I fear a Delphi compatibility library will even have to emulate this... :-( (BTW: Since OOP objects are often compared to real world objects or persons, this "Free" method would mean: 'Commit suicide, and bury your own corpse, please!' ;-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Procedural Types
by Bernhard Tschirren 06 Jul '97

06 Jul '97

Somehow, procedural types are not transported through the GPIs correctly. I am using gpc-970624 (BETA) for DJGPP 2.01. The following program demonstrates this bug. In some (RANDOM!) cases, the program works, in others it prints out only the first letter of the 'OK'. The bug does not only affect functions returning CCtring (PChar) values, it affects all procedural types (Procedures AND Functions). BUG02_U.PAS: ------------ Unit Bug02_U; {$X+} Interface Type TProcRec = Record Name1 : ^Function : CString; Name2 : ^Function : CString; End; Implementation End. BUG02.PAS: ---------- Program Bug02; Uses Bug02_U; {$X+} Var ProcRec : TProcRec; Function TheName : CString; Begin TheName := 'OK'; End; Begin ProcRec.Name1 := @TheName; ProcRec.Name2 := @TheName; WriteLn(ProcRec.Name1^); { Prints out 'OK' } WriteLn(ProcRec.Name2^); { Prints out 'OK', or sometimes only 'O' } End. Good Luck finding this bug ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

GPC in an RPM
by Jan-Jaap van der Heijden 06 Jul '97

06 Jul '97

Hello, I finished the RPM (RedHat Linux distribution package) I mentioned earlier. It can be downloaded from a new "redhat" subdirectory on agnes.dida.physik.uni-essen.de While I built it on my RedHat 4.2 distribution, it should work also for other RPM based installations (Caldera, etc.) I included all patches to GCC found in the gcc-2.7.2.1.src.rpm so it should build on Linux/alpha and Linux/sparc as well, but I cannot verify this. As soon as we have gpc-2.1, it should probably be uploaded to the redhat-contrib archive. Okay, so now installation on Redhat is reduced to only a few mouseclicks. Too bad you still need a keyboard to *use* it ;-) JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

GNU Pascal preconfigured
by Peter Gerwinski 05 Jul '97

05 Jul '97

Hi, everybody! (*$ifdef Andreas Eckleder *) Hallo, Andreas! Meine persoenliche Antwort an Dich kam dreimal zurueck mit dem Vermerk "unbekannter Host". Da die Angelegenheit ohnehin alle GPCies betrifft, antworte ich jetzt ueber die Liste. Ich hoffe, Du hast nichts dagegen, dass ich Teile deiner persoenlichen e-mail hier uebersetze und veroeffentliche ... #-) (*$endif *) Andreas Eckleder wrote to me (in German; translation by myself): > What about creating a GNU Pascal distribution with an installation > tool which makes it extremely easy to install, and simultaeously > does some other configuration tasks (environment variables, RHIDE > configuration)? > [...] I would vote for it! Once upon a time I had started myself to write such an installation tool, but then there were several urgent GPC errors which were much more interesting ... ;-) For DOS or for Linux? (Or for SGI?;-) Be welcome to distribute this package on agnes and kampi, together with the rest of GNU Pascal! However we must take care not to spoil the structure of the other parts of the GPC distribution. We do not want to prefer DOS or Linux users to any other ones. The current structure is: / = ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/ or ftp://kampi.hut.fi/jtv/gnu-pascal/ / GPC source, global `README', etc. /binary/ GNU-style GPC binary distribution, i.e. gpc-2.0.i586-linux.tar.gz, gpc-2.0.i386-djgppv201.zip, ... /djgpp/ DJGPP-style GPC distribution (gpc20s.zip, gpc20b.zip) /emx/ EMX-style GPC distribution (gpcsrc.zip, gpcdev.zip) /beta/ beta versions /alpha/ alpha versions /old/ museum /contrib/ useful independent contributions, e.g. `BPCompat' /misc/ other stuff, e.g. the GPC WWW home page. The package (How to call it? What about "Easy GPC?" I am taking this as a working title ... :-) must not occupy the main directory. OTOH, we must not hide it, of course. What about another subdirectory `/easy/' from the same type as `/djgpp/' containing all needed `.zip' files plus the installation program and `README'? Having this, a user only needs to download the contents of *one* directory. /easy/ complete GPC distribution for DOS (DJGPP) with a user-friendly, interactive installation program And the global `README' would get a prominent pointer to this directory: The easy way to install GNU Pascal ================================== If you are running DOS, and you want to install a complete package via a user-friendly, interactive installation tool, please go to the `easy' subdirectory, download all files, store them in one directory on your hard disk, and type `install'. If I remember right, The African Chief (Hi!:) had planned to write something similar for Windows. Then we could create more directories of this type, e.g. `/easy-dos/' and `/easy-w32/', and change the text in `README' accordingly. BTW, the installation program "must" contain a text browser which presents the GNU license in full length! I have the impression that many users consider a program the more interesting, the more penetrant you point them to the license terms and conditions. If you tell them "you can just proceed and use it", people become sceptical. sqr ( BTW ), if all components included are under the GNU GPL, it is perfectly legal to burn the whole stuff on a CD (or a stack of floppies) and to sell that CD. You are invited to do that, too. Tschuess, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Delphi classes
by Frank Heckenbach 05 Jul '97

05 Jul '97

Ken Linder wrote: > The Object Inspector is a development tool that allows the developer to > 'non-programaticaly' set the properties of an object before instantiation. > Here is a quick example: > > ... > published > Caption : string; > Status : (Maximized, Minimized, DontKnow); > SomeNum : integer; > ... > Lets say the above is part of an object that can be 'dragged' onto the > desired window. (Yes, I know I am talking Windows here) Selecting the > object after it is dragged onto the window will make the 'object inspector' > display all 'published' properties of that object. The object inspector > will allow the programmer to enter some string for Caption, select one of > the enumerated values for Status, and an integer for SomeNum. At run-time > the object inspector don't exist. It is strictly part of the Delphi (and > C++ builder) development tool. AFAI understand it, it's just some form of debugger, isn't it? (Typical for all the Windoze hype to introduce new names for the same old things...?) I think, changing values of object fields can be done with any debugger. Anyway, so the difference between "published" and "public" is just relevant to the debugger, not to the compiled program? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: GNU Pascal beta version gpc-970624
by Peter Gerwinski 05 Jul '97

05 Jul '97

According to Maurice Lombardi: > > djtar -x -v gpc-9706.tgz (8.3 limitation) > > It barks: unable to create the directory gpc-970624/p/ Ah - sorry, there should be a separate `.zip' source archive for DJGPP and EMX. I am uploading it now. > I found that the only difference is that now all is in > the subdirectory p/ It seems so. This is done because the GPC source shall go into a subdirectory `p' of the GCC source. However the contents of the directory has changed violently as well. > This is supported also by the fact that the files COPYING.gpc and > INSTALL.gpc which are said in the file gpc-970624/p/install to be within > gpc-970624 together with the directory p are not there. Yes, we first had `COPYING.gpc' and `INSTALL.gpc' in the GCC top directory, but I thought that they are better in the `p' subdirectory. Having two identical files `COPYING' and `COPYING.gpc' in the GCC source looks stupid IMHO, but having two copies of `COPYING' in different directories is okay. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Delphi classes
by Peter Gerwinski 05 Jul '97

05 Jul '97

According to Ken Linder: > ... > published > Caption : string; > Status : (Maximized, Minimized, DontKnow); > SomeNum : integer; > ... > Lets say the above is part of an object that can be 'dragged' onto the > desired window. (Yes, I know I am talking Windows here) Selecting the > object after it is dragged onto the window will make the 'object inspector' > display all 'published' properties of that object. The object inspector > will allow the programmer to enter some string for Caption, select one of > the enumerated values for Status, and an integer for SomeNum. At run-time > the object inspector don't exist. It is strictly part of the Delphi (and > C++ builder) development tool. I understand this as follows (please correct me if I am wrong): The object inspector, a development tool, lets you specify values for `published' variables interactively. After that, a copy of the object is stored in a resource file read by the application. Like this, the program can (and will) use an instance of the object with the fields having these values. > You can also attach specialized editors for > complex properties. So you can extend this functionality of the object inspector. When implementing it for GPC, we should do this from the very beginning: The library somehow exports methods how to edit these fields. All this can easily be implemented in a library without touching the compiler. In Delphi, they obviously implemented it in an external program which reads some data about the application (kind of debugging information) which requires close interaction with the compiler. > The inspector also allows the programmer to attach > functions and procedures to events but that is VERY windows based due to the > message passing nature of the Windows OS. ^^^^^^^^^^ (* "Windows program" or "Windows server program". It's no OS, but a GUI. Let's call it "platform" which covers both. ;*) Messages are not Windows-specific. Turbo Vision has them, too, so does the OS/2 presentation manager, and, AFAIK, X always did, too. What Borland did with Delphi was to design the compiler to work together with exactly one library (VCL), exactly one set of development tools (object inspector etc.) on exactly one platform (Windows). I don't like this approach because it contradicts the general applicability of a compiler. For GPC, we should better implement a library (our VCL equivalent; GCL?) which comes with a set of development tools which works with this library, but can be adapted to work with other libraries as far as possible (e.g., it reads some information about the library from a configuration file included in the package). The compiler can produce information of general interest (perhaps the debugging information is already sufficient) read by the development tools, but any library-specific information must be produced by the libary, not by the compiler. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Delphi classes
by Peter Gerwinski 05 Jul '97

05 Jul '97

According to Frank Heckenbach: > According to myself (Peter Gerwinski): > > It's "class" = "reference to object". Fortunately, the GCC front-end > > is able to deal with such things, > > Fine! :-) (Front-end? Or back-end?) The front-end definitely is (read: we can use this for GPC); for the back-end it *might* be necessary to convert references to pointers. No big deal. > gpc will certainly not remove objects when classes are implemented. :-) It won't. :-) According to Frank Heckenbach: > According to The African Chief: > > New(Foo); > > Foo.Create; > > If it's undefined in Delphi, it wouldn't hurt if there is a defined > behaviour in gpc. :-) You cannot `New' a class because it is a reference, no pointer. The above should be a syntax error in GPC as well as in Delphi. > My suggestion: implement a compiler switch like '--base-class="TObject"' so > that gpc will use this class by default as a parent class if no parent is > declared (and, of course, if the current class is not "TObject" itself ;-). > With "--delphi", this switch could be set automatically. Then, TObject could > be declared in some unit (like System for Delphi). (For "completeness", we > could also have '--base-object' or so...) Sounds reasonable. > BTW: This is similar to the '--uses="system"' I suggested -- things that > are not really the job of the compiler, but needed for compatibility. Such > switches seem to make the difference to the compiler as small as possible. Sounds reasonable. (Even *more* switches!) > For BP/Delphi programs that are just recompiled with gpc, these switches > can be used. When the programs are really ported to gpc, these things would > probably put into them programs themselves, and the switches would not be > used anymore (neither for native gpc programs), I guess. That's the anti-motivating part of compatibility: All this is intended *not* to be used. > > Like I said, "Create" and "Destroy" are empty in TObject > > (i.e., they contain just an empty "begin end;" block). > > "Free" checks whether the pointer is Nil, and if it is not, > > it calls Destroy. > > Nice little "trick", but not very systematic. "Free" is a method of an > object, and this object can be "nil^"!? Technically, it works, but "Free" > must not be virtual (I guess it isn't in Delphi)! But as a clean way, I'd > prefer a procedure... (Or should we regard it as defined behaviour to call > a static method of a non-existing object if the method doesn't access any > fields of the object?) Sorry, but this nice little trick is purest brain-damage! I saw similar tricks in Turbo Vision. All of this works, but it relies on how the compiler and the RTS do things. - Dereferencing a `Nil' pointer should yield a runtime error. Both BP and GPC don't check this, but this is a bug in the compiler to be eliminated when we implement runtime checks into GPC. - Releasing the storage of an object while a method of it is running is idiocy. It should yield a runtime error, too, but this is too hard to detect for the compiler. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GNU Pascal beta version gpc-970624
by Peter Gerwinski 05 Jul '97

05 Jul '97

Hello everybody! Here again is a new version of GNU Pascal: gpc-970624. Since we are aiming gpc-2.1 now, this is considered a *beta* version. :-) GPC integrated into GCC ======================= We succeeded to integrate the GPC source tree into that of GCC. Now GPC is compiled and installed just like other GNU compilers. Advantages of this distribution to the users of GPC are: * Easier configuration: GPC is configured automatically when you configure GCC. To build it, simply type "make LANGUAGES=pascal" in the GCC directory. No more VPATH problems with some (read: Solaris) versions of `make'. * Building GCC, G++, ObjC, GPC and G77 (GNU Fortran) from a single source tree is now possible. Benefits for GPC developers: * Easier adaption to different GCC versions. * Better functional separation of GPC sources from the GNU back-end (code shared with GCC) and the GPC specific code. * A first step of further integration of GPC into the main GCC distribution? Other changes since gpc-970510 ============================== General news: * The version number is now again produced manually, so it does reflect the date of release, not of compilation. * The GCC_MINOR version number now yields the expected result of `7'. Bug fixes: * Concatenation of more than two String constants now results in a constant again, as it should be. * Chars passed to formal String parameters work now. * The warning "return type of `main' is not `int'" which occured with Pentium optimization is gone. * Enumerated types now can be exported by Units or Modules and are type-checked more strictly. * Pointers to single-character identifiers like `^A' now work as type specifications in variable declarations. (They no more crash with `^A' character constants.) * GPC no more crashes on errorneous constant definitions. * GPC no more crashes on errorneous initializers of structured variables. * AutoMake with (*$L foo.c *) sometimes appeared to chose the compiler to run at random, and it threw the dice to decide whether to recompile the file or not. This feature is replaced now by a more traditional method: (i) Derive the compiler to run from the extension of the file, and (ii) decide whether to recompile or not from the date of the last change. * Fixed some obvious bugs in the lexical analyzer which never showed up. (The situation was too exotic to appear in praxis.) * Extended Pascal's `ReadStr' (for BP users: this is EP's equivalent to `Val') now accepts numeric values in non-zero-terminated strings. (GPC's strings are not zero-terminated.) * Initialized strings no longer get a trailing `chr ( 0 )'. (Initialized `CString's (aka `pChar's) do; see below.) * Initialization of structured variables containing other structured variables works now. * OOP: Nested subfunctions of methods work now. * Pointer arithmetics now also works on the DEC Alpha, where `SizeOf ( Pointer)' is different from `SizeOf ( Integer )'. * Objects now also work on the DEC Alpha, where the type for sizes of objects is not `Integer' (32 bits) but `LongInt' (64 bits). * Packed arrays now also work on the DEC Alpha which does not like to access misaligned 64-bit words. * Schemata now also work on the DEC Alpha. * Functions returning `Char' values now also work on the DEC Alpha. * Module (Unit) constructors and destructors now also work on the DEC Alpha. (You see: The DEC Alpha is a good platform to test GPC!) UCSD (and Borland) Pascal: * `Exit' handles function return values correctly now. * Functions returning `String' now default to return `String ( 255 )'. Without the `--borland-pascal' switch, a warning is given. (According to EP, `String' is a Schema type in GPC and not limited to 255 characters.) Borland Pascal: * Control character constants like `^A' are now restricted to `^A..^Z' because `^^' happened to crash with double pointer dereferences, etc. (BP has a bug here and does even accept `^;' and `^ ' (with a blank). They might consider it a feature ...) * `Abstract' can be redeclared now. (BP has no built-in `Abstract', but Turbo Vision defines one.) * Assigning contant values to `pChar' (aka `CString') variables works now. * The `write' and `writeln' procedures now work for `pChar's, too. * Calls to procedural parameters now work in expressions, too. * Type casts now work like in BP, no more like in C. Delphi: * GPC now implements the function return `Result' variable. (According to EP it was always possible to implement it manually by declaring "Function foo ( bar: Integer ) = Result: Integer". (And it still is.:)) Extended Pascal: * Subarray access `a [ i..j ]' for non-Strings is now warned about in `--extended-pascal' mode. * Pointers to pointers to undiscriminated Schemata (e.g. Strings without specified length) work now. * Schemata are (read: should be;) initialized properly now in all situations. GNU extensions: * A new option `--executable-file-name' or (*$executable-file-name="foo"*) now provides an alternative mechanism (apart from `-o foo') to specify the executable output file. While `-o' can only be specified at the command line, this switch can be written in the source as a compiler directive. If the name is not explicitly given, it is derived from the source file name which contains the `Program' declaration. * A new option `--ignore-function-results' or (*$ignore-function-results *) now allows to ignore values returned by functions without (*$X+*). Since this is not as dangerous as, say, pointer arithmetics, it has got a separate switch. It has a counterpart `--no-ignore-function-results'. * `--extended-syntax' now has a counterpart `--no-extended-syntax'. * `TypeOf ( MyObj )' is not accepted as an lvalue any more; instead, you can use `AssignType ( MyObj, MyVmtLink )'. * Assignment of the return value of a function through `asm' statements is now recognized, so you won't get a superfluous "warning: return value not assigned" any more. * Pointer arithmetics: `inc ( p, n )' now increases the address pointed to by `n * SizeOf ( p^ )' rather than just `n'. * GPC has new integer types now. Below is a table with their sizes in bits and their equivalents in (GNU) C. The size is the same for all platforms I have access to, but I am not sure whether this will always and everywhere be the case. However, compatibility to GNU C is guaranteed to work to the extend of the GNU GPL. ;-) The `*Int' types are signed (integer), the `*Card' types unsigned (cardinal numbers). The `*Word' types are unsigned, too, but should be thought of having undefined sign; they are intended to be used where signedness does not matter. Bits Signed Unsigned undefined (GNU) C equivalent 8 ByteInt ByteCard Byte [signed|unsigned] char 16 ShortInt ShortCard ShortWord short [unsigned] int 32 Integer Cardinal Word [unsigned] int 32 MedInt MedCard MedWord long [unsigned] int 64 LongInt LongCard LongWord long long [unsigned] int 64 LongestInt LongestCard LongestWord long long [unsigned] int In addition, you can define the number of bits for `Integer', `Cardinal', and `Word' types by putting it in parentheses, Type Int16 = Integer ( 16 ); (* 16 bits *) Unsigned17 = Cardinal ( 17 ); (* 17 bits; stored in 32 bits *) (* except when in packed arrays *) (* and records (or on machines *) (* with 17-bit registers:-). *) Answer = Word ( 42 ); (* Stored in 64 bits *) The size is rounded up to the next unit the machine can access, usually a power of 2 with 8 bits being the smallest possible size. * Subrange types can be packed now: Type Foo: -12..127; (* Takes 4 bytes (fast access) *) Bar: packed -12..127; (* Takes 1 byte (saves memory) *) Where to get it =============== The source is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. Acknowledgement =============== We thank everybody who took part in the discussion about integer types and other extensions for good ideas. We thank Larry Carter, Frank Heckenbach, Abimbola A. Olowofoyeku, Markus Gerwinski, Berend de Schouwer, Maurice Lombardi, Phil Robertson, Bernhard Tschirren, and Dario Anzani for finding the bugs. We thank the IFF (Institut fuer Festkoerperforschung) of the FZ Juelich, Germany, for the opportunity to test this new version of GPC on a DEC Alpha computer. Greetings, Peter Gerwinski Jan-Jaap van der Heijden <peter.gerwinski(a)uni-essen.de> <j.j.vanderheijden(a)student.utwente.nl>

2 1

Re: Delphi classes
by Ken Linder 04 Jul '97

04 Jul '97

At 04:27 PM 7/4/97 +0200, Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: >> Right, only published propertied show up in the object inspector. I >> think for now, in GPC anyway, allow 'published' and treat it as a 'public'. >> When GPC moves to X-windows or gains a visual/graphical development tool, we >> should be able to utilize it better. > >Good idea. However, what is this object inspector, anyway? To me, it sounded >like a development tool, but now it seems like it's something used at >runtime, right? What do programs do with it? >-- >Frank Heckenbach, Erlangen, Germany >heckenb(a)mi.uni-erlangen.de >http://www.mi.uni-erlangen.de/~heckenb/links.htm > The Object Inspector is a development tool that allows the developer to 'non-programaticaly' set the properties of an object before instantiation. Here is a quick example: ... published Caption : string; Status : (Maximized, Minimized, DontKnow); SomeNum : integer; ... Lets say the above is part of an object that can be 'dragged' onto the desired window. (Yes, I know I am talking Windows here) Selecting the object after it is dragged onto the window will make the 'object inspector' display all 'published' properties of that object. The object inspector will allow the programmer to enter some string for Caption, select one of the enumerated values for Status, and an integer for SomeNum. At run-time the object inspector don't exist. It is strictly part of the Delphi (and C++ builder) development tool. You can also attach specialized editors for complex properties. The inspector also allows the programmer to attach functions and procedures to events but that is VERY windows based due to the message passing nature of the Windows OS. Later... Ken L kc7rad(a)vegasnet.net klinder(a)hn.com

1 0

Re: Delphi classes
by Frank Heckenbach 04 Jul '97

04 Jul '97

Marius Gedminas wrote: > In Delphi you can declare a method 'virtual' or 'dynamic' and when you want to > override it in an descendant class, you must do it with 'override' directive. And what happens if you don't use "override"? Does it overload the methods then? (Does it have overloading at all?) > I think it's only needed for Delphi compatibility, where TObject is the > ultimate ancestor of all objects. Perhaps another compiler switch (for > Delphi compatibility)? I agree (see below). Peter Gerwinski wrote: > It's "class" = "reference to object". Fortunately, the GCC front-end > is able to deal with such things, Fine! :-) (Front-end? Or back-end?) > so we "only" have to implement the > syntax into GPC - and take care that it doesn't break other applications > of reference types such as `Var' parameters and procedural variables. Yes. Are value and reference parameters of class type the same, then (in Delphi)? Or do reference parameters pass a pointer/reference to the reference, i.e. do they allow destroying and recreating the object? Are pointers to classes allowed in Delphi, and what do they mean? > We should try to be compatible to Delphi and the ANSI Object Pascal draft. Yes. And it would be even better if there was any documentation about them available... ;-) For Delphi, I don't have much hope since it's non-free, but Object Pascal? (Should I do another Yahoo search...? ;-) Larry Carter wrote: > > > > 6. All classes to have the same ultimate ancestor object. > > When I actually started to think about this, I realized how this could be > a problem. In Delphi, this commmon object works great becuase it provides > all the basic machinery neccessary for all objects, however, this is > machinery that is specific to the Intel running Windows environment, the > memory model etc. An object of this type in GPC would probably be very > bloated, making all its decedants bloated, becuase of all the different > environments it would have to handle. Perhaps a library of foundation > objects for each OS?? Especially since this really has little to do with > the compiler itself anyway! :) I think the problem we're facing is that Delphi is not really a "standalone" language, but partly tied to one special environment. Since for gpc, portability is a more important goal than conformance to other (non-standard) compilers, I agree that such things do belong into libraries. AFAICG, objects in Delphi are typically things like windows, editors, dialogs and such "big things". Other use of OOP is for "small things" like vectors or certain data types with their operations which are completely independent of OS's and such. The African Chief wrote: > >Saves declaring those "PFoo" types, OTOH makes it impossible to declare > >global or local objects variables (without the overhead of allocating > >memory). If we have objects and classes, the programmer can choose what > >(s)he prefers. > > Delphi also supports both Objects and Classes - With the differences like I described them? > so it would be nice if we could as well. gpc will certainly not remove objects when classes are implemented. :-) > >> [b] the constructor does the heap allocation stuff, > >> e.g., "Foo := MyFoo.Create" > >> *allocates memory for Foo "(New, Foo)" > >> *calls Foo^.Create (constructor) > > > >So it's the same as "Foo := New(MyFoo, Create)" in BP? > > More or less. I'd like to know it exactly. Is there any difference (besides the different syntax, of course)? > Delphi destroys all objects that it creates itself. However, > if you manually create an object by calling its constructor, > you have to destroy it yourself with a call to "Free". Sounds logical. But when does Delphi create objects by itself? AFAIK, gpc doesn't do this yet, so we'd have to adopt this as well!? > I suspect that Delphi sets them to Nil as well, both before > construction and after destruction - otherwise the checks for > "Nil" made by TObject.Free would not make any sense, since > there is nowhere in the source code where these things are > manually set to Nil. So I think gpc should do this as well, at least for references (to classes). > Probably so. However, Classes are different from "mere" objects, > and I suspect that with Delphi, (assuming that Foo is an instance > of a Class, and not of a mere object) if you do; > > New(Foo); > Foo.Create; > > What "Foo" is pointing to may actually be undefined - and you will > certainly get an exception when you try to do anything with "Foo". If it's undefined in Delphi, it wouldn't hurt if there is a defined behaviour in gpc. :-) > In this case, it *is* necessary for Delphi compatibility. In Delphi > all classes are descendants of TObject. Doing this in Delphi; > > [...] > > The VCL depends on this being so, and we should also > support it (not least because Delphi programmers expect > this to be so). This means of course that TObject then has > to become part of the GPC RTS. For present purposes, it > only needs to be something like this; Sorry, but it probably can't be in the RTS, I think, because non-Delphi programs use the same RTS, and should not have this type. My suggestion: implement a compiler switch like '--base-class="TObject"' so that gpc will use this class by default as a parent class if no parent is declared (and, of course, if the current class is not "TObject" itself ;-). With "--delphi", this switch could be set automatically. Then, TObject could be declared in some unit (like System for Delphi). (For "completeness", we could also have '--base-object' or so...) BTW: This is similar to the '--uses="system"' I suggested -- things that are not really the job of the compiler, but needed for compatibility. Such switches seem to make the difference to the compiler as small as possible. For BP/Delphi programs that are just recompiled with gpc, these switches can be used. When the programs are really ported to gpc, these things would probably put into them programs themselves, and the switches would not be used anymore (neither for native gpc programs), I guess. > Type TObject = Class > Constructor Create; virtual; > Destructor Destroy; virtual; > Procedure Free; virtual; > end; {I am not sure about the "virtual" bit} > > {and any other (private) stuff needed for any compiler > magic that we need to do; The only magic field in gpc would be the "VMT" link. > Like I said, "Create" and "Destroy" are empty in TObject > (i.e., they contain just an empty "begin end;" block). > "Free" checks whether the pointer is Nil, and if it is not, > it calls Destroy. Nice little "trick", but not very systematic. "Free" is a method of an object, and this object can be "nil^"!? Technically, it works, but "Free" must not be virtual (I guess it isn't in Delphi)! But as a clean way, I'd prefer a procedure... (Or should we regard it as defined behaviour to call a static method of a non-existing object if the method doesn't access any fields of the object?) Larry Carter wrote: > > Saves declaring those "PFoo" types, OTOH makes it impossible to declare > > global or local objects variables (without the overhead of allocating > > memory). If we have objects and classes, the programmer can choose what > > (s)he prefers. > > Delphi does not allocate memory for object variables untill the object is > actually created with its create method. Yes, I understood this. What I meant is, you can declare BP (and gpc) objects globally or locally (if you know the exact type at compile time), so they will be located in the data segment or on the stack, and no memory has to be allocated at all. (Just a minor optimization for most cases, but e.g. for small local objects in a frequently called procedure it could make a real difference.) > In Delphi, the common object ancestor (TObject) provides the most basic > methods and properties that ALL objects need (creation, destruction, > etc.). These are the methods/properties that are unlikely to be > overridden (its rare that you would need a different destructor for > example) Sorry? I use different destructors all the time! E.g., if the object "possesses" other objects, it has to destroy them in its destructor. Or did you mean another destructor of another name (but that's not overriding)? > and having a common ancestor provides the programmer with a ready > to go foundation for his/her objects. I think a common ancestor is the > right way to go. Yes, for a library. Ken <kc7rad(a)vegasnet.net> wrote: > Having the 'private' declarations visible anywhere within the unit in > which it was defined is sort of a compatability thing with C++ 'friends'. I had this suspicion, too. So I think, with "--borland-pascal", we should define the visibility like in BP. For the standard gpc mode, however, we should limit it to the class itself, and instead introduce friends like in C++ (one of the useful features of that language, IMHO). > Correct me if I am wrong, but a C++ class can be defined as being 'friends' > with another class. Since they are 'friends', they can share certain > properties. I personaly don't care for this. There are better ways of > access properties in other classes! Plus this breaks the idea of 'object > oriented' programming and provides a way around the OO paradigm. Well, I haven't had a need for them in my BP programs (and haven't made use of the extended visibility in BP), but from some exercises I did in a C++ course, ISTR that they can be useful sometimes... > Right, only published propertied show up in the object inspector. I > think for now, in GPC anyway, allow 'published' and treat it as a 'public'. > When GPC moves to X-windows or gains a visual/graphical development tool, we > should be able to utilize it better. Good idea. However, what is this object inspector, anyway? To me, it sounded like a development tool, but now it seems like it's something used at runtime, right? What do programs do with it? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Delphi classes (Was: bugs, incompatibity, function attributes)
by Ken 03 Jul '97

03 Jul '97

>>Is this the same as "public" in C++ (= visible to everyone)? I, personally, >>would prefer "public", "protected" (=visible only to descendants) and >>"private" (=visible only to the type/class itself -- BTW, BP does it a bit >>differently, and extend the visibility of private methods to the whole unit >>it's declared in. I don't see any reason or advantage of this). So, perhaps >>we could allow all those keywords, including "published", in any order, also >>possibly repeated (unlike BP). > >In Delphi there are four such directives: > > public - like in BP - visible for everyone > private - like in BP - visible only for this unit (I don't see any > advantages too) Having the 'private' declarations visible anywhere within the unit in which it was defined is sort of a compatability thing with C++ 'friends'. Correct me if I am wrong, but a C++ class can be defined as being 'friends' with another class. Since they are 'friends', they can share certain properties. I personaly don't care for this. There are better ways of access properties in other classes! Plus this breaks the idea of 'object oriented' programming and provides a way around the OO paradigm. > protected - visible for this class and its descendants > published - same as public, but also accessible at the design time > (in Object Inspector) - I don't program Delphi, but as I > remember only properties were placed here. Right, only published propertied show up in the object inspector. I think for now, in GPC anyway, allow 'published' and treat it as a 'public'. When GPC moves to X-windows or gains a visual/graphical development tool, we should be able to utilize it better. Just my thoughts... Ken L kc7rad(a)vegasnet.net klinder(a)hn.com

1 0

Delphi classes (Was: bugs, incompatibity, function attributes)
by Peter Gerwinski 03 Jul '97

03 Jul '97

According to Frank Heckenbach: > > Besides, removing "asmname" would break some existing programs (including > a published one of mine)... Okay, I will let it in. > So "class" = "pointer to object", approximately... It's "class" = "reference to object". Fortunately, the GCC front-end is able to deal with such things, so we "only" have to implement the syntax into GPC - and take care that it doesn't break other applications of reference types such as `Var' parameters and procedural variables. > [Constructors and destructors ...] We should try to be compatible to Delphi and the ANSI Object Pascal draft. > This reminds me of C++'s "reference types" (not only for objects, but for > any types). I.e., a pointer internally, but dereferenced automatically when > necessary. I think they could be quite useful sometimes, anyway, and if > they'll be implemented (syntax?), we'd have "class" = "reference to > object"... General-purpose reference types? :-/ That's C++'s workaround for the missing `Var' parameters. I think this would cause more confusion than goods. > [public, published, private, protected, ...] So, perhaps > we could allow all those keywords, including "published", in any order, also > possibly repeated (unlike BP). I agree. > > 6. All classes to have the same ultimate ancestor object. > > The same discussion as with objects recently... ;-) > Is this really necessary (if so, for what?), or is it sufficient if all > classes in a given library use the same ancestor by convention? I don't like this at all. This is very useful as a convention when writing a library, but it is not the job of the compiler. Since Delphi seems to do it this way, GPC should behave the same in `--delphi' mode, but not by default. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Delphi classes (Was: bugs, incompatibity, function attributes)
by The African Chief 03 Jul '97

03 Jul '97

On Thu, 3 Jul 1997 01:13:18 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: [...] >> 2. [a] a Class instance becomes a pointer to the class; >> (or is it that the Class itself is a pointer to an object/class?); > >I think the latter would be a more consistent interpretation (at least for >us, even if Delphi does it otherwise). So "class" = "pointer to object", >approximately... I agree. I think this is how Delphi does it too. "Procedure Foo (Bar: TObject)" in Delphi is the same as "Procedure Foo (Bar: pObject)" in BP. However, Delphi automatically deferences "Bar" every time it is referred to. >> e.g., "Var Foo : MyFoo" >> = "Var Foo : ^MyFoo" in the current OOP model > >Saves declaring those "PFoo" types, OTOH makes it impossible to declare >global or local objects variables (without the overhead of allocating >memory). If we have objects and classes, the programmer can choose what >(s)he prefers. Delphi also supports both Objects and Classes - so it would be nice if we could as well. >> [b] the constructor does the heap allocation stuff, >> e.g., "Foo := MyFoo.Create" >> *allocates memory for Foo "(New, Foo)" >> *calls Foo^.Create (constructor) > >So it's the same as "Foo := New(MyFoo, Create)" in BP? More or less. >What about destructors? Does Delphi still use "Dispose", or has it another >syntax too, or does it dispose of objects automatically. According to the docs, the destructor destroys the object and releases the memory allocated to it. You are advised that you seldom need to call the destructor directly, and that you should call the "Free" procedure instead, to release memory and dispose of the object. It says that "Free" checks to see if the pointer is nil before calling Destroy and is also more efficient in code size. However, when you look at the code for TObject.Destroy, it actually does nothing. Same thing with the constructor (TObject.Create). Thus all the memory allocation and deallocation stuff seems to be done with compiler magic. TObject.Free contains ASM code which tests what is in EAX (I am talking about 32-bit Delphi here), and does some other stuff with EAX and ECX and then does something with the VMT which I assume is a call to the ECX. "Destroy" destructor. Those of you who know Intel asm, will probably understand all this. >(C++, BTW, does the latter. It destroys e.g. local objects at the end of the function >automatically. Delphi destroys all objects that it creates itself. However, if you manually create an object by calling its constructor, you have to destroy it yourself with a call to "Free". >This is possible because in C++ every class has exactly one >destructor. I guess they set the pointer to nil automatically at the >beginning (and set it back to nil if the destructor is called manually), >so they can easily find all local objects that "exist" and destroy them.) I suspect that Delphi sets them to Nil as well, both before construction and after destruction - otherwise the checks for "Nil" made by TObject.Free would not make any sense, since there is nowhere in the source code where these things are manually set to Nil. >> *Foo now points to whatever >> "Foo.Create" - should generate an exception >> because Foo needs to be assigned to the >> constructor > >AFAICS, calling a second constructor does not even have to be forbidden -- >at least in gpc. Constructors can be called like normal methods from an >initialized object, though this is certainly uncommon practice. Probably so. However, Classes are different from "mere" objects, and I suspect that with Delphi, (assuming that Foo is an instance of a Class, and not of a mere object) if you do; New(Foo); Foo.Create; What "Foo" is pointing to may actually be undefined - and you will certainly get an exception when you try to do anything with "Foo". That may be why you need to assign "Foo" to its constructor - viz; Foo := TMyFoo.Create; >> 4. Virtual methods to be overridden must be overriden >> with the "override" directive; the "virtual" directive merely >> creates a new method (or at least, don't reject the >> "override" directive in a "Class" definition) > >Does this mean you have to use "virtual" for *every* method in Delphi, or >what is meant by "create a new method"? Somebody else (Marius Gedminas) has responded to this. >> 5. Allow "Published" methods (or at least, don't reject the >> "published" directive in a "Class" definition). > >Is this the same as "public" in C++ (= visible to everyone)? I, personally, >would prefer "public", "protected" (=visible only to descendants) and >"private" (=visible only to the type/class itself -- BTW, BP does it a bit >differently, and extend the visibility of private methods to the whole unit >it's declared in. I don't see any reason or advantage of this). So, perhaps >we could allow all those keywords, including "published", in any order, also >possibly repeated (unlike BP). And this too. >> 6. All classes to have the same ultimate ancestor object. > >The same discussion as with objects recently... ;-) Yes ;) >Is this really necessary (if so, for what?), or is it sufficient if all >classes in a given library use the same ancestor by convention? In this case, it *is* necessary for Delphi compatibility. In Delphi all classes are descendants of TObject. Doing this in Delphi; Type MyFoo = Class end; is exactly the same as doing this; Type MyFoo = Class(TObject) end; The VCL depends on this being so, and we should also support it (not least because Delphi programmers expect this to be so). This means of course that TObject then has to become part of the GPC RTS. For present purposes, it only needs to be something like this; Type TObject = Class Constructor Create; virtual; Destructor Destroy; virtual; Procedure Free; virtual; end; {I am not sure about the "virtual" bit} {and any other (private) stuff needed for any compiler magic that we need to do; Delphi contains some more stuff in TObject - most of them are all ASM, and I don't have a clue as to what they do }. Like I said, "Create" and "Destroy" are empty in TObject (i.e., they contain just an empty "begin end;" block). "Free" checks whether the pointer is Nil, and if it is not, it calls Destroy. So, TObject itself is easy to implement - but I don't know what compiler magic will need to be done to make sure that everything else works as expected. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Some new features
by Frank Heckenbach 02 Jul '97

02 Jul '97

Peter Gerwinski wrote: > > > What about extending (*$executable-file-name="foo"*) to accept > > > a directory? Or else (*$executable-path-name="/foo"*) and > > > (*$object-path-name="/bar"*)? > > > > I don't agree. The *name* of the executable can be considered part of the > > program. The *path* where it will be stored will be system dependent, so the > > path, IMHO, does not belong into the source, but on the commandline (or into > > a (system or user or project specific) config file, of course). > > A directive (*$Foo="Bar"*) is always equivalent to a command-line > option `--foo="Bar"'. I was just thinking about reasonable names > for these options. Ok, "executable-path-name" and "object-path-name" seem ok to me. I just doubt whether it's wise to allow putting them into the source (doing so would probably lead to "unexpected results" when moving the files to another system). Or are all command line options automatically allowed in the source now? > > > > - Passing the actual size for untyped (resp. void) parameters, so it can > > > > be access with sizeof. > > > > var x:void -> like C > > var/const x -> like BP > > BP does *not* pass the size of untyped parameters to the procedure. Sorry, I meant to say "like BP with extensions"... ;-) > Changing GPC would break compatibility to both C and BP; the latter > being unimportant because nobody will consider it a feature *not* > to have the size of a variable. I wouldn't even say it breaks compatibility. It just adds a feature ("backward compatible"). Programs written for BP cannot fail with gpc because of the additional parameter. > OTOH, many C libraries rely on a > `void*' parameter *not* being followed by a `size' parameter. Ok, then "void" works for these cases (passing an untyped pointer by value works, too). > Instead of changing the meaning of `Var foo', we are IMHO better off > when introducing a *safe* mechanism to pass variables of varying type > (and number). Procedure overloading will be "half the rent". ;-) But what about the other half? Overloading will only handle those cases where only a certain number of types are admitted. Other cases (like BlockRead/ -Write, Move, FillChar, to speak in BP terms) allow any type, so overloading doesn't help there. And since BP compatibilty is not really broken, I'd still vote for this. > > For procedural variables, BP uses "@ProcVar" to cast them into a pointer(!!!). > > gpc does not understand this, but the (more logical, IMHO) "Pointer(ProcVar)". > > Unfortunately, BP doesn't accept the latter, so AFAICS there's yet no way that > > works on both. :-( Since we can't change BP, we should make gpc recognize > > "@ProcVar", perhaps also only in "--borland-pascal". > > Okay; I have put it on my list. > > Plan: Recognize it, but warn. With `--borland-pascal' (same as > (*$borland-pascal*) :-), don't warn. Oh, oh... things seems to be much more difficult than I thought... :-( I saw that there could be problems with function type variables, resulting from the possible confusion between their addresses and the function results -- especially difficult if the function result type is a pointer type. Additionally, there can be manual type casts, and finally there's BP even more strange syntax "@@", meaning the address of the procedure/function type *variable*. So I did some tests, and now I'm completely confused! Since I don't know what the standard requires, I don't even know what are bugs, and what are features... That's why I'm posting the results without any comments. The first program: program x; {$x+} {$f+} {Write a pointer (with BP: only the offset, but this doesn't matter here)} procedure wp(p:pointer); begin writeln(integer(p)) end; {Test function} function y:pointer; begin y:=nil end; type t=function:pointer; var va:integer; v:t absolute va; begin v:=y; {Let v point to y} wp(@va); {Should give the address of the variable v for reference purposes} wp(@y); {Should give the address of the function y for reference purposes} {6 different ways of accessing some addresses...} {$ifndef __GPC__} wp(v); {$endif} wp(@v); {$ifndef __GPC__} wp(@@v); {$endif} wp(pointer(v)); wp(pointer(@v)); {$ifndef __GPC__} wp(pointer(@@v)); {$endif} end. The results with BP are (where "v" means the actual address of v, "y" that of y, and "0" means nil): v,y,0,y,v,0,y,v gpc gives (where "-" means, doesn't compile, and "?" is a seemingly arbitrary value): v,0,-,v,-,?,v,- With the SP syntax "^function:pointer", the "?" becomes 0. With the next program, gpc says "invalid lvalue in address expression" in line 4: program x; var a:procedure; b:integer absolute a; begin end. With this one, it says "void value not ignored as it ought to be" and "initial value is of wrong type" in line 5: program x; procedure y; begin end; var a:procedure value y; begin end. All I can see that the results are "a little bit" different from BP. :-( The last two programs seem to show that gpc tries to "evaluate"(?) a procedure when it shouldn't...!? Since I don't really understand what's going on, I have no ideas how to "fix" it. At least, we have a different syntax in BP and SP, so we could use different semantics if necessary (see above ;-)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: latest wip
by Peter Gerwinski 02 Jul '97

02 Jul '97

According to Bill Currie: > > I grabbed the 2.1 (01?) beta. Is that the correct verstion to work off? Yes. We call it gpc-970624. The next beta release is likely to follow within the next weeks. Have fun, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Long integers
by Peter Gerwinski 02 Jul '97

02 Jul '97

According to Frank Heckenbach: > > [...] -- or is it an instance of the "cannot write > longint variables" known bug? It is. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: latest wip
by Peter Gerwinski 02 Jul '97

02 Jul '97

Bill Currie wrote: > > Where can I get the latest WIP version? What's that? > Never mind, just found it (DOH! blind as a bat) :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

latest wip
by Bill Currie 02 Jul '97

02 Jul '97

Where can I get the latest WIP version? I'ld like to see if I can lend a hand. (Couldn't find a reference on the web pages,faq or info docs). Bill -- Leave others their otherness.

1 1

Re: bugs, incompatibity, function attributes
by Peter Gerwinski 02 Jul '97

02 Jul '97

According to The African Chief: > > 1. specifying DLL names; > With Borland, you need to specify the name of the DLL from which > you are importing a function. You need to do this with *every* > function. This is extremely tedious. Try doing that with the whole > Win32 API for example. Also, you would need to find some documentation > on which DLL holds which function. That is even more tedious. Thus, if we > are going to support the Borland syntax, then using it should be optional. > With GPC, you don't need to specify the DLL name - that is, I think, a > *great* advantage over Borland. Or you can specify the DLL name *once* with (*$L foo.a *) or something similar to be implemented. Yes - a great advantage! > 2. not having to redeclare the entire function in the implementation section; > I think it is good to support this. With Borland, you can redeclare the whole > function, or you can just specify it's name. You are not forced to do it in > any particular way, and you can mix and match. It would be nice if GPC > supported this. GPC *does* support this. > 3. Delphi's "name" directive; > This is exactly the same as GPC's "asmname" directive. We can > implement this simply by also allowing just the use of "name" in any place > where "asmname" would be allowed (i.e., we can dispense with the "asm" > part of the "asmname" directive). That way, we get the best of both worlds! Sounds reasonable. So should we just change "asmname" to "name"? Or keep both? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Long integers
by Frank Heckenbach 02 Jul '97

02 Jul '97

Peter Gerwinski wrote: > When I have the time :-( I "must" have a look at those pages. Maybe we > can find more interesting ideas for GPC there ... I'm quite sure, actually (though I only took a quick glance at them)! :-) (It'll be interesting to see if gpc's adopting other features can keep pace with new Pascal dialects being developed... ;-) > Schema discriminants must be ordinal types, but the following compiles: > > Type > roots ( p, q: Integer ) > = array [ 1..1 + ord ( sqr ( p ) / 4 - q <> 0 ) ] of Complex; > > However it is useless since > > Var > x: roots ( 4, 4 ); > > crashes GPC. That's what I meant with my "bug report". I didn't check if the type or the var declaration caused the internal error. I just found another bug -- or is it an instance of the "cannot write longint variables" known bug? var c:cardinal value $ffffffff; begin writeln(c) end. ...writes -1. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Some new features
by Frank Heckenbach 02 Jul '97

02 Jul '97

Peter Gerwinski wrote: > > - Commandline options to specify the directory(ies) > > a) to search for units/modules (source or compiled) > > My current plan is to use the `-L' path/s for this purpose. Yes, why not! (What I'd like best is if it (with "--automake") would look for a source file in the current directory and the "-L" path, and for a compiled module in the "-L" path and the b) path (see below), and if it finds both, compare the dates, regardless where it found them. I think that's how BP does it -- or even a little bit better... :-) > > b) to put compiled modules (.o, .gpi, .gpm) > > c) to put compiled programs (executables). > > \begin{sigh} > Even more options! > \end{sigh} But those are more useful than average, I think... ;-) I, personally, can't stand other files put between my sources, and for executables, there usually exists a separate directory, anyway... > What about extending (*$executable-file-name="foo"*) to accept > a directory? Or else (*$executable-path-name="/foo"*) and > (*$object-path-name="/bar"*)? I don't agree. The *name* of the executable can be considered part of the program. The *path* where it will be stored will be system dependent, so the path, IMHO, does not belong into the source, but on the commandline (or into a (system or user or project specific) config file, of course). > > - Passing the actual size for untyped (resp. void) parameters, so it can > > be access with sizeof. > > This would spoil compatibility to other languages such as C. What about: var x:void -> like C var/const x -> like BP > So perhaps make "Procedure Foo ( Var x )" pass the size, and keep > "Procedure Foo ( Var x: Void )" as it is (i.e. without passing the size)? I was typing too soon before reading this... :-) > Or introduce another data type? Only if necessary. (But I don't see why it would be, since there are already two types and two purposes -- if existing programs with "var x" do rely on C compatibility, those (few, probably) programs should be changed rather than the compiler...) > Okay; I have put it on my list. Fine! :-) And another one: For procedural variables, BP uses "@ProcVar" to cast them into a pointer(!!!). gpc does not understand this, but the (more logical, IMHO) "Pointer(ProcVar)". Unfortunately, BP doesn't accept the latter, so AFAICS there's yet no way that works on both. :-( Since we can't change BP, we should make gpc recognize "@ProcVar", perhaps also only in "--borland-pascal". -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: bugs, incompatibity, function attributes
by Peter Gerwinski 01 Jul '97

01 Jul '97

According to Jan-Jaap van der Heijden: > > Borland does it like this: > > ----------------------------------------- > unit Foo; > > interface > > function Bar(var i: integer): integer; > > implementation > > function Bar; external; > > end. > ----------------------------------------- GPC allows this: Unit Foo; Interface Function Bar ( Var i: Integer ): Integer; external; Implementation end. (Or `attribute', or `asmname' in the Interface part.) However, Borland-comptaible syntax should be supported, too. > Although it accepts the input, GPC doesn't do anything with the > directives. (function attributes not surviving the GPI mechanism is a > long-standing bug, but the "asmname" is silently ignored). It's fixed now. :-) > [...] > GPC has no equivalent for the "DLLfile". > But, if implemented, the automake mechanism could add an option > "-lDLLfile" to the linker command line, something you have to do manually > now. This is useful for all platforms, not just windows DLL's BTW. I agree. > 1. Are there any reasons not to change the "external" declaration, at > least for "borland" mode? This should be done. With what priority? > 2. Any objections against allowing (working, that is) function attributes > in the implementation part? When we want them in the GPI file, they *must* be present already in the Interface part. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Long integers
by Peter Gerwinski 01 Jul '97

01 Jul '97

According to Frank Heckenbach: > > How do you know about PXSC, anyway? Everything I know about PXSC is from one book, "Pascal-SC", in German only, I once have found at our library. I was impressed by the possibilities of exact (!) numerical calculations, and operator overloading. > I did a Yahoo search on "PXSC", and it showed quite a few interesting > things about PXSC (besides a few other things abbreviated by "PXSC" and > several links to gpc pages :-), e.g. PXSC "home pages": > > http://ma70.rz.uni-karlsruhe.de/~ae25/iam/html/language/xsc-sprachen.html > http://wwwma.rz.uni-karlsruhe.de/~ae08/iam/html/language/pxsc.html > > I also learned about even more Pascal extensions, like XL Pascal and > Pascal++ (see > http://www.informatik.uni-halle.de/lehre/pascal/sprache/pas0.html). When I have the time :-( I "must" have a look at those pages. Maybe we can find more interesting ideas for GPC there ... > On a page about BP, I found this remarkable statement: > "Borland is the leader in Object-Oriented Programming, winning more awards > for technical innovation and customer support than anyone else. That means > that when you use Turbo Pascal, you're guaranteed to have the best > development environment available, backed by the best support available. > It's Borland's commitment to you. > [...] > Copyright ) 1995 Borland International, Inc." > Things must have changed very much within 2 years... :-( That's just the problem: They didn't change (read: improve) anything since 2 years and more. > > Think of a schema as a type declaration with parameters which can occur > > anywhere in the declared type: as array or subrange boundaries, or as a > > variant record selector. > > Anywhere??? (roots:array[1..1+ord(sqr(p)/4-q<>0)] of complex;-) Schema discriminants must be ordinal types, but the following compiles: Type roots ( p, q: Integer ) = array [ 1..1 + ord ( sqr ( p ) / 4 - q <> 0 ) ] of Complex; However it is useless since Var x: roots ( 4, 4 ); crashes GPC. Expressions in schemata don't seem to work at all currently. > [long numbers] > > Not really the whole library; multiplying a long number by 10 (or any base) > would be relatively easy to do manually. But you're right, it won't probably > be needed too often, so this little inefficiency of the conversion at runtime > seems tenable... :-) ... except, maybe, if PXSC demands it ...? The compiler would have to deal with expressions formed by such numbers. Better leave this for a library. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Some new features
by Peter Gerwinski 01 Jul '97

01 Jul '97

According to Frank Heckenbach: > > Here are a few features I'd like to see in gpc. I hope they can be > implemented without much work... > > - Commandline options to specify the directory(ies) > a) to search for units/modules (source or compiled) My current plan is to use the `-L' path/s for this purpose. > b) to put compiled modules (.o, .gpi, .gpm) > c) to put compiled programs (executables). > > (They're similar to some BP options, except that BP uses the same for b) > and c) which I think is a bad idea, so I'd prefer different options.) \begin{sigh} Even more options! \end{sigh} What about extending (*$executable-file-name="foo"*) to accept a directory? Or else (*$executable-path-name="/foo"*) and (*$object-path-name="/bar"*)? > - Passing the actual size for untyped (resp. void) parameters, so it can > be access with sizeof. This would spoil compatibility to other languages such as C. > (E.g., with untyped files (at least in BP) I often have to do things like > "blockread(f,x,sizeof(x))", which could be simplified to > "blockreadvar(f,x)" then.) So perhaps make "Procedure Foo ( Var x )" pass the size, and keep "Procedure Foo ( Var x: Void )" as it is (i.e. without passing the size)? Or introduce another data type? > And for better BP compatibility: > > - A function "Concat", equivalent to the operator "+" for strings. It can't > be declared in system.pas since (in BP) it allows an arbitrary number of > arguments. > > - Ignoring the BP directives "near" and "far" after procedure/function > declarations (they're irrelevant to gpc, anyway) -- only in > "--borland-pascal" mode, of course. Okay; I have put it on my list. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Long integers
by Frank Heckenbach 01 Jul '97

01 Jul '97

Peter Gerwinski wrote: > I have heared of a library "gmp" which could be a useful tool to > achieve this. Just write a Pascal interface for it ... I'll look for it (when I've got some time... ;-) > > BTW: Is there any information about schema types and/or PXSC available? > > I don't know more about them than I saw in some examples. > > So do I. :-( How do you know about PXSC, anyway? I did a Yahoo search on "PXSC", and it showed quite a few interesting things about PXSC (besides a few other things abbreviated by "PXSC" and several links to gpc pages :-), e.g. PXSC "home pages": http://ma70.rz.uni-karlsruhe.de/~ae25/iam/html/language/xsc-sprachen.html http://wwwma.rz.uni-karlsruhe.de/~ae08/iam/html/language/pxsc.html I also learned about even more Pascal extensions, like XL Pascal and Pascal++ (see http://www.informatik.uni-halle.de/lehre/pascal/sprache/pas0.html). On a page about BP, I found this remarkable statement: "Borland is the leader in Object-Oriented Programming, winning more awards for technical innovation and customer support than anyone else. That means that when you use Turbo Pascal, you're guaranteed to have the best development environment available, backed by the best support available. It's Borland's commitment to you. [...] Copyright ) 1995 Borland International, Inc." Things must have changed very much within 2 years... :-( > Think of a schema as a type declaration with parameters which can occur > anywhere in the declared type: as array or subrange boundaries, or as a > variant record selector. Anywhere??? (roots:array[1..1+ord(sqr(p)/4-q<>0)] of complex;-) (I just tried it, it gives an internal compiler error. Not that I'd expect this to compile, but I heard somewhere, internal errors should always be reported...) > I doubt whether this is really useful. Numbers of this size aren't usually > typed in as decimal digits, but they are characterized as "2 pow 103 - 2 pow > 97 + 3 pow 13". And you can always write a function which accepts a string > or a chain of integers or whatever and returns a long number. > > [...] > > Then the compiler would have to use this arbitrary-precision library (gmp?) > by itself because a number must be multiplied by ten each time a digit is > read. Not really the whole library; multiplying a long number by 10 (or any base) would be relatively easy to do manually. But you're right, it won't probably be needed too often, so this little inefficiency of the conversion at runtime seems tenable... :-) ... except, maybe, if PXSC demands it ...? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: bugs, incompatibity, function attributes
by The African Chief 01 Jul '97

01 Jul '97

On Tue, 1 Jul 1997 01:15:36 +0100 (WET DST) Jan-Jaap van der Heijden <janjaap(a)Wit381304.student.utwente.nl> wrote: [...] >So: > >1. Are there any reasons not to change the "external" declaration, at > least for "borland" mode? 1. specifying DLL names; With Borland, you need to specify the name of the DLL from which you are importing a function. You need to do this with *every* function. This is extremely tedious. Try doing that with the whole Win32 API for example. Also, you would need to find some documentation on which DLL holds which function. That is even more tedious. Thus, if we are going to support the Borland syntax, then using it should be optional. With GPC, you don't need to specify the DLL name - that is, I think, a *great* advantage over Borland. 2. not having to redeclare the entire function in the implementation section; I think it is good to support this. With Borland, you can redeclare the whole function, or you can just specify it's name. You are not forced to do it in any particular way, and you can mix and match. It would be nice if GPC supported this. 3. Delphi's "name" directive; This is exactly the same as GPC's "asmname" directive. We can implement this simply by also allowing just the use of "name" in any place where "asmname" would be allowed (i.e., we can dispense with the "asm" part of the "asmname" directive). That way, we get the best of both worlds! >2. Any objections against allowing (working, that is) function attributes > in the implementation part? None that I can see - except if it makes things become more error-prone. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Some new features
by Frank Heckenbach 01 Jul '97

01 Jul '97

Here are a few features I'd like to see in gpc. I hope they can be implemented without much work... - Commandline options to specify the directory(ies) a) to search for units/modules (source or compiled) b) to put compiled modules (.o, .gpi, .gpm) c) to put compiled programs (executables). (They're similar to some BP options, except that BP uses the same for b) and c) which I think is a bad idea, so I'd prefer different options.) - Passing the actual size for untyped (resp. void) parameters, so it can be access with sizeof. (E.g., with untyped files (at least in BP) I often have to do things like "blockread(f,x,sizeof(x))", which could be simplified to "blockreadvar(f,x)" then.) And for better BP compatibility: - A function "Concat", equivalent to the operator "+" for strings. It can't be declared in system.pas since (in BP) it allows an arbitrary number of arguments. - Ignoring the BP directives "near" and "far" after procedure/function declarations (they're irrelevant to gpc, anyway) -- only in "--borland-pascal" mode, of course. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

bugs, incompatibity, function attributes
by Jan-Jaap van der Heijden 01 Jul '97

01 Jul '97

Hello, First: this is a small change to lang-specs.h to correctly pass directives from "specs" to gpc-cpp. GPC skips half of them. --- lang-specs.h.orig Mon Jun 2 02:01:51 1997 +++ lang-specs.h Tue Jul 1 00:00:18 1997 @@ -32,7 +32,7 @@ %{C:%{!E:%eGNU Pascal does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GPC__=%v1 -D__GNUC_MINOR__=%v2\ - %{!undef: %P}\ + %{!undef: %p %P} \ %c %{O*:%{!O0:-D__OPTIMIZE__}} %{traditional} %{ftraditional:-traditional}\ %{traditional-cpp:-traditional} %{trigraphs}\ %{g*} %{W*} %{w} %{pedantic*} %{H} %{d*} %C %{D*} %{U*} %{i*} %Z\ Then, I'm trying to get a somewhat borland-compatible syntax for external functions. GPC requires that the full declaration of a function is repeated, combined with the directive 'external': ----------------------------------------- unit Foo; interface function Bar(var i: integer): integer; implementation function Bar(var i: integer); integer; external; end. ----------------------------------------- Borland does it like this: ----------------------------------------- unit Foo; interface function Bar(var i: integer): integer; implementation function Bar; external; end. ----------------------------------------- ISO only mentions that "many processors provide, as an extension" 'external', but doesn't require it, let alone define the syntax to be used. Then, and this is a bug, GPC accepts this: ----------------------------------------- unit Foo; interface function Bar(var i: integer): integer; implementation function Bar(var i: integer); integer; external; attribute(stdcall); end. ----------------------------------------- The "attribute" part should be in the first declaration, not the second. The same error for other the "asmname" directive. Although it accepts the input, GPC doesn't do anything with the directives. (function attributes not surviving the GPI mechanism is a long-standing bug, but the "asmname" is silently ignored). To add to the confusion, this is how delphi declares a win32 API function imported from a DLL: ----------------------------------------- unit Foo; interface function Win32apiFunction(var i: integer): integer; stdcall; implementation function Win32apiFunction; external DLLfile name 'RealName'; end. ----------------------------------------- DLLfile is the name of the DLL (i.e. kernel32.dll), RealName need not be the same as Win32apiFunction: for 'MessageBox' the real name is 'MessageBoxA', to name one. A complete function declaration is not repeated, and while one attribute is in the declaration ('stdcall'), the other is in the implementation. GPC has no equivalent for the "DLLfile". But, if implemented, the automake mechanism could add an option "-lDLLfile" to the linker command line, something you have to do manually now. This is useful for all platforms, not just windows DLL's BTW. So: 1. Are there any reasons not to change the "external" declaration, at least for "borland" mode? 2. Any objections against allowing (working, that is) function attributes in the implementation part? Greetings, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

Volatile!!
by Peter Gerwinski 30 Jun '97

30 Jun '97

According to Bernhard Tschirren: > Is it possible to decalare a variable volatile? Var Foo: __volatile__ Integer; > Other than that, the latest release is excellent. Many bugs were fixed! :-) Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Rhide that chuchoo train...
by Peter Gerwinski 30 Jun '97

30 Jun '97

According to Orlando Llanes: > > Is there a version of RHIDE that doens't lock up? The last time I > downloaded it, I used rhide12b.zip is there a newer version? rhide13b.zip. :-) To stay up-to-date with RHIDE, please read news://comp.os.msdos.djgpp, or look at http://www.tu-chemnitz.de/~rho/rhide.html from time to time. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Long integers
by Peter Gerwinski 30 Jun '97

30 Jun '97

According to Frank Heckenbach: > > Thinking about it, it might be better to implement long integers as a > schema or object type (perhaps with PXSC operators?)... I have heared of a library "gmp" which could be a useful tool to achieve this. Just write a Pascal interface for it ... > BTW: Is there any information about schema types and/or PXSC available? > I don't know more about them than I saw in some examples. So do I. :-( > If I know more about them, it could be relatively easy to implement them... Think of a schema as a type declaration with parameters which can occur anywhere in the declared type: as array or subrange boundaries, or as a variant record selector. (I am not sure if the latter one really works.) For PXSC, it's even easier because operators are the only PXSC thing so far implemented in GPC. Procedure overloading will be the next one. And there is yet another syntax to define Modules (aka Units) which would probably be easy to implement if I really know how it looks like. > var x:array[1..10] of word; > > begin > x:=8932740732465987432659087423658294376597843265987432659786; > {fill this number into x (according to endianness, "0-padded" for > positive numbers, "F-padded" for negative ones)} I doubt whether this is really useful. Numbers of this size aren't usually typed in as decimal digits, but they are characterized as "2 pow 103 - 2 pow 97 + 3 pow 13". And you can always write a function which accepts a string or a chain of integers or whatever and returns a long number. > Would this be possible to do? The latter instruction seems more difficult. > "+" and "=" could be operators, implemented in Pascal. The requirement to > the compiler would be to convert such numbers into an array (and a length > value) automatically. Seems difficult, but since it's just like with > strings, I hope it's possible... Then the compiler would have to use this arbitrary-precision library (gmp?) by itself because a number must be multiplied by ten each time a digit is read. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Long integers (Was: Severe bug! :-(And some more bugs.))
by Frank Heckenbach 29 Jun '97

29 Jun '97

Peter Gerwinski wrote: > > Is "Integer(n)" supposed to support bigger types than LongestInt? > > No. Somebody else may implement that ... ;-) Thinking about it, it might be better to implement long integers as a schema or object type (perhaps with PXSC operators?)... BTW: Is there any information about schema types and/or PXSC available? I don't know more about them than I saw in some examples. If I know more about them, it could be relatively easy to implement them... > > The following program writes 0. ("+" doesn't seem to work correctly with > > big integers at all, telling from the asm code.) > > > > program x; > > var a:integer(128); > > begin > > a:=$FFFFFFFF; > > a:=a+1; > > writeln(integer(a)) > > end. > > This is correct: "a + 1" gets the integer value $100000000 in this > example; the cast to `Integer' yields an (uncatched)-: overflow and > the correct value 0 for the lowest 32 bits. The example was bad, but in fact a+1 did not get the correct value as the following programs shows (writes "0 0 0 0"). But obviously, it wasn't supposed to... program x; var a:integer(128); b:record c,d,e,f:cardinal end absolute a; begin a:=$FFFFFFFF; a:=a+1; writeln(b.f,' ',b.e,' ',b.d,' ',b.c) end. > > At least "=" seems to work with these types, which would make "Cardinal(128)" > > usable for ClassIDs (I hope)... :-) > > Sorry to have it taken out again! ;-) Then, we can use something like a record of 2 card64's (internally). Actually, thinking about it, it might even be better. If 64 bits are the "programmer ID" anyway, it could be easier to declare this once, and to declare only the other 64 bits (which is possible :-) for each class. And, when the "programmer ID" is declared (typically at the beginning of a unit), a base value for the "class ID" could perhaps also be given, so that the actually declared class IDs would be simple (small) numbers without the need of constants. I'm not sure about a good syntax for it, but I mean something like the following: const MyProgrammerID=$12345678; set base ID to MyProgrammerID,$0f000000 type x=object[1] ... which would result in an actual class ID of $123456780f000001. Unique and easy to type! :-) But it would also be useful (e.g. for constants for the big integers when they're implemented) to be able to specify (arbitrarily) long integers to be filled into a data structure (array of word or so...), analogous to arbitrarily long sequenced of characters filled into an array (aka strings :-). E.g.: var x:array[1..10] of word; begin x:=8932740732465987432659087423658294376597843265987432659786; {fill this number into x (according to endianness, "0-padded" for positive numbers, "F-padded" for negative ones)} if x+430985234985790342857=2938576498734697856 then ... end. Would this be possible to do? The latter instruction seems more difficult. "+" and "=" could be operators, implemented in Pascal. The requirement to the compiler would be to convert such numbers into an array (and a length value) automatically. Seems difficult, but since it's just like with strings, I hope it's possible... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Rhide that chuchoo train...
by Orlando Llanes 29 Jun '97

29 Jun '97

Is there a version of RHIDE that doens't lock up? The last time I downloaded it, I used rhide12b.zip is there a newer version? -- See ya! Orlando Llanes

1 0

Volatile??
by Bernhard Tschirren 29 Jun '97

29 Jun '97

Is it possible to decalare a variable volatile? I have been waiting for that a while now, and I expect it in 2.1!! :-) Other than that, the latest release is excellent. Many bugs were fixed! ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Info files problem..
by Peter Gerwinski 29 Jun '97

29 Jun '97

According to Kevin A. Foss: > I downloaded the new EMX binaries of gpc (970624) and find that > I can't get the info files to display: "info -f gpc.inf" yields: info: > Cannot find the node "Top". Ah - sorry! I again installed a copy of `gpc.inf' which had suffered from an RHIDE bug and has a doubled line End Tag Table End Tag Table at the end. To repair it, load `gpc.inf' with your favourite ASCII editor and remove one of these lines. This holds both for EMX and for DJGPP. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: GNU Pascal
by Peter Gerwinski 29 Jun '97

29 Jun '97

According to mtdew: > > Hi, Im very excited about using your GPC for programming some IRC > interfaceses (server and client) However, Im new to using GPC (not new to > borland pascal) and have been finding it difficult to find information on > commands/functions/procs that are specific to GPC. Indeed, our documentation is somehow outdated and incomplete. A lot of requests for extensions of GPC arise from the fact that nobody knows how to use the existing features. Sorry for that. If you want to help us to improve the GPC documentation, be welcome! (-: > I'm very interested in any information about opening sockets, so > that I can use them to connect with other irc servers.. (Or maybe even > just other servers of any sort of port) Is there support for this? > (Something similar to C's, 'socket'?) I don't know much about sockets (would like to know, however), but the GPC FAQ describes how to use arbitrary C libraries from GNU Pascal: 8< ---- begin (* FAQ extract *) ------------------------------------------ How do I use <insert_your_function_here> from the C library? ============================================================ GNU Pascal can use every function of your C library, but it may be up to you to write declaration of an external function, before you can use it. Consider the function `sleep'. `man(3) sleep' reveals: --------------------------------------------------------- NAME sleep - Sleep for the specified number of seconds SYNOPSIS #include <unistd.h> unsigned int sleep(unsigned int seconds); --------------------------------------------------------- This small demo program shows how to use `sleep' in a Pascal program: --------------------------------------------------------- program SleepDemo; type word = __unsigned__ integer; function sleep(seconds: word): word; C; var result : word; begin result := sleep(10); end. ---------------------------------------------------------- 8< ---- end (* FAQ extract *) -------------------------------------------- If you write a GPC Unit (or Module) to access sockets and such, be welcome to give us a copy we can publish with GPC. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GNU Pascal
by mtdew 29 Jun '97

29 Jun '97

Hi, Im very excited about using your GPC for programming some IRC interfaceses (server and client) However, Im new to using GPC (not new to borland pascal) and have been finding it difficult to find information on commands/functions/procs that are specific to GPC. I'm very interested in any information about opening sockets, so that I can use them to connect with other irc servers.. (Or maybe even just other servers of any sort of port) Is there support for this? (Something similar to C's, 'socket'?) Please mail me back with any information you may have on this! Thank You Donald Newberry desync(a)eskimo.com

1 0

Info files problem..
by Kevin A. Foss 28 Jun '97

28 Jun '97

Hiya, I downloaded the new EMX binaries of gpc (970624) and find that I can't get the info files to display: "info -f gpc.inf" yields: info: Cannot find the node "Top". "info -f gpc.i1" shows the menu for the gpc info files but it doesn't find the nodes in the the other gpc.i? files. I know this problem cropped up before, but I couldn't find in a quick fix (that worked) in the archives. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: Severe bug! :-(And some more bugs.)
by Peter Gerwinski 28 Jun '97

28 Jun '97

According to Frank Heckenbach: > > The following program causes an internal compiler error (Linux) or > causes gpc to crash with page fault (DJGPP), sometimes it hangs. Fixed. > Is "Integer(n)" supposed to support bigger types than LongestInt? No. Somebody else may implement that ... ;-) > If not, gpc should give an error if n is too big, It does so, now. > The following program writes 0. ("+" doesn't seem to work correctly with > big integers at all, telling from the asm code.) > > program x; > var a:integer(128); > begin > a:=$FFFFFFFF; > a:=a+1; > writeln(integer(a)) > end. This is correct: "a + 1" gets the integer value $100000000 in this example; the cast to `Integer' yields an (uncatched)-: overflow and the correct value 0 for the lowest 32 bits. > The following program writes "garbage": > > var x:cardinal(8); > begin > x:=31; > writeln(x); > end. `x' gets the correct value, but writeln barfs on `cardinal(8)' types. Working on it. > With this one, gpc says "initializer element is not constant": > > program x; > var a:integer(128) value 0; > begin > end. This was connected with the undetected overflow. (The maximal integer types have 64 bits on the PC). > At least "=" seems to work with these types, which would make "Cardinal(128)" > usable for ClassIDs (I hope)... :-) Sorry to have it taken out again! ;-) > Also, the n in "Integer(n)" seems to be handled modulo 256. > If types >256 bits are not supported, an error should be given. It is now. > Besides, I'm not too sure if "Integer(0)" is reasonable... ;-) It's also catched now. > And now for something completely different... > [...] Working on that. > But apart from these things, a lot of bugs have disappeared! :-) :-) Fein! That's what I hoped for. Thanks for the bug report, and I am glad that there were not much more bugs. This give hope that gpc-2.1 can be released within the next months. Tschuess, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Unsubscribe
by Jonas Ingi Ragnarsson 27 Jun '97

27 Jun '97

Unsubscribe

1 0

Severe bug! :-(And some more bugs.) (Was: GNU Pascal beta version gpc-970624)
by Frank Heckenbach 27 Jun '97

27 Jun '97

As you probably expected, the new "Integer(n)" types have some bugs left, among them a really bad one: The following program causes an internal compiler error (Linux) or causes gpc to crash with page fault (DJGPP), sometimes it hangs. It did even manage to hang Linux, when running in DosEmu!!! That's not easy! )-: unit x; interface type Card8=Cardinal(8); implementation end. Some more bugs with "Integer/Card/Word(n)": Is "Integer(n)" supposed to support bigger types than LongestInt? If not, gpc should give an error if n is too big, otherwise the following things are bugs. The following program writes 0. ("+" doesn't seem to work correctly with big integers at all, telling from the asm code.) program x; var a:integer(128); begin a:=$FFFFFFFF; a:=a+1; writeln(integer(a)) end. The following program writes "garbage": var x:cardinal(8); begin x:=31; writeln(x); end. With this one, gpc says "initializer element is not constant": program x; var a:integer(128) value 0; begin end. At least "=" seems to work with these types, which would make "Cardinal(128)" usable for ClassIDs (I hope)... :-) Also, the n in "Integer(n)" seems to be handled modulo 256. If types >256 bits are not supported, an error should be given. Besides, I'm not too sure if "Integer(0)" is reasonable... ;-) And now for something completely different... Peter Gerwinski wrote: > A new option `--executable-file-name' or (*$executable-file-name="foo"*) Doesn't work if no "program name;" is given, i.e. x.p with "program y;" results in x, but x.p without any "program" results in a.out. > * Subrange types can be packed now: Works "strangely" in some situations. The following gives 8, but replacing "packed 1..6" by "byte" yields 2 (the program with a packed record gives 1, as it should, however). program x; var z:record a:packed 1..6; b:packed 1..6 end; begin writeln(sizeof(z)) end. The following writes "xb" (I'm not completely sure how arrays of char are handled in EP, but I'd expect either "x" or "xbc"): program x; Var x:array[0..64] of Char; Begin x:='abc'; x:='x'; writeln(x) End. But apart from these things, a lot of bugs have disappeared! :-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

New WIN32 binaries uploaded
by Jan-Jaap van der Heijden 25 Jun '97

25 Jun '97

Hello, A new GPC binary distribution, corresponding to GPC-970624 (2.1-beta1) for cygwin32-b18 has been uploaded to: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32 The file to get is: gpc-970624.i386-cygwin32-b18.zip I included the corresponding tools (cygwin.dll, as, ld etc.) and documentation in windows .HLP files. NEWS: 1) You can now build DLL's with GPC. A sample is included. 2) The broken examples work again. GPC related notes: 1) The "winapi" macro is not in the compiler (yet) so you still have to {$define WINAPI(X) asmname X; attribute(stdcall)} 2) "function attributes" get lost in the GPI machanism, so you cannot export them from a unit (or DLL) Cygwin32 related problems: 1) On win95, building a DLL may not work because of garbage in the DLL. A solution (don't laugh!) : defrag the disk and make sure the option "wipe empty diskspace" is checked. 2) Linking against kernel32 *twice* will result in segfaulting apps. the previous alpha-gpc's demos suffered from this. 3) Linking GUI apps gives a harmless message: ld: warning: cannot find entry symbol _WinMainCRTStartup; defaulting to 00401000 There's an `ld' option to suppress this, but I have forgotten it. Things to come: 1) Build the RTS as a DLL --> smaller applications. 2) Switch to mingw32 ?? The programs you build would be faster and not depend on cygwin.dll. 3) Start a web page to publish the latest developments. Happy hacking, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

Hi There
by Bill Currie 25 Jun '97

25 Jun '97

Just a few questions: Is this the list for general discussion of gpc? How do I subscribe? Is there a faq? (other than the djgpp faq) TIA Bill -- Leave others their otherness. -- Leave others their otherness.

1 0

Re: Hi There
by Peter Gerwinski 25 Jun '97

25 Jun '97

According to Bill Currie: > > Is this the list for general discussion of gpc? Yes. > Is there a faq? (other than the djgpp faq) Yes: http://home.pages.de/~GNU-Pascal/gpc-faq.html ftp://kampi.hut.fi/jtv/gnu-pascal/FAQ > How do I subscribe? That's in the FAQ: Write e-mail to gpc-request(a)hut.fi. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Word types...
by Frank Heckenbach 24 Jun '97

24 Jun '97

Christian Wendt wrote: > :-) > you could start BP IDE, type COMP and hit Strg-F1 ... :-) > In BP Comp is a FPU Type - it uses the FPU... Yes, I know that, but neither the online help nor the manuals (now I did look it up) say something about the name "Comp"... > (i think technically it's a > 73 Bit BCD packed integer; -> 18 (decimal) Digits + sign ) No, it's a signed 64 bit integer. It's just handled by the FPU, therefore BP handles it as a real type (a dubious decision, IMHO)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Bug report
by C.WENDT＠CHATEAU.line.org 24 Jun '97

24 Jun '97

Am 24.06.97 konnte ich meine Finger einfach nicht von der Tastatur fernhalten... Folgendes kam dabei heraus: Hallo Gpc! Look at the source: program Bug; type tvect=record x,y,z:real; end; operator + (a,b:tVect) r:tVect; begin r.x:=a.x+b.x; r.y:=a.y+b.y; r.z:=a.z+b.z; end; {BTW - here it warns "return value not assigned" - GCC relict?} type tNotOK=array[1..5] of tvect; (* tIsOk=array[1..5] of record p:tvect end;*) var a,b:tvect; prob:tNotOk; r:tvect; begin r:=a+b; {works fine} r:=b+prob[1]; {doesn't :-(} a:=prob[1];r:=a+b; {Does} end. Chris --- HomeBox : Chateau - +49(0)8677 911940(V.34) 911941(ISDN) *! New Address - C.Wendt(a)chateau.line.org !* ## CrossPoint v3.11 ##

1 0

Re: Word types...
by Frank Heckenbach 23 Jun '97

23 Jun '97

The African Chief wrote: > long longint {now = integer} > unsigned long longword {now = word} The problem with this one is that (at least on the common platforms), "long" is the same as "int", and I'd expect (as probably many ex-BP programmers do) LongInt to be longer than Integer. In fact, some of my programs rely on this. > long long comp {now = longint, or comp} > unsigned long long compword (now = longword} Why "Comp"? What does "Comp" mean at all? -- I really don't know, perhaps I could look it up in one of the 11 BP books... :-| However, I don't think "Comp" is reasonable name for any integer type, except for BP compatibility ("Comp" = "compatibility type" ;-). > However, since the above will most likely break a lot of existing > code, perhaps GPC should have built-in data types that mean > *exactly* the same thing as they mean in GCC Seems necessary. (I didn't like how C messed up their integer types, now we're getting the same problems... :-( -- I hope we find a good solution finally!) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

Re: :-) ARRAYS BUG; preparing next GPC ...
by Peter Gerwinski 22 Jun '97

22 Jun '97

According to Bernhard Tschirren: > > Its high time you release another alpha! I have GPC970510, the latest > release. My GPC does NOT compile A^[(I)]?!? It aborts with the following > error messages: [...] Ah - I see. gpc-970510 misinterpretes `^[' as a control character. It is already fixed in my current development version. Sorry, I should have checked it with gpc-970510 before replying ... #-) To work around this, insert a blank between the `^' and the `['. > So, when is the next release coming? :-) Either as soon as I have fixed all pending bugs and I find a day without new bug reports, or else when I give up fixing them. ;-) Seriously, I am now putting in the Integer types discussed during the last days, and I have two pending bugs: casts of structured types and duplicate field identifieres. In addition, due to major changes in the structure of GPC's source, there are some problems with DJGPP and EMX we must solve before the release. :-( Everything else planned for the first post-2.0 GPC beta release is finished now. :-) Thanks for your patience, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: :-) ARRAYS BUG
by Bernhard Tschirren 22 Jun '97

22 Jun '97

>Where is the bug??? My version of GPC compiles it. > >In case you think that `A^[(I)]' would be illegal: It isn't. :-) >`(I)' is an expression in parentheses which means the same as just `I'. > Its high time you release another alpha! I have GPC970510, the latest release. My GPC does NOT compile A^[(I)]?!? It aborts with the following error messages: bug01.pas: In function `program_Funnybug': bug01.pas:14: warning: expression used as a statement - value is ignored bug01.pas:14: parse error before `^' bug01.pas:14: missing semicolon bug01.pas:14: warning: expression used as a statement - value is ignored bug01.pas:14: missing semicolon bug01.pas:14: missing semicolon bug01.pas:14: missing semicolon bug01.pas:14: missing semicolon STRANGE! So, when is the next release coming? :-) Cya L8r ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Word types...
by Peter Gerwinski 22 Jun '97

22 Jun '97

According to Frank Heckenbach: > > And something I just noticed concerning "Word" (this is addressed more > to Peter ;-) : > > A "machine word" in the sense of assembly language actually describes > the *size* of data and not whether it's signed or unsigned, doesn't it? > (Data in asm are neither signed nor unsigned per se, it depends on which > operations are used on them.) So from the original meaning (in PC real > mode) "Word = 16 bits", Borland made "Word = 16 bits unsigned", and now > you seem to be making "Word = unsigned" out of it... Now you have got me! (-: Okay, so GPC will have `FooInt' for signed, `FooCard' for unsigned integer types, and `FooWord' for types where we don't care about signedness (and which are in fact unsigned). These are many Integer types for GPC - much more than in BP. So let's hope that this will lead to clear programming, not to confusion ... Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: :-) ARRAYS BUG
by Peter Gerwinski 22 Jun '97

22 Jun '97

According to Bernhard Tschirren: > > This is the -best- bug that I have ever found! :-) Take a look at the code > below... > > Program > FunnyBug; > Type > PArray = ^TArray; > TArray = Array[0..255] Of Integer; > Var > I : Integer; > A : PArray; > Begin > New(A); > For I := 0 To 255 Do > Begin > A^[I] := 10; > A^[(I)] := 10; { :-) } > End; > Dispose(A); > End. > > Hehehe. I LOVE GPC's parser... > > Good Luck Where is the bug??? My version of GPC compiles it. In case you think that `A^[(I)]' would be illegal: It isn't. :-) `(I)' is an expression in parentheses which means the same as just `I'. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Ignoring function return values
by Frank Heckenbach 21 Jun '97

21 Jun '97

Peter Gerwinski wrote: > Perhaps `--ignore-function-return'? or `--ignore-function-results'? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Word types: Suggestion
by Frank Heckenbach 21 Jun '97

21 Jun '97

Peter Gerwinski wrote: > Discussion of #1: Compatibility to BP. > > - GPC is *not* intended to be a drop-in replacement for BP. > Compatibility is desireable as long as we don't have to pay a high > price for it. We want to preserve the "spirit" of BP in GPC, not > its "letters". What we do is to "write BP, as it should have been", > not "rewrite BP, exactly as it is". > > - GPC is a 32-bit compiler. Maybe we will extend it to 64 bits, some day, > but we won't restrict it to 16 bits. > > That's why `Word' etc. are as they are, and why I think they should > not change. Agreed. And if someone wants to redeclare them for "100% silver plate compatibility", this is no problem to do. (Like in the Chief's system unit with -D_Borland_16_Bit_.) The only question is if *in*this*special*case* also Integer should be redeclared to 16 bits. (I know this is quite unusual, but since this mode is *only* for using existing BP programs without (ideally any) changes, these programs are likely to expect integer to be 16 bit.) > Round parentheses are easiest to implement, but their syntax interferes > with Schemata. Would this a problem? It's very unlikely that someone would declare a schema called "Integer", isn't it? Such an "Integer(n)" could be a special built-in schema (special in that the "n" is not stored in the variable). > Square brackets come into mind, but they interfere with > UCSD's "long integers". <off-topic> Are these UCSD "long integers" of arbitrary size, or limited to subtypes of regular integer types? </off-topic> > While the remaining two possibilities are certainly the most `Pascalish' > ones, they are not 100% clear: What size has `packed $1000..$10FF'? > Although 8 bits would be sufficient, GPC would allocate 13 bits. This is a strange case, indeed! How are they handled currently in packed record. Testing seems to show to it's 13 bits in fact. (* The results are a bit strange. The following program gives "1299" !?! program x; type y=packed array [1..800] of $1000..$10ff; begin writeln(sizeof(y)) end. *) I think it's ok like this. After all, if it's really for a system call or so, what sense would it make to interpret the values as $10xy if they were only stored as $xy? As a rule, one might say that the internal representation of a subrange always includes 0. > Outside > of packed arrays and records, they would be rounded to the next unit the > machine can access, usually 8 bits, but it can also be 16 or 32 bits. Can not all machines address 1 byte? I.e., is "Byte" on some machines bigger than 1 byte (internally)? This gives real problems with binary files, doesn't it? How do such machines read single bytes from files at all? > Despite of the disadvantage sketched above, I think that `packed 0..$FF' > is the way to go. Authors of libraries are encouraged to define their own > types using this mechanism. > > To have `LongestInt' as - currently - a synonym for `LongInt' cannot > hurt. If one day there will be something longer than `LongInt', we > can name it `LongLongInt' (because it might be superseeded again by > `LongLongLongInt'), but `LongestInt' will always remain the longest one. Fine! :-) > Discussion of #3: Compatibility to GCC. > > I can guarantee that the above GPC <--> GCC compatibility rules for > `ShortInt' etc. will not change. Then the only needed thing is something > which is guaranteed to be the same as `long' in GCC, even if `int' is > not the same as `long'. Since we are aiming towards the top, C's `long' > is just "medium" for us. ;-) Thus I propose the names `MedInt' and > `MedWord'. Why not! If it's documented, headers should be "easy" to convert then! > Summary and Proposal: > > Let all GPC integer types like they are, and add `MedFoo' and > `LongestFoo': If you don't mind, please also add {Short,Med,Long,Longest}Card[inal]. > Okay like this? Or better keep `Integer ( 8 )' (or `Integer < 8 >', Why not, additionally! ("Integer(n)" is easier to read than "Packed 0..1 shl n-1".) > or `Integer : 8' like bit-fields in C, "a:Integer:8" would look strange to me. > or `Integer * 1' like in FORTRAN?) Would also look strange to me. "Integer * 2" I would understand as "twice the size of an integer", if at all... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

:-) ARRAYS BUG
by Bernhard Tschirren 21 Jun '97

21 Jun '97

This is the -best- bug that I have ever found! :-) Take a look at the code below... Program FunnyBug; Type PArray = ^TArray; TArray = Array[0..255] Of Integer; Var I : Integer; A : PArray; Begin New(A); For I := 0 To 255 Do Begin A^[I] := 10; A^[(I)] := 10; { :-) } End; Dispose(A); End. Hehehe. I LOVE GPC's parser... Good Luck ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Initialized record fields
by Peter Gerwinski 21 Jun '97

21 Jun '97

According to A.A. Olowofoyeku: > > [...] I *need* to be able to do > something like; > > Type r = record > foo : integer value 24; > bar : char value 'B'; > end; The syntax Type R = record foo: Integer; bar: char; end (* R *) value ( foo: 24; bar : 'B' ); is intended to yield what you expect. But it seems to be broken at the moment, so please be patient ... Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Word types...
by Frank Heckenbach 21 Jun '97

21 Jun '97

The African Chief wrote: > >The problem with this one is that (at least on the common platforms), > >"long" is the same as "int", and I'd expect (as probably many ex-BP > >programmers do) LongInt to be longer than Integer. In fact, some of my > >programs rely on this. > > Yes. But in BP, "integer" is 16-bit and "longint" is 32-bit. > Surely, if your programs rely on "longint" to be bigger than > "integer", they also expect "integer" to be 16-bit? Not necessarily. > If GCC's > "long" is 32-bit and GPC's "longint" is 64-bit - what does that > say about compatibility of data structures? E.g., that LongIntVar=LongInt(IntVar)*IntVar works always without overflowing, or that you can type cast a LongInt into a record of two Integers. > This is from the BPW help file; > > "Note: The comp type is a 64-bit integer. It holds only integral > values within the range (-2 63 + 1) to (2 63 - 1)." I know that (except that I think it should be -2^63, not "+1"). What I don't understand is the strange name "Comp" -- which I still can't make any sense of in connection with integer data types. And something I just noticed concerning "Word" (this is addressed more to Peter ;-) : A "machine word" in the sense of assembly language actually describes the *size* of data and not whether it's signed or unsigned, doesn't it? (Data in asm are neither signed nor unsigned per se, it depends on which operations are used on them.) So from the original meaning (in PC real mode) "Word = 16 bits", Borland made "Word = 16 bits unsigned", and now you seem to be making "Word = unsigned" out of it... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Interrupts (was: system.pas)
by PredatorZeta 21 Jun '97

21 Jun '97

Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: > According to Frank Heckenbach: > > > > I declared all eax, ebx, ecx, edx, esi and edi as clobbered. Do I need more? > > (ebp? What about segment registers, anyway?) > > I think if you include `ebp' you are safe. However you should better > look up the register usage from a suitable book whenever you invoke a > certain interrupt. This improves performance. TAKE CARE!!! If you don't use -fomit-frame-pointer your code DON'T WORK!!! This because EBP is always used as stack pointer, also if you declare this as clobbered: then if you modify EBP your local variable offsets is WrOnG!! Btw ES, DS, GS, FS, SS cannot be restored by the compiler. You must do this from yourself..... Cya PrZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Re: Initialized record fields
by Peter Gerwinski 21 Jun '97

21 Jun '97

According to The African Chief: > > It seems that one cannot have record fields pre-initialised to > certain values (or am I missing something?) [...] True. I agree that initalized record fields would be nice. (What does The Standard say about this, BTW?) However you can initialize the whole record, like type constants in BP ... testing it ... uh - sorry, it does not work in fact! :-( The following should work: Var R: record foo: Integer; bar: Char; end (* R *) value ( foo: 42; bar: 'G' ); or, alternatively Var R: record foo: Integer; bar: Char; end (* R *) value ( 42, 'G' ); Thanks for the bug report! Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Ignoring function return values (was: system.pas)
by Peter Gerwinski 20 Jun '97

20 Jun '97

According to Frank Heckenbach: > According to myself (Peter Gerwinski): > > Ignoring a function's return value *is* a risky thing, because it > > switches off an error-checking rule which is important for teaching. > > [...] > > I'd still feel better with a separate switch because I try to avoid pointer > arithmetic and such things in all but low level or very time critical code, > but I usually have to ignore some function results. Perhaps `--ignore-function-return'? > (Perhaps with function > overloading, this can be solved cleanly -- could it be possible then to have > a function and a procedure with the same parameters???) It would be difficult to implement. Having the separate switch, I think it's not worth the effort. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Interrupts (was: system.pas)
by Peter Gerwinski 20 Jun '97

20 Jun '97

According to Frank Heckenbach: > > I declared all eax, ebx, ecx, edx, esi and edi as clobbered. Do I need more? > (ebp? What about segment registers, anyway?) I think if you include `ebp' you are safe. However you should better look up the register usage from a suitable book whenever you invoke a certain interrupt. This improves performance. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Word types: Suggestion
by Peter Gerwinski 20 Jun '97

20 Jun '97

Hello, everybody! I am trying now to summarize our "Integer type" problems and to propose a solution. Problem #1: Compatibility to BP. - Some people want `Word' to have 16 bits, because it has in BP. - Some other people want `Word' to have the same size as `Integer', because it has in BP. - Some people expect `LongInt' to have 32 bits, like in BP. - Some other people expect `LongInt' to be bigger than `Integer', like in BP. Hard to escape! Problem #2: Data types with known size. Here everybody seems to agree that they are needed, discussions are about how they should be named. - `int8' and `card8' - `int8' and `word8' - `Integer ( 8 )' and `Cardinal ( 8 )' and/or `Word ( 8 )' - `0..$FF' (always) - `packed 0..$FF' There is also need for a data type which is guaranteed to be the largest signed/unsigned Integer type available. Problem #3: Compatibility to GCC. In order to access libraries written in GCC, GPC must provide integer types which are guaranteed to be the same as `long long unsigned int' etc. in GCC. - Current implementation: GPC GCC ByteInt Byte signed char unsigned char ShortInt ShortWord short unsigned short Integer Word int unsigned LongInt = Comp LongWord long long unsigned long long Obviously, an equivalent for GCC's `[unsigned] long' is missing. This is because it's the same as `[unsigned] int'. If we can make sure that this will always be the case, we can safely leave things like they are and document them (which I already did: see "info -f gpc -n Integer"). - Some people propose to change `LongInt' to be the same as GCC's `long'. Advantage: closer to GCC's syntax, and same bit size as BP's `LongInt'. Disadvantage: `LongInt' would not be longer than `Integer'. - While we are discussing all this, GPC already has type modifiers: `__long__ Integer' means the same as `long' in GCC. So there *is* a mechanism with syntax close to C which guarantees compatibility. (* If we were Borland, we would probably say now: "On all currently existing platforms, GCC's `long' is the same as `int', so don't worry about the missing equivalent for `long'." *) Discussion of #1: Compatibility to BP. - GPC is *not* intended to be a drop-in replacement for BP. Compatibility is desireable as long as we don't have to pay a high price for it. We want to preserve the "spirit" of BP in GPC, not its "letters". What we do is to "write BP, as it should have been", not "rewrite BP, exactly as it is". - GPC is a 32-bit compiler. Maybe we will extend it to 64 bits, some day, but we won't restrict it to 16 bits. That's why `Word' etc. are as they are, and why I think they should not change. Discussion of #2: Data types with known size. I think, Frank is right when he says that we must provide a way to define them rather than defining everything in GPC. Separate identifiers for everything are not flexible enough. Round parentheses are easiest to implement, but their syntax interferes with Schemata. Square brackets come into mind, but they interfere with UCSD's "long integers". While the remaining two possibilities are certainly the most `Pascalish' ones, they are not 100% clear: What size has `packed $1000..$10FF'? Although 8 bits would be sufficient, GPC would allocate 13 bits. Outside of packed arrays and records, they would be rounded to the next unit the machine can access, usually 8 bits, but it can also be 16 or 32 bits. Despite of the disadvantage sketched above, I think that `packed 0..$FF' is the way to go. Authors of libraries are encouraged to define their own types using this mechanism. To have `LongestInt' as - currently - a synonym for `LongInt' cannot hurt. If one day there will be something longer than `LongInt', we can name it `LongLongInt' (because it might be superseeded again by `LongLongLongInt'), but `LongestInt' will always remain the longest one. Discussion of #3: Compatibility to GCC. I can guarantee that the above GPC <--> GCC compatibility rules for `ShortInt' etc. will not change. Then the only needed thing is something which is guaranteed to be the same as `long' in GCC, even if `int' is not the same as `long'. Since we are aiming towards the top, C's `long' is just "medium" for us. ;-) Thus I propose the names `MedInt' and `MedWord'. Summary and Proposal: Let all GPC integer types like they are, and add `MedFoo' and `LongestFoo': GPC GCC ByteInt Byte signed char unsigned char ShortInt ShortWord short unsigned short Integer Word int unsigned MedInt MedWord long unsigned long LongInt = Comp LongWord long long unsigned long long LongestInt LongestWord long long unsigned long long where `MedInt' happens to be the same as `Integer' and `MedWord' the same as `Word' on all platforms currently existing. Introduce `packed 0..$FF' like discussed above. Forget about `Integer ( 8 )'. But don't forget about UCSD's `Integer [ 42 ]' which might be implemented later. Okay like this? Or better keep `Integer ( 8 )' (or `Integer < 8 >', or `Integer : 8' like bit-fields in C, or `Integer * 1' like in FORTRAN?) which shows more explicitly how many bits a type has? Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Word types...
by The African Chief 20 Jun '97

20 Jun '97

On Fri, 20 Jun 1997 15:49:30 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> long longint {now = integer} >> unsigned long longword {now = word} > >The problem with this one is that (at least on the common platforms), >"long" is the same as "int", and I'd expect (as probably many ex-BP >programmers do) LongInt to be longer than Integer. In fact, some of my >programs rely on this. Yes. But in BP, "integer" is 16-bit and "longint" is 32-bit. Surely, if your programs rely on "longint" to be bigger than "integer", they also expect "integer" to be 16-bit? If GCC's "long" is 32-bit and GPC's "longint" is 64-bit - what does that say about compatibility of data structures? > >> long long comp {now = longint, or comp} >> unsigned long long compword (now = longword} > >Why "Comp"? What does "Comp" mean at all? -- I really don't know, >perhaps I could look it up in one of the 11 BP books... :-| > >However, I don't think "Comp" is reasonable name for any integer >type, except for BP compatibility ("Comp" = "compatibility type" ;-). This is from the BPW help file; "Note: The comp type is a 64-bit integer. It holds only integral values within the range (-2 63 + 1) to (2 63 - 1)." >> However, since the above will most likely break a lot of existing >> code, perhaps GPC should have built-in data types that mean >> *exactly* the same thing as they mean in GCC > >Seems necessary. (I didn't like how C messed up their integer types, >now we're getting the same problems... :-( -- I hope we find a good >solution finally!) So do I. The solution may be to predefine these types in GPC; "int", "short", "long", "uint", "ulong", "ushort", "longlong", "dword", etc. These could be defined to mean exactly the same thing as they mean in GCC - thus, there will be no need to "translate" them into Pascal. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Word types...
by Frank Heckenbach 20 Jun '97

20 Jun '97

Peter Gerwinski wrote: > Where do such data types matter? Everywhere where we must set up a record > type of well-known size and structure, for example when reading a binary > file created by some other program, (* Not necessarily by another program. If the file can get big, I'd want to choose the smallest possible types, anyway. *) > or when communicating with the operating > system. > > For this reason, the syntax must be compact, and somehow closer to the bare > metal (assembler) than to the clouds (Modula). That's why I prefer `Word' > here with respect to `Cardinal'. (* Another reason is that when I read > `Card', I think of games, not of cardinalship. ;*) (* And when I read "Word", I think of other things, too... *) > (Due to the need for > compactness, I think my "Integer ( 8 )" notation was not the best idea. Or > perhaps it was, and the programmer can define the below in his own Units?) > So what about this? > > Int8 Word8 = Byte > Int16 Word16 > Int32 Word32 > Int64 Word64 If everyone can define these types, we don't have to determine it here. You can declare "Word<n>" in your units, and I'll probably declare "Card<n>" or perhaps "Cardinal<n>" in mine... > Once more discussing subranges as an alternative: "True Pascal" does not > specify the storage size, but valid values for those. So I am no more sure > whether it is wise to guarantee that their size will always be the minimal > one. And anyway, they are no true replacement for built-in data types of > well-defined size because no programmer will write `0..$FF' everytime he > wants to express that something has 8 bits. He will define his own type > for this reason: "Type Byte = 0..$FF". (Note that `Byte' is built-in in > GPC!) If we don't want terrible confusion among future GPC hackers, we > should provide built-in types for such purposes. But you can't predefine anything that might be needed by someone. Perhaps someone needs a type with the range 0..1234 that occupies 2 bytes... So I'd prefer to have a way to define it by oneself. To me, the "packed" still seems the most logical thing to do: without "packed", the data are optimized for speed, with "packed" for size. So it would "only" be necessary to extend "packed" to any type (and I don't see any inherent reason why it should apply only to records and arrays). -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: system.pas
by Frank Heckenbach 20 Jun '97

20 Jun '97

Peter Gerwinski wrote: > What about `__BORLAND_PASCAL__' and `__DELPHI__' (and `__EXTENDED_PASCAL__' > and `__STANDARD_PASCAL__' etc. which are of course useless because these > dialects don't allow conditional defines anyway;-)? Sounds good! :-) > Everybody, PLEASE check what GPC can already do and what it cannot BEFORE > you post to this list. You are confusing possible GPC newcomers! ;-) Sorry for that! (When I wrote the mail, I was at university, and of course, they haven't installed gpc there...)-: > > Perhaps (additionally) a separate switch for those who want to use > > functions as procedures, but without the "risks" implied by "{$X+}" > > in other aspects? I guess, most of my units would use such a switch. > > Ignoring a function's return value *is* a risky thing, because it > switches off an error-checking rule which is important for teaching. > Programmers who want to use this feature usually (should;-) know what > they are doing, and won't be hit by the other "risky" things. For > instance: A beginner might unintentionally increment a pointer instead > of the value pointed to. An expert probably won't - he produces much > uglier bugs. No, when I want to produce ugly bugs, I write in C or Asm -- it's so much easier there... ;-) I'd still feel better with a separate switch because I try to avoid pointer arithmetic and such things in all but low level or very time critical code, but I usually have to ignore some function results. (Perhaps with function overloading, this can be solved cleanly -- could it be possible then to have a function and a procedure with the same parameters???) > > - Is calling the Dos interrupt like I did it ok, or is there a better way > > (perhaps some DPMI calls > > Praxis has shown for me that interrupts which don't pass pointers work > without any DPMI magic. But take care of clobbered registers! I declared all eax, ebx, ecx, edx, esi and edi as clobbered. Do I need more? (ebp? What about segment registers, anyway?) > > -- perhaps even without any asm, that would be better). > > No. This would be *very* system-dependent, so it should not be a GPC > built-in. No, not built-in of course! I thought of the __dpmi* functions declared in dpmi.h (at least with DJGPP). I had hoped someone had already figured out how to use them in gpc... -- So I tried it myself, it seems to work on my DJGPP (code below). Could someone please check if the code "looks" ok, and if it works on an EMX system? BTW: Chief, I think your version of __dpmi_regs in dpmi.pas (v1.00) has a little mistake, because a "union" in C is a variant record in Pascal. I think I found a bug with variant records, namely that gpc allows duplicate identifiers in different "cases". I think the following program should either fail to compile (what I'd expect), or write "MaxCard"-1 (but that would be quite difficult to do in general). It does write -1. var x:record case d:integer of 1:(a:cardinal); 2:(a:integer) end; begin x.d:=2; x.a:=-1; x.d:=1; writeln(x.a) end. > > Would it seem reasonable (and feasible) to propagate defines > > (either all of them, or only those that are specially marked) through > > .gpi files? > > No. Defines are C. We do Pascal. True. Ok, for now we can help with "-Drandom=RandReal" on the command line, and later we'll make an overloaded function out of it... :-) UNIT Rand; INTERFACE TYPE Card8=Byte; Card16=ShortWord; Card32=Cardinal; Card64=LongWord; Int32=Integer; VAR RandSeed:Int32 VALUE 0; FUNCTION Random(Range:Card16):Card16; FUNCTION RandReal:Real; PROCEDURE Randomize; IMPLEMENTATION {$W-,R-,W+} PROCEDURE NextRand; BEGIN RandSeed:=$8088405*RandSeed+1 END; FUNCTION Random(Range:Card16):Card16; BEGIN NextRand; Random:=(Card32(RandSeed)*Card64(Range)) DIV $100000000 END; FUNCTION RandReal:Real; BEGIN NextRand; RandReal:=RandSeed/4294967296.0+0.5 END; {$IFDEF __DJGPP__}{$DEFINE DOS}{$ENDIF} {$IFDEF __EMX__}{$DEFINE DOS}{$ENDIF} {$IFDEF DOS} TYPE PDPMIRegs=^TDPMIRegs; TDPMIRegs=RECORD CASE (d,x,h) OF d:(edi,esi,ebp,res,ebx,edx,ecx,eax:Card32); x:(di,di_hi,si,si_hi,bp,bp_hi,res_lo,res_hi,bx,bx_hi,dx,dx_hi, cx,cx_hi,ax,ax_hi,flags,es,ds,fs,gs,ip,cs,sp,ss:Card16); h:(edi_b,esi_b,ebp_b,res_b:ARRAY[0..3] OF Card8; bl,bh,ebx_b2,ebx_b3, dl,dh,edx_b2,edx_b3, cl,ch,ecx_b2,ecx_b3, al,ah,eax_b2,eax_b3:Card8) END; {$W-} FUNCTION __DPMI_Simulate_Real_Mode_Interrupt(Vector:Integer;VAR Regs:TDPMIRegs):Integer; C; {$W+} PROCEDURE Randomize; VAR RandSeedLoHi:PACKED RECORD Lo,Hi:Card16 END ABSOLUTE RandSeed; DPMIRegs:TDPMIRegs; BEGIN DPMIRegs.ah:=$2C; {$X+} __DPMI_Simulate_Real_Mode_Interrupt($21,DPMIRegs); {$X-} RandSeedLoHi.Lo:=DPMIRegs.cx; RandSeedLoHi.Hi:=DPMIRegs.dx END; {$ELSE} FUNCTION Rand:Integer; C; PROCEDURE SRand(Seed:Cardinal); C; FUNCTION GetPID:Integer; C; PROCEDURE Randomize; BEGIN SRand(GetPID); RandSeed:=Rand END; {$ENDIF} END. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Word types...
by The African Chief 20 Jun '97

20 Jun '97

On Fri, 20 Jun 1997 01:08:29 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: [...] > Int8 Word8 = Byte > Int16 Word16 > Int32 Word32 > Int64 Word64 I would vote for this. [...] >The other thing we must worry about is compatibility to GNU C, because >the use of GNU Pascal depends on library written in GNU C. For this reason, >`ShortInt', `ShortWord', `ByteInt', and `Byte' must stay like they are; >I think it's quite natural then to have `Word' for an unsigned 32-bit Integer. >I am not sure whether `int' in GNU C might ever change to be different from >`long int'. (DOES SOMEBODY KNOW???) If so, our (my;) choice for the meaning >of `LongInt' and `LongWord' might be subject to change. (Note again that >I am speaking about types that *are* built-in in GPC with the mentioned >meanings.) Frankly speaking, I find the dissimilarities between GPC and GCC very confusing, and, at times, frustrating. Since GPC depends on GCC, shouldn't the data structures be the same? For example, "long" in GCC means "integer" in GPC, but "int" also means "integer". "Longint" in GPC is not the same as GCC's "long", which would seem to be the sensible thing - but rather, it is the same as GCC's "long long". "Word" seems to be 32-bit in GCC (am I right?), but with the cygwin32 port of GPC, "word" sometimes seems to be 16-bit, and sometimes, 32-bit (judging from all my attempts at wading through the thousands of lines of cygwin32 C headers - again, perhaps I am missing something, but at least, I get very confused at times). It very soon becomes a very difficult, or, at best, quite error-prone, task, to translate these C headers for use with GPC. In my ideal world, GPC and GCC data types would follow this logical course; GCC GPC int integer short shortint word word, cardinal unsigned int word, cardinal unsigned short shortword long longint {now = integer} unsigned long longword {now = word} long long comp {now = longint, or comp} unsigned long long compword (now = longword} This is perhaps only useful for easier translation of the GCC headers and therefore may not be a priority - however, I don't think we will ever stop translating those C headers. However, since the above will most likely break a lot of existing code, perhaps GPC should have built-in data types that mean *exactly* the same thing as they mean in GCC - e.g., "int", "long", "short", etc (in addition to "integer", "longint", "shortint", etc). This will certainly help in translating a lot of those .H files. Any thoughts on these things? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Initialised record fields
by The African Chief 20 Jun '97

20 Jun '97

Hi all, It seems that one cannot have record fields pre-initialised to certain values (or am I missing something?) - see the code below. It would be useful to be able to do this in GPC, otherwise, it would be hard or impossible to translate many C structures (some of which are declared with fields initialised certain values) to Pascal (this makes it impossible to translate the whole of the cygwin32 structures.h for example). Is it possible to add support for this to GPC? Thanks! Below is my test program which does not work .... program testfoo; Type foo = record a : integer value -3; { error here } b : word value 600; { ditto } end; Procedure foobar ( var f : foo ); begin with f do begin writeln ( a ); writeln ( b ); end; end; Var bar : foo; begin with bar do begin a := -200; b := 0; end; foobar ( bar ); end. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Bug with text files
by Frank Heckenbach 20 Jun '97

20 Jun '97

The following works as a program, but not as a unit (used e.g. by an empty program). It gives the following runtime message (DJGPP and Linux): ?GPC runtime error: (gpc-rts) _p_initfdr() has not been called for file (#701) {$define u} {$IFDEF u} UNIT printer; INTERFACE {$ENDIF} USES System; VAR Lst:Text; {$IFDEF u} IMPLEMENTATION TO BEGIN DO {$ENDIF} BEGIN Assign(Lst,'LPR'); Rewrite(Lst); writeln(Lst,'Test'); Close(Lst) {$IFDEF u} END; {$ENDIF} END. Apropos: Did anyone write a portable printer unit yet? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Word types...
by Peter Gerwinski 19 Jun '97

19 Jun '97

According to Orlando Llanes: > > The only reason I suggested having Platform specific types is because > since the size varies per system, and you save a file using natural types > on one, they have to be read in using the same size. For example, let's say > a Word is 32-bit on one system, and then you have the PC where it's 16-bit, > let's call them Word (32-bit) and PCWord (16-bit). The natural size of a Word on the PC equipped with a 80386 or higher is 32-bit. The restriction of most applications to 16 bits is an artificial one and orginates to Microsoft which did not react on the hardware improvement. We do. > Word is 4 bytes, PCWord is 2 bytes. If data was written using PCWord, it > could be read into a Word. But if a Word was written, then it needs 2 > PCWords to read it properly. In this way, it's not cross platform because > you have to make adjustments per platform. So what you are really worrying about is the binary format (which includes the size) of these types, not the platform where they are "natural". I agree. This means that the following is the way to go: > I'm all for the IntX data types > suggested earlier for this reason, if one data type is treated the same > across all platforms, then all you have to do is write a program once, and > then compile it across all platforms without having to use platform > specific compiler options. [...] So it's clear what has to be implemented. Now we must discuss about their syntax. Where do such data types matter? Everywhere where we must set up a record type of well-known size and structure, for example when reading a binary file created by some other program, or when communicating with the operating system. For this reason, the syntax must be compact, and somehow closer to the bare metal (assembler) than to the clouds (Modula). That's why I prefer `Word' here with respect to `Cardinal'. (* Another reason is that when I read `Card', I think of games, not of cardinalship. ;*) (Due to the need for compactness, I think my "Integer ( 8 )" notation was not the best idea. Or perhaps it was, and the programmer can define the below in his own Units?) So what about this? Int8 Word8 = Byte Int16 Word16 Int32 Word32 Int64 Word64 Once more discussing subranges as an alternative: "True Pascal" does not specify the storage size, but valid values for those. So I am no more sure whether it is wise to guarantee that their size will always be the minimal one. And anyway, they are no true replacement for built-in data types of well-defined size because no programmer will write `0..$FF' everytime he wants to express that something has 8 bits. He will define his own type for this reason: "Type Byte = 0..$FF". (Note that `Byte' is built-in in GPC!) If we don't want terrible confusion among future GPC hackers, we should provide built-in types for such purposes. The other thing we must worry about is compatibility to GNU C, because the use of GNU Pascal depends on library written in GNU C. For this reason, `ShortInt', `ShortWord', `ByteInt', and `Byte' must stay like they are; I think it's quite natural then to have `Word' for an unsigned 32-bit Integer. I am not sure whether `int' in GNU C might ever change to be different from `long int'. (DOES SOMEBODY KNOW???) If so, our (my;) choice for the meaning of `LongInt' and `LongWord' might be subject to change. (Note again that I am speaking about types that *are* built-in in GPC with the mentioned meanings.) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: system.pas
by Peter Gerwinski 19 Jun '97

19 Jun '97

According to Frank Heckenbach: > According to The African Chief: > > According to Frank Heckenbach: > > > > > > (Is there a way to test in a program, if "--borland-pascal" or > > > "--delphi" was given?) > > > > I know of none. > > If there isn't, could you make one, Peter? (Perhaps just some > predefined symbols?) What about `__BORLAND_PASCAL__' and `__DELPHI__' (and `__EXTENDED_PASCAL__' and `__STANDARD_PASCAL__' etc. which are of course useless because these dialects don't allow conditional defines anyway;-)? > > True enough. In BP, when {$X+} is used, you can use functions just > > like procedures. Perhaps Peter can add this to GPC as well, so that > > no warning is generated in such instances? If this happens, then we > > don't need to turn off warnings. This was one of the very first things I did to GPC. It was in version 1.1-turbo-alpha-1.0, aka turbo-gpc-2.6.3.tar.gz, aka turbo11b.zip. Everybody, PLEASE check what GPC can already do and what it cannot BEFORE you post to this list. You are confusing possible GPC newcomers! ;-) > Perhaps (additionally) a separate switch for those who want to use > functions as procedures, but without the "risks" implied by "{$X+}" > in other aspects? I guess, most of my units would use such a switch. Ignoring a function's return value *is* a risky thing, because it switches off an error-checking rule which is important for teaching. Programmers who want to use this feature usually (should;-) know what they are doing, and won't be hit by the other "risky" things. For instance: A beginner might unintentionally increment a pointer instead of the value pointed to. An expert probably won't - he produces much uglier bugs. > So I'm asking the asm experts here: I am not an asm expert, but here are my guesses. > - First, the asm syntax -- can it change, or will it always work like that? It won't change. To much GCC stuff depends on the asm syntax as it is now, and GPC will stay compatible to GCC. Maybe, somebody will implement an alternative Borland-compatible asm syntax, but this will be an extension. (And, since I now know the advantages of GPC's asm syntax, I won't even vote for doing that.) > - Could using 8 and 16 bit registers ever be a problem (note: that's only > for __DJGPP__ and __EMX__)? No. (Note: That's only for iX86-platforms.) > - Is calling the Dos interrupt like I did it ok, or is there a better way > (perhaps some DPMI calls Praxis has shown for me that interrupts which don't pass pointers work without any DPMI magic. But take care of clobbered registers! > -- perhaps even without any asm, that would be better). No. This would be *very* system-dependent, so it should not be a GPC built-in. > > > As a preliminary solution for the overloading problem, one could use > The only way to do it (AFAICS) are include files, or defines on the command > line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to > work?) It does work. > Would it seem reasonable (and feasible) to propagate defines > (either all of them, or only those that are specially marked) through > .gpi files? No. Defines are C. We do Pascal. However, it would be desireable to allow inline functions transported through GPI files which have the same functionality (including translating C macros) but are *much* cleaner. To achieve this, somebody would have to extend my `store_tree()' (in `gpc-module.c') to store function bodies in GPI files, too. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Variable type casts
by Peter Gerwinski 19 Jun '97

19 Jun '97

According to Frank Heckenbach: > > > Would it be possible to implement type casts of variables (like > in BP) into gpc? Currently, it only seems to know value type casts. It knows variable type casts, but only of "simple" types. I will see what I can do. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Bug with string(x)
by Frank Heckenbach 19 Jun '97

19 Jun '97

In the following program, the capacity is not handled correctly. x contains the full alphabet (though it shouldn't), and y contains garbage (at least on Linux, not on DJGPP). var y,x:string(10); begin y:=''; x:='abcdefghijklmnopqrstuvwxyz'; writeln(x); writeln(y) end. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: system.pas
by Frank Heckenbach 19 Jun '97

19 Jun '97

The African Chief wrote: > No. SYSTEM.INC (which is $INCLUDEd into GPCTYPES.PAS) > contains this; > > {.$DEFINE _Borland_16_Bit_} { 16-bit Borland data types } > {$DEFINE _Borland_Pascal_} { Borland string types } Ah, now I understand! Looks reasonable to me. > Yes, it is giving me problems with certain things in the cygwin32 C > headers. It would have made things a lot easier if they could be > exported in units - but you can't have everything ! ;-) Why not? This is gpc! ;-) > >The only way to do it (AFAICS) are include files, or defines on the command > >line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to > >work?) > > I am not sure. I just tested it, it seems to work already! > That would make my life a lot easier with translating C macros to > Pascal. However, it may be of dubious long-term benefif. At the > moment, I have to translate all those C macros into Pascal > functions. This is bit tedious, but it is probably better in the > long run. Who knows? I think it's better to translate them to functions wherever possible, though it is tedious. But there may be some things left that can't be translated adequateley -- overloaded functions are one such thing (perhaps some day they will be possible in gpc, too), and there may be other things... On a somewhat similar but different topic: Perhaps the state of some compiler switches that influence the generated code (e.g. range and stack checks when they're implemented; probably not optimization) and all the defines that are active at the beginning aof the compilation of a unit could be stored in the .gpi file. When the unit is used, and automake is active, the compiler could check if the current settings match those stored in the .gpi file, and if not, have the unit recompiled. So, if one wants to change one switch (e.g. the _Borland_16_Bit_ above), one could still use the automake and have all units updated if necessary. (In the case of defines, this would also require to store in the .gpi file which defines are tested or used, so that changing an unrelated define will not cause to unit to be recompiled.) And how about something like "--autobuild" to compile all units whether or not this seems necessary? This could be useful for a final compilation of a project (probably with a highest optimization), or to recompile something for a different platform in the same directory without having to manually remove all the .{o,gp[mi]} files (this happens to me often with DJGPP and Linux). -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Word types...
by Orlando Llanes 19 Jun '97

19 Jun '97

The only reason I suggested having Platform specific types is because since the size varies per system, and you save a file using natural types on one, they have to be read in using the same size. For example, let's say a Word is 32-bit on one system, and then you have the PC where it's 16-bit, let's call them Word (32-bit) and PCWord (16-bit). Word is 4 bytes, PCWord is 2 bytes. If data was written using PCWord, it could be read into a Word. But if a Word was written, then it needs 2 PCWords to read it properly. In this way, it's not cross platform because you have to make adjustments per platform. I'm all for the IntX data types suggested earlier for this reason, if one data type is treated the same across all platforms, then all you have to do is write a program once, and then compile it across all platforms without having to use platform specific compiler options. I'm not suggesting that they truly have to be 16-bit or 8-bit, just that to the programmer and the program they are, to GPC they can be 32-bit. I'm suggesting those data types as a supplement, not as a replacement. Ok, it may be hard to remember (for some, but I for one could remember them), but beginners don't have to worry about it, and when they advance, it's there for them to use as they see fit. See ya! Orlando Llanes

1 0

Re: system.pas
by The African Chief 19 Jun '97

19 Jun '97

On Thu, 19 Jun 1997 15:36:20 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> I am not sure I understand what you mean. However, the idea is >> this. GPC is a 32-bit compiler that wants to support the BP syntax; >> so we try to do support the *syntax* - thereby helping BP folks to >> move their programs to 32-bit.; so we keep the data structures in >> their 32-bit format - but, if, for some reason, a person who wants >> to move his 16-bit programs to 32-bit with GPC still wants his >> data types to be exactly as they are in a 16-bit compiler, then he >> has to remove a dot on one line in the unit wherein the data types >> are defined, and recompile his program. > >Yes, I see the problem. So your defaults are to use the bigger types. >I don't think that's a problem for most programs (though I just saw >one that wanted to write a LongInt, and gpc can't yet write 64 bit >variables -- but, of course, it would make more sense to implement >this feature into the RTL than to restrict the size for that reason :-). Agreed :-)= >I'm not sure I really understood how your declaration looks like. Is it >the following: > >{.$ifdef borland-16-bit} No. SYSTEM.INC (which is $INCLUDEd into GPCTYPES.PAS) contains this; {.$DEFINE _Borland_16_Bit_} { 16-bit Borland data types } {$DEFINE _Borland_Pascal_} { Borland string types } {$ifdef _Borland_16_Bit_} {$DEFINE _Borland_Pascal_} {$endif _Borland_16_Bit_} [...] >> The problem with $define is that it does not export from units. Will >> this be a problem? > >Yes! :-( Yes, it is giving me problems with certain things in the cygwin32 C headers. It would have made things a lot easier if they could be exported in units - but you can't have everything ! ;-) >The only way to do it (AFAICS) are include files, or defines on the command >line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to >work?) I am not sure. >Would it seem reasonable (and feasible) to propagate defines >(either all of them, or only those that are specially marked) through >.gpi files? At first sight, I'd think so. That would make my life a lot easier with translating C macros to Pascal. However, it may be of dubious long-term benefif. At the moment, I have to translate all those C macros into Pascal functions. This is bit tedious, but it is probably better in the long run. Who knows? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: system.pas
by Frank Heckenbach 19 Jun '97

19 Jun '97

The African Chief wrote: > I am not sure I understand what you mean. However, the idea is > this. GPC is a 32-bit compiler that wants to support the BP syntax; > so we try to do support the *syntax* - thereby helping BP folks to > move their programs to 32-bit.; so we keep the data structures in > their 32-bit format - but, if, for some reason, a person who wants > to move his 16-bit programs to 32-bit with GPC still wants his > data types to be exactly as they are in a 16-bit compiler, then he > has to remove a dot on one line in the unit wherein the data types > are defined, and recompile his program. Yes, I see the problem. So your defaults are to use the bigger types. I don't think that's a problem for most programs (though I just saw one that wanted to write a LongInt, and gpc can't yet write 64 bit variables -- but, of course, it would make more sense to implement this feature into the RTL than to restrict the size for that reason :-). I'm not sure I really understood how your declaration looks like. Is it the following: {.$ifdef borland-16-bit} In this case, one would have to remove the dot, and to define "borland-16-bit", wouldn't one? I think you can just remove the dot always. Then programs compiled without "borland-16-bit" would still use the long types, and the short types if compiled with that define (which can be put into the source if one wants to use it always, or given on the command line ("-Dborland-16-bit") for one-time use). > > (Is there a way to test in a program, if "--borland-pascal" or > > "--delphi" was given?) > > I know of none. If there isn't, could you make one, Peter? (Perhaps just some predefined symbols?) > True enough. In BP, when {$X+} is used, you can use functions just > like procedures. Perhaps Peter can add this to GPC as well, so that > no warning is generated in such instances? If this happens, then we > don't need to turn off warnings. Perhaps (additionally) a separate switch for those who want to use functions as procedures, but without the "risks" implied by "{$X+}" in other aspects? I guess, most of my units would use such a switch. > >- If you want to use my random functions in System, you're welcome to > > include them, of course. (Perhaps one day we can claim "100% BP > > compatibility -- even the random numbers are the same..." ;-). > > Okay, thanks. I will see if I can add it. AFAICR your unit uses some ASM > statements. Are we sure that ASM code in GPC will stand the test of time? I'm not ;-( So I'm asking the asm experts here: - First, the asm syntax -- can it change, or will it always work like that? - Could using 8 and 16 bit registers ever be a problem (note: that's only for __DJGPP__ and __EMX__)? - Is calling the Dos interrupt like I did it ok, or is there a better way (perhaps some DPMI calls -- perhaps even without any asm, that would be better). If so, could someone please provide the code to do so? > > As a preliminary solution for the overloading problem, one could use > > the (case-sensitive!) preprocessor, as by defining > > "{$define random RandReal}". Then "random" would be for real types, > > and all other cases for integers. (Or perhaps vice versa? Or all-caps?) > > At least, programs could be the same for BP and gpc in this respect. :-) > > The problem with $define is that it does not export from units. Will > this be a problem? Yes! :-( The only way to do it (AFAICS) are include files, or defines on the command line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to work?) Would it seem reasonable (and feasible) to propagate defines (either all of them, or only those that are specially marked) through .gpi files? At first sight, I'd think so. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

system.pas (Was `Word' data type et al)
by The African Chief 19 Jun '97

19 Jun '97

On Thu, 19 Jun 1997 03:22:55 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: [...] >The African Chief wrote: > >> >> {$ifdef _Borland_16_Bit_} >> > >> >Is this defined by default in your unit? >> >> No. The definition is commented out (with a dot before the "$") >> >> > (Otherwise it might be confusing for BP->gpc programmers.) >> >> BP->GPC programmers (like me) may want BP syntax support, >> but not necessarily want to use 16-bit data structures instead >> of the default ones. It is quite easy to remove the dot. > >Ok, so by default the unit uses data types like BP, but it can be >changed, right? I am not sure I understand what you mean. However, the idea is this. GPC is a 32-bit compiler that wants to support the BP syntax; so we try to do support the *syntax* - thereby helping BP folks to move their programs to 32-bit.; so we keep the data structures in their 32-bit format - but, if, for some reason, a person who wants to move his 16-bit programs to 32-bit with GPC still wants his data types to be exactly as they are in a 16-bit compiler, then he has to remove a dot on one line in the unit wherein the data types are defined, and recompile his program. >BTW: I just took a look at BPCompat1.0. Just a few quick comments: > >- How about some sub-directories (perhaps according to the 5 sections > of files in *.txt)? Would help in order to see immediately what's > needed for "only" BP compatibility, and what's additional > functionality. Yes, that will happen in the next release. >- Concerning FindFirst and FindNext in Dos: is there any reason why > they're functions, not procedures? > Delphi? Yes. > If so, perhaps dependent on a compiler switch? At present, no. > (Is there a way to test in a program, if "--borland-pascal" or > "--delphi" was given?) I know of none. > Otherwise, you'll always > get warnings in BP programs (and I don't think it's a good idea to > disable warnings globally). True enough. In BP, when {$X+} is used, you can use functions just like procedures. Perhaps Peter can add this to GPC as well, so that no warning is generated in such instances? If this happens, then we don't need to turn off warnings. >- If you want to use my random functions in System, you're welcome to > include them, of course. (Perhaps one day we can claim "100% BP > compatibility -- even the random numbers are the same..." ;-). Okay, thanks. I will see if I can add it. AFAICR your unit uses some ASM statements. Are we sure that ASM code in GPC will stand the test of time? (I have some programs which use a lot of 8086 asm code, and it is impossible to port these to Delphi 2 ...). > As a preliminary solution for the overloading problem, one could use > the (case-sensitive!) preprocessor, as by defining > "{$define random RandReal}". Then "random" would be for real types, > and all other cases for integers. (Or perhaps vice versa? Or all-caps?) > At least, programs could be the same for BP and gpc in this respect. :-) The problem with $define is that it does not export from units. Will this be a problem? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Variable type casts
by Frank Heckenbach 19 Jun '97

19 Jun '97

Would it be possible to implement type casts of variables (like in BP) into gpc? Currently, it only seems to know value type casts. What I mean is the following (works in BP): type x=record lo,hi:shortint end; var a:integer; begin with x(a) do begin lo:=10; hi:=1 end; writeln(a) end. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: `Word' data type et al.
by Frank Heckenbach 19 Jun '97

19 Jun '97

Maurice Lombardi wrote: > > I'd add {Short,Long,LongLong(?),Longest(?)}{Int,Card} here. > > But this is much harder to standardize: they will have different > meanings on different systems, whence better to reject them in > XXcompat units: gpc being cross-platform it will be difficult to > give a general rule whereas the others are non ambiguous: I didn't intend them to be in a XXcompat unit, but rather built-in (the only place they *could* be declared, AFAICS), provided it can be guaranteed on every platform that - 2 <= SizeOf(ShortInt) < SizeOf(Integer) < SizeOf(LongInt) (or perhaps even 8 <= 4*SizeOf(ShortInt) = 2*SizeOf(Integer) = SizeOf(LongInt) ?) - SizeOf(LongInt) < SizeOf(LongLongInt) (if LongLongInt is possible) (resp. 2*... = ...) - SizeOf(LongestInt) is the biggest possible integer size for the given compiler. (The same, of course, for Card*.) Types like Short* and Long* can be useful e.g. for multplications (ShortInt * ShortInt always fits in an Integer, Integer * Integer fits in a LongInt, ...). Longest* would be useful for programs that want to offer the biggest possible range without having to know what this is on every platform. Furthermore, it *might* become useful to have a Cardinal that's exactly the size of a pointer (since for a normal Cardinal this doesn't always hold, and AFAIK, only the compiler knows the actual pointer size). Though pointer arithmetic has mostly eliminated the need for explicit type casts between pointers and integers, there may be some cases left, where it's needed... > but notice that in BP I frequenly used a defreal unit, > (referenced from the main and all other units) which > contains either > > type real = single > or > type real = double > or > type real = extended > > to have a quick way to see the effect of the size of reals on accuracy > or speed of some computations. But this is a purely private trick > which should be restricted to such peculiar purposes. I think you could do this in gpc as well (I see no reason why not). PS: No copies by email necessary. I get your mails through the list, anyway. Peter Gerwinski wrote: > > > Cardinal 0 .. 2147483647 Non sign=E9, 32 bits > > If Delphi uses "Cardinal", gpc should use it too, of course. > > It already does. 32 bits, unsigned. True, fine! :-) > As you can see above, > `Cardinal' is 31 bits, unsigned, in Delphiy. Has anybody an > idea, why? I guess they didn't want to get into trouble with the internal handling of integer values in the compiler. If Cardinal is a subset of Integer, they can store anything in an Integer internally. Otherwise, they'd have to have a flag indicating if signed or unsigned (I guess this is what gpc does, right?). IOW: The same reason why there wasn't an unsigned 32 bit integer in BP (I suppose). > GPC's current setting - on *all* platforms - is the following: > > GNU Pascal GNU C > > Byte unsigned char > ByteInt signed char Is a char *always* 1 byte in C? > ShortWord unsigned short > ShortInt short > Integer int, long > Word, Cardinal unsigned, unsigned long > LongInt, Comp long long > LongWord unsigned long long How about "ShortCard" and "LongCard", too? I guess, Comp should rather be fixed to 64 bits ("Integer(64)") than dependent on "long long", for BP compatibility. Since you didn't mention it, I assume it's not possible (on current platforms) to have an integer > 64 bits, is it? > I see only one possible reason why we should change that: It is > not absolutely sure that `int' will always remain the same as `long' > on GCC. Is it guaranteed that "short" is always shorter than (resp. half as big as) "int", and "int" than "long long"? > The sizes of these types are the same on all platforms I have seen > so far. (8, 8, 16, 16, 32, 32, 64, 64.) Also on the Alpha? Isn't this a 64 bit processor (so "int" should be 64 bits)? But anyway, I guess, this can change in the future... > I agree, but maybe a different syntax would be preferable. UCSD Pascal > has a "long Integer" type which is written as > > Type Int42 = Integer [ 42 ]; > > Where `42' is the number of decimal digits. (In the long run, this should > be in GPC, too.) What about defining > > Type Int16 = Integer ( 16 ); > Type Word16 = Word ( 64 ); > > for types with a specified number of *dual* digits, read: bits? Why not! (With the actual size rounded up to bytes (or to a power of 2 of bytes) unless in a packed array/record?) > What are we talking about? > > Pascal has subrange types. Why not forget about all this and let the > user specify the types by himself? > > Type > I16 = -$8000..$7FFF; > W16 = 0..$FFFF; > > MyRecordToAccessSomeStrangeSystemData = record > Descriptor: 0..$FFFFFFFF; > ImportantData: -$80..$7F; > FillSpace: array [ 0..42 ] of 0..$FF; > end (* MyRecordToAccessSomeStrangeSystemData *); > > Then, of course, GPC must not reserve more space than necessary for > them - which it does not do anyway since it has packed records. But it does if you declare the type plainly, i.e. Sizeof(0..$FF) = 4. This is handled faster than one byte, but takes more memory. What about "packed" with those types as well ("type Int8 = packed -$80..$7F")? -- Looks strange, I know, but there should be some way to decide if one wants speed or small size (the latter can be important e.g. in binary files). Given this or something equivalent (and of course, subranges that exceed Integer), I'd prefer this to "Integer(n)". The African Chief wrote: > >> {$ifdef _Borland_16_Bit_} > > > >Is this defined by default in your unit? > > No. The definition is commented out (with a dot before the "$") > > > (Otherwise it might be confusing for BP->gpc programmers.) > > BP->GPC programmers (like me) may want BP syntax support, > but not necessarily want to use 16-bit data structures instead > of the default ones. It is quite easy to remove the dot. Ok, so by default the unit uses data types like BP, but it can be changed, right? (That's what I meant how it should be for unsuspicious BP->gpc programmers.) BTW: I just took a look at BPCompat1.0. Just a few quick comments: - How about some sub-directories (perhaps according to the 5 sections of files in *.txt)? Would help in order to see immediately what's needed for "only" BP compatibility, and what's additional functionality. - Concerning FindFirst and FindNext in Dos: is there any reason why they're functions, not procedures? Delphi? If so, perhaps dependent on a compiler switch? (Is there a way to test in a program, if "--borland-pascal" or "--delphi" was given?) Otherwise, you'll always get warnings in BP programs (and I don't think it's a good idea to disable warnings globally). - If you want to use my random functions in System, you're welcome to include them, of course. (Perhaps one day we can claim "100% BP compatibility -- even the random numbers are the same..." ;-). As a preliminary solution for the overloading problem, one could use the (case-sensitive!) preprocessor, as by defining "{$define random RandReal}". Then "random" would be for real types, and all other cases for integers. (Or perhaps vice versa? Or all-caps?) At least, programs could be the same for BP and gpc in this respect. :-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: `Word' data type et al.
by Frank Heckenbach 19 Jun '97

19 Jun '97

Maurice Lombardi wrote: > You may be interested to know the answer given by Borland to the same > problem in Delphi 2.0 when going from 16 bit to 32 bit system.=20 > The following is a cut out of the Delphi help (in french however): I don't understand much French, sorry, but I think I can recognize the important words :-) > Type Intervalle Format > > Integer -32768 .. 32767 Sign=E9, 16 bits > > Integer -2147483648 .. 2147483647 Sign=E9, 32 bits > > Cardinal 0 .. 65535 Non sign=E9, 16 bits > > Cardinal 0 .. 2147483647 Non sign=E9, 32 bits If I understand it right, Integer and Cardinal have different sizes on 16 and 32 bit Delphi, right? This would be like in gpc (though not 16 bit, AFAIK, but 64 bit and perhaps more). Perhaps contrary to Delphi, I don't think LongInt should be 32 bits on every platform, but rather twice as bug as Integer. What do you think? > The idea is exactly the same as that contained in the letter of > Frank Heckenbach of today, except for the replacement of=20 > Ordinal by Cardinal (which was also suggested by Franck). That's fine! If Delphi uses "Cardinal", gpc should use it too, of course. > So I would vote to implement what is proposed by Franck, > with only the replacement of ordinal by cardinal to have > some compatibility. i.e. > > Generic Types > > Integer Cardinal I'd add {Short,Long,LongLong(?),Longest(?)}{Int,Card} here. > Well defined types > > int8 card8 (=3Dbyte is the only case without doubt) > int16 card16 > int32 card32 > > ... > > card9 =3D 0..2 POW 9 -1 ... if needed: this is always > allowed by the pascal syntax > but the amount of memory involved > is implementation dependant: Sounds good. > Compatibility types > > anything contained in bpcompat.pas delphi1compat.pas > delphi2compat.pas and everything you need, > better than compiler switches when possible to > avoid to garble the compiler by a lot of special > purpose oddities: the idea of C to keep a minimum > in the compiler and a maximum in libraries is > not so bad (when it is possible). I agree! Except for "integer", all types can be redeclared in these units. (I think, "integer" could be redeclared, too, but AFAIR it's not a good idea to do so, is it?) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

Re: `Word' data type et al.
by Maurice Lombardi 18 Jun '97

18 Jun '97

In message Wed, 18 Jun 1997 20:13:16 +0200 (MET DST), Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> writes: > According to Frank Heckenbach: > >> >> > Cardinal 0 .. 65535 Non sign=E9, 16 bits >> > >> > Cardinal 0 .. 2147483647 Non sign=E9, 32 bits >> >> [...] >> >> That's fine! If Delphi uses "Cardinal", gpc should use it too, >> of course. > > It already does. 32 bits, unsigned. As you can see above, > `Cardinal' is 31 bits, unsigned, in Delphi. Has anybody an > idea, why? > Seems a bug or at least it is inconsistent with the comment that they give to this stuff. Anyway I have checked that Delphi 2 rejects c:=$FFFFFFFF with c cardinal (and gives -1 for c integer); But the idea that we had in mind is that "generic" types are signed (integer) and unsigned (cardinal) integers best suited to a given computer, usually 16 bits Five years ago, 32 bits now, 64 bits in next Five years, 128 bits in next 10 years. This is what is needed for common arithmetic computations. But other needs are e.g. reading binary files coming from other computers or reading I/O ports, where the number of bits has to be specified exactly. >> > Generic Types >> > > GPC's current setting - on *all* platforms - is the following: > > GNU Pascal GNU C > > Byte unsigned char > ByteInt signed char > ShortWord unsigned short > ShortInt short > Integer int, long > Word, Cardinal unsigned, unsigned long > LongInt, Comp long long > LongWord unsigned long long > > I see only one possible reason why we should change that: It is > not absolutely sure that `int' will always remain the same as `long' > on GCC. > > The sizes of these types are the same on all platforms I have seen > so far. (8, 8, 16, 16, 32, 32, 64, 64.) However I agree that it is > a good idea to provide types of known size. > > >> > Well defined types >> > >> > int8 card8 (byte is the only case without doubt) >> > int16 card16 >> > int32 card32 >> > >> > [...] >> >> Sounds good. >> > > I agree, but maybe a different syntax would be preferable. UCSD Pascal > has a "long Integer" type which is written as > > Type Int42 = Integer [ 42 ]; > > Where `42' is the number of decimal digits. (In the long run, this should > be in GPC, too.) What about defining > > Type Int16 = Integer ( 16 ); > Type Word16 = Word ( 64 ); > > for types with a specified number of *dual* digits, read: bits? > Seems fine > > === BUT === > > What are we talking about? > > Pascal has subrange types. Why not forget about all this and let the > user specify the types by himself? > > Type > I16 = -$8000..$7FFF; > W16 = 0..$FFFF; > > MyRecordToAccessSomeStrangeSystemData = record > Descriptor: 0..$FFFFFFFF; > ImportantData: -$80..$7F; > FillSpace: array [ 0..42 ] of 0..$FF; > end (* MyRecordToAccessSomeStrangeSystemData *); > > Then, of course, GPC must not reserve more space than necessary for > them - which it does not do anyway since it has packed records. > (These topics are related, as you can well imagine.) > This is the best Pascalish point of view (and in fact the one I use in computations, if I know that an integer is within 0 and 100, I never declare it as byte but as 0..100, letting the computer determine the amount of space necessary) But for the binary stuff to work it __must__ be granted that the minimum space is actually used: Pascal gives the subrange definition which gives (among others) full compatibility between platforms for computations, but the amount of space which corresponds to a subrange is not enforced. Maurice Lombardi | Laboratoire de Spectrometrie Physique | Maurice.Lombardi(a)ujf-grenoble.fr Universite Joseph Fourier de Grenoble | tel: (33) 04 76 51 47 51 BP 87 | fax: (33) 04 76 51 45 44 38402 Saint Martin d'Heres Cedex FRANCE |

1 0

Re: `Word' data type et al.
by Peter Gerwinski 18 Jun '97

18 Jun '97

According to The African Chief: > > >> Type > >> Single = __short__ Real; > >> Double = Real; > >> Extended = __long__ Real; > >> ShortInt = __byte__ Integer; > >> LongInt = Integer; > >> Comp = __longlong__ Integer; > >> Integer16 = __short__ Integer; > >> Word = __unsigned__ Integer16; > >> {$endif _Borland_16_Bit_} > > I believe that "Byte" is the same in GPC and BP, and so > it doesn't need to be redefined for 16-bit BP. The same is true for `Single', `Double', `Extended', and `Comp'. (Just for compatibility.) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: `Word' data type et al.
by Peter Gerwinski 18 Jun '97

18 Jun '97

According to Frank Heckenbach: > > > Cardinal 0 .. 65535 Non sign=E9, 16 bits > > > > Cardinal 0 .. 2147483647 Non sign=E9, 32 bits > > [...] > > That's fine! If Delphi uses "Cardinal", gpc should use it too, > of course. It already does. 32 bits, unsigned. As you can see above, `Cardinal' is 31 bits, unsigned, in Delphiy. Has anybody an idea, why? > > Generic Types GPC's current setting - on *all* platforms - is the following: GNU Pascal GNU C Byte unsigned char ByteInt signed char ShortWord unsigned short ShortInt short Integer int, long Word, Cardinal unsigned, unsigned long LongInt, Comp long long LongWord unsigned long long I see only one possible reason why we should change that: It is not absolutely sure that `int' will always remain the same as `long' on GCC. The sizes of these types are the same on all platforms I have seen so far. (8, 8, 16, 16, 32, 32, 64, 64.) However I agree that it is a good idea to provide types of known size. > > Well defined types > > > > int8 card8 (=3Dbyte is the only case without doubt) > > int16 card16 > > int32 card32 > > > > [...] > > Sounds good. I agree, but maybe a different syntax would be preferable. UCSD Pascal has a "long Integer" type which is written as Type Int42 = Integer [ 42 ]; Where `42' is the number of decimal digits. (In the long run, this should be in GPC, too.) What about defining Type Int16 = Integer ( 16 ); Type Word16 = Word ( 64 ); for types with a specified number of *dual* digits, read: bits? ... === BUT === What are we talking about? Pascal has subrange types. Why not forget about all this and let the user specify the types by himself? Type I16 = -$8000..$7FFF; W16 = 0..$FFFF; MyRecordToAccessSomeStrangeSystemData = record Descriptor: 0..$FFFFFFFF; ImportantData: -$80..$7F; FillSpace: array [ 0..42 ] of 0..$FF; end (* MyRecordToAccessSomeStrangeSystemData *); Then, of course, GPC must not reserve more space than necessary for them - which it does not do anyway since it has packed records. (These topics are related, as you can well imagine.) > > Compatibility types > > > > anything contained in bpcompat.pas delphi1compat.pas > > delphi2compat.pas and everything you need, > > better than compiler switches when possible to > > avoid to garble the compiler by a lot of special > > purpose oddities: the idea of C to keep a minimum > > in the compiler and a maximum in libraries is > > not so bad (when it is possible). > > I agree! Except for "integer", all types can be redeclared in these > units. (I think, "integer" could be redeclared, too, but AFAIR it's > not a good idea to do so, is it?) It's not a good idea for the same reason as it is not a good idea to change the size of `Integer' by a compiler switch. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: CStrings/PChars
by The African Chief 18 Jun '97

18 Jun '97

On Tue, 17 Jun 1997 16:18:14 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to The African Chief: >> >> Great! Now one last thing about pChars - can you make >> them type-compatible with zero-based arrays of Char? > >It seems to work already ... my GPC just compiled: > > > program foobar; > > {$X+} > > function foo ( p : pChar ) : pChar; > Begin > foo := succ ( p, 2 ); > End; > > Var > x : array [ 0..4 ] of Char value 'xyOK'#0; > > Begin > writeln ( foo ( x ) ); > End. Yes, it does seem so. However, the following program gives different outputs under BP and GPC; program foobar; {$ifdef ver70} Uses Strings; function puts ( astr : PChar ) : char; begin Writeln ( astr ); end; {$else} {$X+} {$W-} function strcopy ( s1 : PChar; s2 : PChar ) : PChar; asmname 'strcpy'; function strcat ( s1 : PChar; s2 : PChar ) : PChar; C; function puts ( s1 : PChar ) : Integer; C; {$endif} function foo ( p : pChar ) : pChar; Begin foo := p + 2; End; Var x : array [ 0..24 ] of Char; Begin strcopy(x, 'African'); strcat(x, #13#10); strcat(x, 'Chief'); puts(x); End. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: `Word' data type et al.
by The African Chief 18 Jun '97

18 Jun '97

On Tue, 17 Jun 1997 16:13:12 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> In bpcompat's GPCTYPES unit, I have this; >> >> {$ifdef _Borland_16_Bit_} > >Is this defined by default in your unit? No. The definition is commented out (with a dot before the "$") > (Otherwise it might be confusing for BP->gpc programmers.) BP->GPC programmers (like me) may want BP syntax support, but not necessarily want to use 16-bit data structures instead of the default ones. It is quite easy to remove the dot. >> Type >> Single = __short__ Real; >> Double = Real; >> Extended = __long__ Real; >> ShortInt = __byte__ Integer; >> LongInt = Integer; >> Comp = __longlong__ Integer; >> Integer16 = __short__ Integer; >> Word = __unsigned__ Integer16; >> {$endif _Borland_16_Bit_} > >Don't forget: > >Byte = __unsigned__ Shortint; I believe that "Byte" is the same in GPC and BP, and so it doesn't need to be redefined for 16-bit BP. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Random
by Frank Heckenbach 18 Jun '97

18 Jun '97

I wrote a random unit that uses the same algorithm as BP does. It produces exact the same random numbers as the Random function of BP 7.0 (I heard, older BP versions used a different algorithm, though). Just a couple of notes/questions: - Is the DOS interrupt in Randomize call OK for DJGPP and EMX? I'm not really sure if it's good, but it seems to work. Any improvements welcome! - The code is not meant as a "default" random procedure for gpc, but only for BP compatibility. - Of course, RandReal should have the same name as Random, when function overloading exists. - When range checking exists, NextRand must be compiled without it. (That's why I put "{$W-,R-,W+}" in :-) - The type declarations should be replaced by machine-independent ones (or be predefined by the compiler in the future). - Random produces exact the same random number sequence as BP's integer random. RandReal gives the same values an BP's Random for FPU types (e.g. Double). BP's Random for BP's own Real type differs from that by 0.5 (doesn't really matter, just if someone wants to compare the random values). While writing it, I discovered some type casting bugs in gpc concerning signed/unsigned integers: program x; var a:integer value -$80000000; begin Writeln(ShortWord((LongWord(a)*4) DIV $100000000)); {65534, should be 2} Writeln(Word((LongWord(a)*4) DIV $100000000)); {-2, should be 2} end. Another thing is the implicit real->integer(!) conversion, e.g. "Writeln(Integer(2.2))" works (and gives 2). Is this required by the standard? Otherwise I don't think it should work. At least, it shouldn't with "--borland-pascal". Apropos of BP compatibility: I think many BP users wouldn't like to have to put something like "{$ifdef __gpc__}uses system;{$endif}" in their programs. Is there a way to do this easier? If not, could one be created (perhaps a compiler switch that uses a given unit in all compiled files automatically; though I don't think it should be set by default even with "--borland-pascal", since System is a "contrib". But people could then set an alias to "gpc --automake --executable-file-name --borland-pascal --uses="system" or so...)? --- UNIT Rand; INTERFACE TYPE Cardinal=Word; Card16=ShortWord; Card32=Word; Card64=LongWord; Int32=Integer; VAR RandSeed:Int32 VALUE 0; FUNCTION Random(Range:Card16):Card16; FUNCTION RandReal:Real; PROCEDURE Randomize; IMPLEMENTATION {$W-,R-,W+} PROCEDURE NextRand; BEGIN RandSeed:=$8088405*RandSeed+1 END; FUNCTION Random(Range:Card16):Card16; BEGIN NextRand; Random:=(Card32(RandSeed)*Card64(Range)) DIV $100000000 END; FUNCTION RandReal:Real; BEGIN NextRand; RandReal:=RandSeed/4294967296.0+0.5 END; {$IFDEF __DJGPP__}{$DEFINE DOS}{$ENDIF} {$IFDEF __EMX__}{$DEFINE DOS}{$ENDIF} {$IFDEF DOS} PROCEDURE Randomize; VAR RandSeedLoHi:PACKED RECORD Lo,Hi:Card16 END ABSOLUTE RandSeed; BEGIN ASM("movb $44,%%ah int $0x21" :"=c"(RandSeedLoHi.Lo), "=d"(RandSeedLoHi.Hi) ::"eax","ebx","ecx","edx","esi","edi") END; {$ELSE} FUNCTION Rand:Integer; C; PROCEDURE SRand(Seed:Cardinal); C; FUNCTION GetPID:Integer; C; PROCEDURE Randomize; BEGIN SRand(GetPID); RandSeed:=Rand END; {$ENDIF} END. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: push (was: "Bug fixes")
by Frank Heckenbach 18 Jun '97

18 Jun '97

Jan-Jaap van der Heijden wrote: > The GCC 2.7.2.x backend used by GPC knows nothing about pentium > optimzations or instruction scheduling. I'd think the direct push is also faster on a 386/486, isn't it? (As I said in another mail, I couldn't check it myself.) > [...] So, I guess more work is needed here > (by the GCC crew), although this compiler produces significantly faster > code already :-) Do you know who one could report this problem to, and ask about the backend in general (newsgroups, addresses)? There's another issue (concerning our planned OOP-interface implementation) that I'd like to ask someone about. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: cygwin
by O. Patrick Barnes 18 Jun '97

18 Jun '97

Thanks for the help. That did work nicely. however I still have this problem... I can get winhello.pas to compile, however I get errors in the others when they compile... here is the error: C:\gpcwin32\test\windows>make gpc -g -Wl,-subsystem,windows -o winhello.exe winhello.pas -lkernel32 -lgdi32 -luser32 ld: warning: cannot find entry symbol _WinMainCRTStartup; defaulting to 00401000 gpc -g -o winversion.exe winversion.pas -lkernel32 -lgdi32 -luser32 gpc -g -o compname.exe compname.pas -lkernel32 -lgdi32 -luser32 C:\gpcwin32\test\windows> I captured the make above^^^^^ Also, earlier you asked if I would like to help in the writing of the win32 GUI functions for GPC. I would love to! Just let me know where to start. I am a very good pascal and intermediate C programmer, so my assistance at this is at your disposal. Thanks! -obarnes(a)online.emich.edu > On Mon, 16 Jun 1997, O. Patrick Barnes wrote: > > > Where can I get a copy of GPC with the correct version of cygwin.dll > > included! I can't get the windows version to run! Is there a package > > that includes everything I need, including cygwin?! That would be much > > easier. > > > > ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32/gpc-i970526.i386-cygwin32-b18.zip > > Hope this helps, > > JanJaap

1 0

Re: Bug fixes (was: "Recursion, need more stack space.")
by Frank Heckenbach 17 Jun '97

17 Jun '97

Peter Gerwinski wrote: > Fixed. :-) > Fixed. :-) > > Another thing I observed when looking at the asm code (see above) was > > that the i386 backend doesn't seem to know the "push mem" instruction. > > [...] > > Probably. However if you want to try yourself on that problem, look > into the GCC info documentation, and read about "machine descriptions". > There is something about how to describe each instruction a processor > has, and maybe it's a trivial error and somebody overlooked this > instruction. I looked at i386.h and i386.md, and it seems like there isn't even a way to push anything but registers and constants... ?-( > Or else: Loading the memory reference into a register and > pushing that *might* be faster than a direct push (don't know). That might be a reason. But I don't know, either. I would suppose not -- why should the extra loading a register be faster? I tried some ways to measure the actual time (system clock, ps, /proc/..., even gprof), but they were all terribly inaccurate (+/- 5..10%), so there's no chance to check which is faster. :-( Anyone knows a way to measure runtime presicsely (Linux or DJGPP)? Jan-Jaap van der Heijden wrote: > unsigned-rel = digit-sequence `.' fractional-part [ `e' scale factor ] > | digits-sequence `e' scale factor > [...] > I see a simular definition in my Turbo pascal Programmer's Guide, so > BP should not accept it either. The BP handbook says (Fig. 2.3, at least in the German version): unsigned real value (as above) unsigned numerical value = unsigned integer | unsigned real value This looks reasonable to me. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

CStrings/PChars
by Peter Gerwinski 17 Jun '97

17 Jun '97

According to The African Chief: > > Great! Now one last thing about pChars - can you make > them type-compatible with zero-based arrays of Char? It seems to work already ... my GPC just compiled: program foobar; {$X+} function foo ( p : pChar ) : pChar; Begin foo := succ ( p, 2 ); End; Var x : array [ 0..4 ] of Char value 'xyOK'#0; Begin writeln ( foo ( x ) ); End. (Note that the (*$X+*) directive is needed to enable both pointer arithmetics and `pChar's being treated as Strings.) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: `Word' data type et al.
by Frank Heckenbach 17 Jun '97

17 Jun '97

The African Chief wrote: > In bpcompat's GPCTYPES unit, I have this; > > {$ifdef _Borland_16_Bit_} Is this defined by default in your unit? (Otherwise it might be confusing for BP->gpc programmers.) > Type > Single = __short__ Real; > Double = Real; > Extended = __long__ Real; > ShortInt = __byte__ Integer; > LongInt = Integer; > Comp = __longlong__ Integer; > Integer16 = __short__ Integer; > Word = __unsigned__ Integer16; > {$endif _Borland_16_Bit_} Don't forget: Byte = __unsigned__ Shortint; But I think you could use the "more comfortable" gpc identifiers now, just to make it a bit more readable. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

CStrings/PChars (was: Whats wrong?!?)
by Peter Gerwinski 17 Jun '97

17 Jun '97

According to The African Chief: > > Great! Now one last thing about pChars - can you make > them type-compatible with zero-based arrays of Char? > This is the case with BP - so that any function/procedure > that takes a pChar as a parameter will accept a zero-based > array of Char as well - thanks! Thanks for the example programs! They make it easier to implement. I must admit that I do not really like this CString/PChar stuff: All this is C, not Pascal, and I am implementing it for compatibility's sake only - both with Borland compilers and with C libraries which exist on many platforms and are important to support. However, this will only work in GPC together with the (*X+*) directive. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: `push' instructions (was: Bug fixes)
by PredatorZeta 17 Jun '97

17 Jun '97

According to Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de>: > According to PredatorZeta: > > Just little clarifying.....:)) > > No. Surely not on 80x86 machines. Look this (is for Pentium): > > > > 1 push (mem) take 2 cycles NOT pairable > > > > 2 a) mov (mem), reg take 1 cycle pairable > > AGI Stall (1 cycle+cut off pairing > > system) > > b) push reg take 1 cycle pairable > > > > TOTAL: 3 cycles > > > > Well, is 2 (not pairable) versus 2 1/2 (not pairable) cycles..... > > However, with a manual re-ordering it could take only 1 cycle...8-)) > > > > Hope this clarify...... > > Partially. As far as I understand the above, it's > > push (mem) 2 cycles not pairable > > mov (mem), reg 1 cycle pariable > push reg 1 cycle pairable > > so both versions have the same speed, but the second one > is pairable (-;whatever that means ... Only theoretically..::)) This is because between the two instructions there is an AGI stall, a Pentium hardware-generated LOCK instruction.(why? because there is a read after write!!) 8-< This block ALL pairing rules and costs 1 cycle. Then: 1 cycle for the MOV pairable (BUT THAT DON'T PAIR!!) 1 cycle for AGI (block all pipeline!!) 1 cycle for the PUSH pairable = 2 cycles(not pairable) + 1 pairable= 2 1/2 cycles > I guess it means that > it is executed in parallel with a floating point operation, > right?). Yez, but also PUSH (MEM) can do this... Cya PrZ -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Re: Whats wrong?!?
by The African Chief 17 Jun '97

17 Jun '97

On Tue, 17 Jun 1997 02:11:17 +0200 (MET DST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >According to Frank Heckenbach: >> >> Ooops, can't gpc write PChars at all? The following doesn't work: >> >> program x; >> {$x+} >> var a:PChar; >> begin >> writeln(a) >> end. > >Fixed. > >> Similarly, the following compiles with BP, but not with gpc: >> >> program x; >> {$x+} >> var a:PChar; >> begin >> a:='Test' {in BP: assign the address of the 0-terminated string 'Test'#0 >> (stored somewhere statically) to a} >> end. > >Fixed. Great! Now one last thing about pChars - can you make them type-compatible with zero-based arrays of Char? This is the case with BP - so that any function/procedure that takes a pChar as a parameter will accept a zero-based array of Char as well - thanks! e.g., program foobar; uses strings; {$W-} function foo ( p : pChar ) : pChar; Begin writeln ( p ); foo := strlen ( p ); End; Var x : array [ 0..64 ] of Char; Begin strcopy ( x, 'Dr. Chief' ); writeln ( foo ( x ) ); End. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Help!
by O. Patrick Barnes 17 Jun '97

17 Jun '97

Where can I get a copy of GPC with the correct version of cygwin.dll included! I can't get the windows version to run! Is there a package that includes everything I need, including cygwin?! That would be much easier. Thanks, obarnes(a)online.emich.edu

2 1

Re: `Word' data type et al.
by Frank Heckenbach 17 Jun '97

17 Jun '97

Peter Gerwinski wrote: > I noticed a lot of confusion about Integer types in GNU Pascal. So did I (read: I was confused in the beginning ;-). I was going to post something about it sometime anyway... > 32 Integer Word [unsigned] int == long > 64 LongInt LongWord [unsigned] long long > > (BTW: The number of bits is the same on all platforms, isn't it?) Even if it is now, it probably won't be forever, I guess... (What about the 64 bit platforms (Alpha)? Isn't Integer 64 bits there? Should it be? What about LongInt there?) Is it always (on every platform) guaranteed that "Integer" is strictly bigger than "ShortInt", and "LongInt" is strictly bigger than "Integer"? BTW: Is 64 bits the biggest possible size (at least for 32 bit platforms), or would it be possible to make 128 bit types? (If not, this would probably decide how big the ClassID for objects will be, BTW...) If so, it might probably be called "LongLongInt", and then I'd also suggest something like "LongestInt" or so to get the actually biggest possible type on every system. > I was told more than once that `Word' should have 16 bits (like in > Borland Pascal). I made it 32 bits because this is the "natural" > size on a 32-bit system (like GPC), and it has the same size as > `Integer' (like in Borland Pascal;-). I think this is a good idea. However, for BP compatibility one might define Word as 16 bit in the bpcompat system unit or so, but this should not be the gpc default, IMHO. Christian Wendt wrote: > It could be depend on the Compilerswitches? (there's a --borland-pascal > switch?) > [...] > advantage: BP programms can be compiled more identically. > (maybe someone uses specific type to swap sign by adding.... %-) Argh! But there are cases where the size is necessary (e.g. data files that should be read). I'd favour an explicit declaration instead of this compiler switch, because in many places, even in BP programs, you don't necessarily want the BP sizes (e.g. one often uses "Integer" without much thinking about the exact size, just to have "an integer data type", so it wouldn't hurt to use gpc's 32 bit integer instead). For a quick BP->gpc conversion, one could use the BP identifiers declared in system. Then, to improve the program, one could find those places where the size really matters, and put types like int8 (8 bit integer) or such there. Those can be declared with gpc and BP. Peter Gerwinski wrote: > AFAIK, a "word" is defined to be the "natural" unit of the computer, > but maybe this definition has changed since I have learned it. I think this is correct. However, the word "Word" seems inappropriate to me. In natural language, this word has a different meaning (as this sentence shows), and in mathematics and computer science it has usually also another meaning (a finite sequence of elements of a given "alphabet"). I think "Word" in this sense is only common in assembler, and crept into Pascal through BP (correct me if I'm wrong). So, what else? In mathematics, one says "natural numbers", but I don't think "natural" would be a natural name for this data type... ;-). "unsigned integer" as in C doesn't seem so good, either, simply because it's two words. What about a name as "ordinal" (or "cardinal" -- which one would be better?)? In the following I'll write "ordinal", and in analogy to "LongInt" and "ShortInt" also "LongOrd" and "ShortOrd". (The similarity in name to the Ord function is, of course, not accidental, since ord(x) will always be "ordinal", except if x is a signed integer, or one of the "strange" enum values we discussed recently.) To me, such a name would seem more "high level" (Pascalish) than "word" (low level, assembler) or "unsigned" (medium level, C). > It would not be difficult to implement a compiler switch (*$16-bit *) (or > a command-line option `--16-bit') to make `Integer' and `Word' 16 bits etc., > but I am not so sure that this is a good idea since GPC is a true 32-bit > compiler. If we want to look out for a different "natural" data size for > GPC, it should not be 16 bits, but 64 bits! I don't think such a switch would be a good idea, or even necessary. If someone wants Word to be 16 bits, one can just redeclare it (e.g. in system) -- after all, "Word" is not a reserved word... Orlando Llanes wrote: > I have an idea, perhaps there could be platform dependant types, for > example: VAR MyVar : PCByte; This way it would be treated as 8-bits on all > platforms, the natural types can stay, all one has to do is use the > platform type to compensate for it if necessary. This way, 1) the data > works consistently across all platforms because (for example) they know > that a PCByte is 8 bits, 2) If a byte is a different size on another > platform, then it doesn't matter because the PCByte is the same no matter > where it's compiled. I guess this could be accomplished by making the > PCByte a natural Byte, but in the code, anything above the 8 bits is not > used. I agree (I also don't like things like "__byte__ integer", because it reminds me of C ;-), and I find such identifiers with many underscores "ugly" -- IMHO, if they're necessary at all, they should be there only in a few low level modules/units). But I wouldn't like the name "PCByte". I don't think "PCByte" will be easy to remember... What about the following (the meanings are obvious): Int8 Ord8 Int16 Ord16 Int32 Ord32 Int64 Ord64 Int128 Ord128 (?) [...] If subrange types would automatically have the correct size (currently they don't -- unless within a packed array or record), and "subranges" are also allowed for ranges that exceed integer (like "Ordinal" or "LongInt"), one could just declare all of these types in a normal way like "Int8=-$80..$7F" ... "Ord128=0..$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF". :-) For BP->gpc, as I said above, the types to choose depend on what's really intended. I think one could use about the following rules (please check them carefully; I made several assumptions about the types of which I'm not sure they're valid on all platforms): BP: ShortInt gpc: Int8 BP: Byte gpc: Ord8 BP: Integer gpc: - If exactly a "16 bit signed integer" is wanted, Int16 - If an integer of at least 16 bits is wanted, ShortInt - If just "an integer" is wanted (maybe implying that it can be handled most efficiently), Integer BP: Word gpc: - If exactly a "16 bit unsigned integer" is wanted, Ord16 - If an unsigned integer of at least 16 bits is wanted, ShortOrd - If just "an unsigned integer" is wanted (maybe implying that it can be handled most efficiently), Ordinal - If the biggest possible unsigned integer is wanted (though this might be rare, since one would probably rather use LongInt then in BP though that's signed), LongOrd BP: LongInt gpc: - If exactly a "32 bit signed integer" is wanted, Int32 - If an integer of at least 32 bits is wanted, Integer - If an integer type is wanted that's bigger than Integer (e.g. to hold the result of a multiplication of two integers), LongInt - If the biggest possible [signed] integer type is wanted, LongInt (LongLongInt? LongestInt?) - If an unsigned (!) integer of at least 31 bits is wanted, Ordinal - If the biggest possible unsigned (!) integer is wanted, LongOrd (Did I miss any possible intentions? ;-) Another thing, only partly related to the above: is there any support for endianness (i.e. byte order of integers that are bigger than 1 byte) in gpc yet? (This would be necessary e.g. to read binary files on different platforms.) If not, I'd suggest funtions like "SmallEndian" and "BigEndian", defined for all integer types, which convert a value, given in the normal machine's endianness, to a small endian or big endian value, resp. (or vice versa, which is the same conversion). On each given platform, one half of the functions would do nothing, the other half would reverse the byte order. If there's a conditional define concerning endianness, such functions could be implemented in Pascal with {$IFDEF}'s, otherwise they'd have to be provided by the compiler. Next topic:-) While we are talking about integer sizes, what about boolean sizes? Usually, a boolean is 1 bit, of course, but in some cases (e.g. system calls) one needs booleans of 1 byte (this would only be a difference in a packed array or record) or 2 bytes (e.g. Windoze API, cf. BP's "bool" type), perhaps even more. So it might be useful to have "bool8", "bool16", ... . The internal value 0 would be false, and any other value would be interpreted as true, while the standard true value is 1 (or -1?). Syntactically they would be treated just like booleans (i.e. assignment compatibility between each other, but not with integers; can be used in if/while/until conditions; work with and/or/xor/not/...). And one more topic (also related to some kind of sub-types, at least): Dr John Stockton <jrs(a)merlyn.demon.co.uk> wrote once in c.l.p.b.: > A better language might include sub-types of real, > R>0 R>=0 R<0 R<=0 R<>0 , > with rangechecking. ...or, more generally, arbitrary intervals. Or even more generally, sub-types with a user-defined function(super_type):boolean to decide if an element belongs to the sub-type. (Of course, subranges of ordinal types are a special case of this, too, at least in theory...) Since all of this would only affect range checking, it's not a current topic for now. With range checking, it might not even be very difficult to implement, just using the user-defined function instead of the "standard" range checking function... BTW: Does the PXSC standard have any ideas about such things? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

Re: Whats wrong?!?
by Peter Gerwinski 17 Jun '97

17 Jun '97

According to Frank Heckenbach: > > Ooops, can't gpc write PChars at all? The following doesn't work: > > program x; > {$x+} > var a:PChar; > begin > writeln(a) > end. Fixed. > Similarly, the following compiles with BP, but not with gpc: > > program x; > {$x+} > var a:PChar; > begin > a:='Test' {in BP: assign the address of the 0-terminated string 'Test'#0 > (stored somewhere statically) to a} > end. Fixed. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Bug fixes (was: "Recursion, need more stack space.")
by PredatorZeta 16 Jun '97

16 Jun '97

Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: > Or else: Loading the memory reference into a register and > pushing that *might* be faster than a direct push (don't know). Just little clarifying.....:)) No. Surely not on 80x86 machines. Look this (is for Pentium): 1 push (mem) take 2 cycles NOT pairable 2 a) mov (mem), reg take 1 cycle pairable AGI Stall (1 cycle+cut off pairing system) b) push reg take 1 cycle pairable TOTAL: 3 cycles Well, is 2 (not pairable) versus 2 1/2 (not pairable) cycles..... However, with a manual re-ordering it could take only 1 cycle...8-)) Hope this clarify...... Cya PrZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

2 1

`push' instructions (was: Bug fixes)
by Peter Gerwinski 16 Jun '97

16 Jun '97

According to PredatorZeta: > > Just little clarifying.....:)) > No. Surely not on 80x86 machines. Look this (is for Pentium): > > 1 push (mem) take 2 cycles NOT pairable > > 2 a) mov (mem), reg take 1 cycle pairable > AGI Stall (1 cycle+cut off pairing > system) > b) push reg take 1 cycle pairable > > TOTAL: 3 cycles > > Well, is 2 (not pairable) versus 2 1/2 (not pairable) cycles..... > However, with a manual re-ordering it could take only 1 cycle...8-)) > > Hope this clarify...... Partially. As far as I understand the above, it's push (mem) 2 cycles not pairable mov (mem), reg 1 cycle pariable push reg 1 cycle pairable so both versions have the same speed, but the second one is pairable (-;whatever that means ... I guess it means that it is executed in parallel with a floating point operation, right?). So the second version would be potentially faster, but at least not slower. It seems that I have missed something ... Partially confused, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Encouragement
by Tom Dye 16 Jun '97

16 Jun '97

Hello all, I've been porting VAX Pascal and Borland Pascal code to gpc so that I can compile and run on my Linux box. This has been much easier than I thought it would be--mostly because gpc is an excellent compiler. Keep up the good work! Tom Thomas S. Dye, Ph.D. Home: 813 16th Avenue, Honolulu, Hawaii 96816. Voice (808) 734-2087. Work: International Archaeological Research Institute, Inc., 949 McCully St., Suite 5, Honolulu, Hawaii 96826. Voice (808) 946-2548; Fax 943-0716.

1 0

Re: `Word' data type et al.
by The African Chief 16 Jun '97

16 Jun '97

On Mon, 16 Jun 1997 15:25:56 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >Peter Gerwinski wrote: > >> I noticed a lot of confusion about Integer types in GNU Pascal. [...] >> 32 Integer Word [unsigned] int == long >> 64 LongInt LongWord [unsigned] long long >> >> (BTW: The number of bits is the same on all platforms, isn't it?) [...] > >> I was told more than once that `Word' should have 16 bits (like in >> Borland Pascal). I made it 32 bits because this is the "natural" >> size on a 32-bit system (like GPC), and it has the same size as >> `Integer' (like in Borland Pascal;-). > >I think this is a good idea. However, for BP compatibility one might >define Word as 16 bit in the bpcompat system unit or so, but this should >not be the gpc default, IMHO. In bpcompat's GPCTYPES unit, I have this; {$ifdef _Borland_16_Bit_} Type Single = __short__ Real; Double = Real; Extended = __long__ Real; ShortInt = __byte__ Integer; LongInt = Integer; Comp = __longlong__ Integer; Integer16 = __short__ Integer; Word = __unsigned__ Integer16; {$endif _Borland_16_Bit_} Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Bug fixes (was: "Recursion, need more stack space.")
by Peter Gerwinski 16 Jun '97

16 Jun '97

According to Frank Heckenbach: > > program p; > > var x:record > f:function:real; > end; > > begin > Writeln(x.f) > end. Fixed. > Another little bug I just found: > > program x; > var x:real value 0; {"initial value is of wrong type} > begin > end. Fixed. > Another thing I observed when looking at the asm code (see above) was > that the i386 backend doesn't seem to know the "push mem" instruction. Indeed. > [...] But since it's a backend problem > (the same can happen with gcc), this is probably the wrong place to > report it... Probably. However if you want to try yourself on that problem, look into the GCC info documentation, and read about "machine descriptions". There is something about how to describe each instruction a processor has, and maybe it's a trivial error and somebody overlooked this instruction. Or else: Loading the memory reference into a register and pushing that *might* be faster than a direct push (don't know). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: "Recursion, need more stack space."
by Frank Heckenbach 16 Jun '97

16 Jun '97

Jan-Jaap van der Heijden wrote: > > Guess what: the program compiled and ran fine with gpc, but couldn't > > possibly compile with BP. :-) > > > :-) :-) Pathetic 64K limits :-) :-) Not because of these, but because BP doesn't handle stacke frames with procedural parameters (variables). If it were only the 64kB limit, that's an old story, I wouldn't even have mentioned it here... > > Another little bug I just found: > > > > program x; > > var x:real value 0; {"initial value is of wrong type} > > begin > > end. > > > It's not a bug, I believe. > > From ISO 10206:1990, sec 6.1.7: > > unsigned-rel = digit-sequence `.' fractional-part [ `e' scale factor ] > | digits-sequence `e' scale factor I thought EP would allow arbitrary expressions as variable initializers (even things like sin(x+3), AFAIR). So an implicit integer->real conversion should be possible, too, I'd think. Even if the standard doesn't demand it, I think it's a good idea to have it in gpc. BTW: Isn't there are general rule like (sorry, I don't know the actual identifiers): real_value = integer_value | ... (IMHO, there should be. After all, as we mathematicians say, $\Z \subseteq \Q$ :-) > I see a simular definition in my Turbo pascal Programmer's Guide, so > BP should not accept it either. I'll look it up, but BP allows some kinds of expressions (e.g. (a+b)/2 if a and b are constants, not with variables, no sin, ...), so it seems logical to allow simple integers, too. > Try to make it "0.0" or "0e0" That's one of the (many) things I don't like about C... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

"Recursion, need more stack space."
by Frank Heckenbach 16 Jun '97

16 Jun '97

First the good news: in c.l.p.b (the same subject as this mail), someone wrote: "Anyway, I found this book in the library called "Programming Languages" by Herbert G.Mayor. In the book it has a program written in Algol-60 by Donald Knuth, which is highly recursive etc.etc, and it was written to separate the 'boy compilers' from the 'man compilers'. The book states, that modern computers are able to run the program with ease." Guess what: the program compiled and ran fine with gpc, but couldn't possibly compile with BP. :-) (It relies on nested stack frames handled correctly with procedural parameters. BP can't do this, but gpc does -- it's not trivial, and it took me some time to understand the asm code generated by gpc... :-) Now the bad news (not really so bad): I then modified the program to compile with BP (quite extensive modifications). The resulting program did not compile with gpc any more. I could trace it down to the following bug (which is actually not related to the problem that the program deals with). gpc doesn't compile the following which is legal in BP (gpc says: "wrong type" in the Writeln): program p; var x:record f:function:real; end; begin Writeln(x.f) end. Another little bug I just found: program x; var x:real value 0; {"initial value is of wrong type} begin end. (Also in other places, automatic integer->real conversion would be nice.) Another thing I observed when looking at the asm code (see above) was that the i386 backend doesn't seem to know the "push mem" instruction. E.g., the program program x; var a:integer value 2; begin writeln(a) end. compiled to asm code for i386-linux, contains the lines movl A.2,%eax pushl %eax where actually pushl A.2 is possible (I tried it, and it worked). But since it's a backend problem (the same can happen with gcc), this is probably the wrong place to report it... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

Re: Whats wrong?!?
by Frank Heckenbach 15 Jun '97

15 Jun '97

Peter Gerwinski wrote: > > Why is this correct? Isn't Text, being declared as an array of char, > > treated as a 0-terminated string, meaning that the #0 should not be > > printed? > > No. Text being declared as an array of char is treated as a string of > fixed length. The Standard doesn't say anything about 0-termination. > If GPC sometimes takes `chr ( 0 )' as the end of a string, this behaviour > is a remainder of the C back-end and should be reported as a BUG. > (I am not, however, speaking of `CString's (= `PChar's) which are a GNU > (resp. Borland) extension.) Then we have a conflict with BP (the first real one)-: ! The following writes '1.' with BP, and '1[#0]2.' with gpc (regardless of the state of --borland-pascal and --extended-syntax): program x; const a:array[0..3] of char='1'#0'2'#0; begin writeln(a,'.') end. Any ideas how to solve the conflict -- or how to do something equivalent to the BP meaning of this program in gpc at all? Do we need another compiler switch...? And, why is there no #0 output after the '2'? Is this a bug? Ooops, can't gpc write PChars at all? The following doesn't work: program x; {$x+} var a:PChar; begin writeln(a) end. Similarly, the following compiles with BP, but not with gpc: program x; {$x+} var a:PChar; begin a:='Test' {in BP: assign the address of the 0-terminated string 'Test'#0 (stored somewhere statically) to a} end. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

`Word' data type
by Peter Gerwinski 15 Jun '97

15 Jun '97

Hello, everybody! I noticed a lot of confusion about Integer types in GNU Pascal. As I wrote in "info -f gpc -n Integer", these are bits signed unsigned C equivalent 8 ByteInt Byte [unsigned|signed] char 16 ShortInt ShortWord [unsigned] short 32 Integer Word [unsigned] int == long 64 LongInt LongWord [unsigned] long long (BTW: The number of bits is the same on all platforms, isn't it?) I was told more than once that `Word' should have 16 bits (like in Borland Pascal). I made it 32 bits because this is the "natural" size on a 32-bit system (like GPC), and it has the same size as `Integer' (like in Borland Pascal;-). AFAIK, a "word" is defined to be the "natural" unit of the computer, but maybe this definition has changed since I have learned it. If the definition of a word is indeed "16 bits" now, I should change GPC's behaviour. In this case I would appreciate suggestions how to rename all GPC Integer types above (which I wouldn't like to do because I find the above quite consistent). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Type casting
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Orlando Llanes: > > Oh :} Sorry :} I briefly glanced at it, and what I saw was, for example: > > TYPE > ShortInt = __byte__ Integer; > Byte = __unsigned__ ShortInt; > VAR > AVar : Integer; > ASmallVar : Byte; > BEGIN > ASmallVar := BytePtr(AVar)^; > END. > > Something like that... Your program compiles well, if you add `Type BytePtr = ^Byte'. (But it crashes at run-time because you are accessing an uninitialized pointer variable.) > What I meant was type casting using custom types, not with built-in or > pre-defined types. If it already does this, sorry again :} It already does. ;-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: `Word' data type
by Orlando Llanes 14 Jun '97

14 Jun '97

I know that a byte is 8 bits, but I glanced at soemthing womewhere that the Mac's smallest size that it can process is 16 bits <shrug> Maybe I'm wrong? > You mean: 16 bits? One "Byte"? At least this is against all > definitions I ever saw in textbooks. I have an idea, perhaps there could be platform dependant types, for example: VAR MyVar : PCByte; This way it would be treated as 8-bits on all platforms, the natural types can stay, all one has to do is use the platform type to compensate for it if necessary. This way, 1) the data works consistently across all platforms because (for example) they know that a PCByte is 8 bits, 2) If a byte is a different size on another platform, then it doesn't matter because the PCByte is the same no matter where it's compiled. I guess this could be accomplished by making the PCByte a natural Byte, but in the code, anything above the 8 bits is not used. > It would not be difficult to implement a compiler switch (*$16-bit *) (or > ... > GPC, it should not be 16 bits, but 64 bits! -- See ya! Orlando Llanes

1 0

Re: Type casting (was: `Word' data type)
by Orlando Llanes 14 Jun '97

14 Jun '97

Oh :} Sorry :} I briefly glanced at it, and what I saw was, for example: TYPE ShortInt = __byte__ Integer; Byte = __unsigned__ ShortInt; VAR AVar : Integer; ASmallVar : Byte; BEGIN ASmallVar := BytePtr(AVar)^; END. Something like that... What I meant was type casting using custom types, not with built-in or pre-defined types. If it already does this, sorry again :} > > I think that there should be a compiler directive to generate code, or > > maybe typecasting should be implemented, in case someone writes data from > > 32-bit word to prevent it from being read into a 16-bit word. I like > > Borland Style Type-Casting because it's logical, for example: [...]

1 0

Re: `Word' data type
by Berend de Boer 14 Jun '97

14 Jun '97

Peter Gerwinski wrote: > bits signed unsigned C equivalent > > 8 ByteInt Byte [unsigned|signed] char > 16 ShortInt ShortWord [unsigned] short > 32 Integer Word [unsigned] int == long > 64 LongInt LongWord [unsigned] long long I suggest keeping yourself more closely with Borland Pascal and Delphi. And implement range to byte mapping i.e. if I define a range as 0..255 it should occupy only one byte. I suggest: bits signed unsigned C equivalent 8 shortint byte [unsigned|signed] char 16 smallInt Word [unsigned] short XX Integer cardinal [unsigned] int == long 64 LongInt LongWord [unsigned] long long where XX is platform dependent: natural sizes, so could be 16, 32 or 64, 128 bits, etc. Groetjes, Berend.

1 0

Debugging GPC (was: Problems with OBJECTs)
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Bernhard Tschirren: > > The program below causes a Segment Violation (SIGSEGV) during compilation > using GPC-970510 for DJGPP 2.01. > > [...] > > Procedure TObj.DisposeIndex; > > {$M START} > Procedure DisposeEntry(Var Entry:PEntry); > {$M STOP} > Begin > If (Entry <> Nil) Then > [...] Thanks for the precise bug report. This makes it easier to debug GPC. I don't know how long it took you to find that place, but GPC has a debugging option `-dY' to dump the source to `stderr' during compilation. Using this, you immediately see the location where GPC crashed. The bug, however, seems to be somewhat harder ... working on it ... Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Enumerated types bug!
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Bernhard Tschirren: > > Enumerated types are not exported in the GPI file. For example: [...] Fixed. :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: NOT A BUG Report :-)
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Bernhard Tschirren: > > Whew, this is not another bug report! :-0 Its a suggestion for a feature > that I'd like in GPC. :-) > Sometimes I have to link in 'C' (ugh) code with GPC. Usually this 'C' code > has been compiled into a ".a" library. Is there any way I can tell GPC to > automatically link this ".a" file with my program using automake? > [...] > Please tell me if Im setting my expectations of GPC a little too high :-) Too late: It's already implemented in my current development GPC. (-: (I see: It's really time for a new (beta) release (like promised), but before that I want to get rid of some really ugly bugs which only show up on a DEC Alpha. Since I don't have a DEC Alpha, it's not easy (and expensive)-; for me to hunt them.) To invoke this, wait till I eventually release the next beta; then say (*$L foo.o *) This has the same effect as an additional `foo.o' on the command line and should work with `foo.a' as well. In addition, (*$L foo.c *) has the same effect as (*$L foo.o *), except that - in combination with `--automake' - GPC tries to compile `foo.c' if `foo.o' does not exist or `foo.c' is younger than `foo.o'. Okay, so let me go on with GPC ... (* perhaps this weekend ... Daumen druecken! *) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: SERIOUS GPC BUG!!
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Bernhard Tschirren: > > Every time I compiled my programs with "-g" (debugging) the compiler crashed > with a SIGSEGV. With a bit of late-night detective-ing, I think I figured > WHY this happens! > > I managed to get an assembly dump of my program without the compiler > crashing. The "-g" option wrote ".def _(null) ... " to the assembly output. > Somehow, some NULL strings have crept into GPC.... :-( Whats even scarier is > that the number of _(null) defs varied between different compiles! That's a good hint for what kind of errors to look out; however it's hopeless to check all 2MB of GPC source code for NULL pointer dereferences ... ;-) and my own test programs are compiled with `-g -O3 -Wall' all the time. Could you please mail me a short test program which triggers the bug? Thanks in advance, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: `Word' data type
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Orlando Llanes: > > [...] On certain computers, > like the Macintosh I believe, a Byte is the size of a PC Word. You mean: 16 bits? One "Byte"? At least this is against all definitions I ever saw in textbooks. > I think that there should be a compiler directive to generate code, [...] It would not be difficult to implement a compiler switch (*$16-bit *) (or a command-line option `--16-bit') to make `Integer' and `Word' 16 bits etc., but I am not so sure that this is a good idea since GPC is a true 32-bit compiler. If we want to look out for a different "natural" data size for GPC, it should not be 16 bits, but 64 bits! Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Type casting (was: `Word' data type)
by Peter Gerwinski 14 Jun '97

14 Jun '97

According to Orlando Llanes: > > I think that there should be a compiler directive to generate code, or > maybe typecasting should be implemented, in case someone writes data from a > 32-bit word to prevent it from being read into a 16-bit word. I like > Borland Style Type-Casting because it's logical, for example: [...] Type casting *is* implemented. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

SERIOUS GPC BUG!!
by Bernhard Tschirren 13 Jun '97

13 Jun '97

If you look at the time stamp of this message you'll see that it was written at 2:30am. :-( I have just (hopefully) isolated a VERY SERIOUS GPC bug. Every time I compiled my programs with "-g" (debugging) the compiler crashed with a SIGSEGV. With a bit of late-night detective-ing, I think I figured WHY this happens! I managed to get an assembly dump of my program without the compiler crashing. The "-g" option wrote ".def _(null) ... " to the assembly output. Somehow, some NULL strings have crept into GPC.... :-( Whats even scarier is that the number of _(null) defs varied between different compiles! When "--automake" is enabled, the compiler crashes with a SIGSEGV. I dont think "AS" was ever invoked because it usually complains about those _(NULLS). I am using GPC-970510 for DJGPP 2.01. Now, I desperately need some sleep!! Good night :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: `Word' data type
by Orlando Llanes 13 Jun '97

13 Jun '97

Why not just make it 16 bits on the Intel platform? On certain computers, like the Macintosh I believe, a Byte is the size of a PC Word. > behaviour. In this case I would appreciate suggestions how to rename > all GPC Integer types above (which I wouldn't like to do because I find > the above quite consistent). When I was playing with GPC doing the Port inline assembly stuff, I delcared the types as follows: ... TYPE ShortInt = __byte__ Integer; { 8 bits } Int = __short__ Integer; { 16 bits } LongInt = __long__ Integer; { 32 bits } Byte = __unsigned__ ShortInt; { 8 bits } Word = __unsigned__ Int; { 16 bits } DWord = __unsigned__ LongInt; { 32 bits } ... Or soemthing to that effect. Altho I'd prefer to re-declare the Integer as a PC Integer, I didn't because I don't like overriding the default type. I think that there should be a compiler directive to generate code, or maybe typecasting should be implemented, in case someone writes data from a 32-bit word to prevent it from being read into a 16-bit word. I like Borland Style Type-Casting because it's logical, for example: VAR MyDword : DWord; MyLInt : LongInt; BEGIN MyLint := -23; LongInt( MyDword ) := MyLint; END. Not much of a logical example, but hopefully it shows you what I mean :} See ya! Orlando Llanes

1 0

Re: `Word' data type
by Bernhard Tschirren 13 Jun '97

13 Jun '97

At 05:24 PM 13/06/97 +0200, you wrote: >AFAIK, a "word" is defined to be the "natural" unit of the computer, >but maybe this definition has changed since I have learned it. If the >definition of a word is indeed "16 bits" now, I should change GPC's > DONT CHANGE IT! The word size of a computer is indeed the size of the "natural" unit that the computer works with. GPC is a 32-bit compiler for 32-bit machines (except the 64-bit ALPHAS) so the type "WORD" should be 32-bits! ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

NOT A BUG Report :-)
by Bernhard Tschirren 13 Jun '97

13 Jun '97

Whew, this is not another bug report! :-0 Its a suggestion for a feature that I'd like in GPC. Sometimes I have to link in 'C' (ugh) code with GPC. Usually this 'C' code has been compiled into a ".a" library. Is there any way I can tell GPC to automatically link this ".a" file with my program using automake? At the moment I have to type: GPC program.pas -o program.exe library.a --automake Is there any way another compiler define could be added into the source of a unit to tell automake that "library.a" must be linked with the program. Something along the lines of {$LINK "library.a"} or the Borlandish {$O libary.a} I know that this is REALLY DIFFICULT to do because the unit must somehow tell the calling GPC that it must also link the ".a" library. But something like this is already done using units... Please tell me if Im setting my expectations of GPC a little too high :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Exported Type BUG!
by Bernhard Tschirren 13 Jun '97

13 Jun '97

This is not really a serious bug because it only generates a warning and the code works OK. Its very complicating to explain, so just have a look at the (BIG) example below: {--TYPES.PAS-----------------------------------------------} Unit Types; Interface Type TRecord = Record Data : Word; End; Implementation End. {--PROC.PAS-----------------------------------------------} Unit Proc; Interface Uses Types; Procedure TheProc(Var Data:TRecord); Implementation Procedure TheProc(Var Data:TRecord); Begin End; End. {--BUG.PAS------------------------------------------------} Program Bug; Uses Types,Proc; Var Data : TRecord; Begin TheProc(Data); { Line 8 } End. {---------------------------------------------------------} The compiler spews out the following warning message when compiling: bug.pas: In function `program_Bug': bug.pas:8: warning: passing arg 1 of `Theproc' from incompatible pointer type {--------------------------------------------------------} The pointer is obviously NOT incompatible since its the SAME TYPE. As an aside: If "TheProc" is a method of an object, the compiler reports that the incompatible pointer type is passed in "arg 2" instead of "arg 1". :-) {--------------------------------------------------------} Now, this is what I call a bug report! Its HUGE, and the bug isnt even very serious! :-) Good Work ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Record Initialisers GONE WRONG!?!
by Bernhard Tschirren 13 Jun '97

13 Jun '97

Hmm, this is very strange! {---------------------------------------------------} Type TRecord = Record First : Word; Second : Word; End; Var Single : TRecord Value (10; 1000); { This works OK } Many : Array[1..2] Of TRecord Value ((10; 1000), { Does NOT compile! } (10; 1000)); Begin End. {---------------------------------------------------} I am using GPC-970510 for DJGPP 2.01. This might be a known bug since I read somewhere that arrays are not fully implemented yet. Cya l8r, and happy debugging :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Enumerated types bug!
by Bernhard Tschirren 13 Jun '97

13 Jun '97

WOW, Im on fire... I found another bug. I think this might a known bug. Enumerated types are not exported in the GPI file. For example: {---------------------------------------------------------------------} In TYPES.PAS: Unit Types; Type TDays = (Monday,Tuesday); ... In BUG.PAS: Uses Types; Var TheDay : TDays; { This is OK } Begin TheDay := Monday; { Monday is undefined! } End. {---------------------------------------------------------------------} Thanks ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Problems with OBJECTs
by Bernhard Tschirren 13 Jun '97

13 Jun '97

The program below causes a Segment Violation (SIGSEGV) during compilation using GPC-970510 for DJGPP 2.01. {-----------------------------------------------------------------------------} Type PEntry = ^TEntry; TEntry = Record Prev : PEntry; { Linked List } Data : Word; End; TObj = Object Index : PEntry; Procedure DisposeIndex; End; Procedure TObj.DisposeIndex; {$M START} Procedure DisposeEntry(Var Entry:PEntry); {$M STOP} Begin If (Entry <> Nil) Then Begin DisposeEntry(Entry^.Prev); Dispose(Entry); Entry := Nil; End; End; Begin DisposeEntry(Index); End; Begin End. {-----------------------------------------------------------------------------} The problem does not occur if the procedure "DisposeIndex" is NOT a method of an object. If "DisposeIndex" is declared as a normal procedure then the program compiles OK. WEIRD!?!? I narrowed the problem down to the definition of the nested procedure "DisposeEntry". The second {$M} is never displayed. Tschuess ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Inline Assembler Problems
by PredatorZeta 13 Jun '97

13 Jun '97

According to Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de>: > According to PredatorZeta: > > > > I receive the same invalid 386 instruction error message. > > Mmmh...I investigate on this. I have found this (probably) bug in the > > "as": > > > > movl $_TheArray(,%%esi,4), %%eax > > > > and > > > > movl %%eax, _TheArray(,%%esi,4) > > > > is accepted from the assembler without any problems. But sadly: > > > > movl %%eax, $_TheArray(,%%esi,4) > > > > is refused. If this isn't a bug, anyone know the reasons? > > I do not really know, but I guess that it's the following: > The `$' denotes a constant value, something without a `$' denotes > a memory reference. Not exatly, because $_TheArray is however an immediate value (displacement). The "AS" might accept this, because $_TheArray can be managed really as an immediate. Besides, logically if "movl $_TheArray(,%%esi,4), %%eax" is OK, movl %%eax, $_TheArray(,%%esi,4) MUST be OK. > But if it is so, I have problems to imagine > what "movl $_TheArray(,%%esi,4), %%eax" means ... except if the > `movl' is silently translated to a `leal'. > Could please somebody check it out? Here you are Peter! I have disassembled the object file outputted by "AS". "movl $_TheArray(,%%esi,4), %%eax" is showed in Intelly way as "mov eax, DWORD PTR [esi*4+_TheArray]" without any lea. More probably is an "AS" parsing problem. If it found an $ at the beginning of the DEST operand, it assume that you tried to move something in an immediate value, and emit the error message. But it isn't necessary an invalid opcode!!!! Cya. PrZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Speeding up GPC
by Peter Gerwinski 13 Jun '97

13 Jun '97

Hello, folks! I just compiled a Unit with a 5000-line interface part with GPC. 50 (fifty) seconds on a Pentium 166. :-( That's about a factor of 100 (!) slower than Borland Pascal 7.0 on the same host. :-( :-( Using (*$M Message *) directives, I found out that 90% of the time was spent in writing the GPI file (this is done when `Implementation' is read): Unit Foo; Interface (* ... Many constant definitions ... *) (*$M Writing GPI file ... *) Implementation (*$M GPI file written. *) (* ... other stuff *) end. I think I know already why this takes so long, so you can expect this bottleneck to vanish in the future. Now comes my request: Please help to find similar bottlenecks in GPC! To do so, you can compile your longer programs with the `-Q' option which makes GPC output the name of each function it compiles, and/or you can scatter (*$M message *) directives about your source like I did in the example above. As written in the DJGPP FAQ, GCC compiles 250 (-O2) to 430 (-O0) lines per second on an i486DX2-66. Since Pascal is stricter than C, GPC should not be slower! Thanks in advance, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Inline Assembler Problems
by Peter Gerwinski 12 Jun '97

12 Jun '97

According to PredatorZeta: > > I receive the same invalid 386 instruction error message. > Mmmh...I investigate on this. I have found this (probably) bug in the > "as": > > movl $_TheArray(,%%esi,4), %%eax > > and > > movl %%eax, _TheArray(,%%esi,4) > > is accepted from the assembler without any problems. But sadly: > > movl %%eax, $_TheArray(,%%esi,4) > > is refused. If this isn't a bug, anyone know the reasons? I do not really know, but I guess that it's the following: The `$' denotes a constant value, something without a `$' denotes a memory reference. It is okay to move the constant `$_TheArray' (i.e. the ADDRESS of `_TheArray') into a register, whereas it is not possible to store the value of the %%eax register in the constant `$_TheArray'. But if it is so, I have problems to imagine what "movl $_TheArray(,%%esi,4), %%eax" means ... except if the `movl' is silently translated to a `leal'. Could please somebody check it out? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Whats wrong?!?
by Peter Gerwinski 12 Jun '97

12 Jun '97

According to Frank Heckenbach: > > Why is this correct? Isn't Text, being declared as an array of char, > treated as a 0-terminated string, meaning that the #0 should not be > printed? No. Text being declared as an array of char is treated as a string of fixed length. The Standard doesn't say anything about 0-termination. If GPC sometimes takes `chr ( 0 )' as the end of a string, this behaviour is a remainder of the C back-end and should be reported as a BUG. (I am not, however, speaking of `CString's (= `PChar's) which are a GNU (resp. Borland) extension.) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Inline Assembler Problems
by Bernhard Tschirren 12 Jun '97

12 Jun '97

>BTW I found a new real problem. With: > >movl %%eax, $_TheArray(,%%esi,4) > >I receive the same invalid 386 instruction error message. >Mmmh...I investigate on this. I have found this (probably) bug in the >"as": > >movl $_TheArray(,%%esi,4), %%eax > >and > >movl %%eax, _TheArray(,%%esi,4) > >is accepted from the assembler without any problems. But sadly: > >movl %%eax, $_TheArray(,%%esi,4) > >is refused. If this isn't a bug, anyone know the reasons? > YES, YES!! Thats what Ive been talking about all along! I must make my english a bit more clear - sorry. Cya L8r ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Re: Inline Assembler Problems
by PredatorZeta 12 Jun '97

12 Jun '97

Hello, Bernhard Tschirren <bernie(a)icenet.com.au> You wrote: > > > Var > > TheArray : Array[0..99] Of Integer; {32-bit} > > Begin > > Asm(" > > ... Code ... > > movl _Index, %esi (*you must double % if > you use Ext. Asm*) > > movl $_TheArray(,esi,4), %eax > > ... Code ... > > "); > > End. > > DOHHH! I am an idiot! In my code I had the two operands switched around! The > assembler was telling me that I was using an invalid 386 instruction. Is the > following really illegal? > > movl %eax,$_TheArray(,esi,4) First of all: ESI must be preceding by an "%" symbol __ALSO__ if it is between the brackets (have you get my doc?). Without this the assembler always will tell you that you was using an invalid 386 instruction. Are you sure that your variables are __static__, too? BTW I found a new real problem. With: movl %%eax, $_TheArray(,%%esi,4) I receive the same invalid 386 instruction error message. Mmmh...I investigate on this. I have found this (probably) bug in the "as": movl $_TheArray(,%%esi,4), %%eax and movl %%eax, _TheArray(,%%esi,4) is accepted from the assembler without any problems. But sadly: movl %%eax, $_TheArray(,%%esi,4) is refused. If this isn't a bug, anyone know the reasons? > I LOVE the inline assembler, except for the 15 local label limit. I know I > can prefix locals with an 'L' except when the compiler inlines the codeit > creates duplicate labels. Is there any way around that? In my doc i wrote that the labels can be from 0 to f only because I don't use more than 15 local labels at time. But of course, if you want, you can use for example "16:" or "19:" for indicate a local label, and this work fine. That's all folks!! Cya, PrZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Re: Whats wrong?!?
by Frank Heckenbach 12 Jun '97

12 Jun '97

Peter Gerwinski wrote: > > WriteLn('*',Text,'*'); { Prints out with padded #0 } > > I think we agree that this is correct. (On Linux, the #0s don't appear > on the screen ... I suspect the operating system (or the "terminal") "eats" > them.) Why is this correct? Isn't Text, being declared as an array of char, treated as a 0-terminated string, meaning that the #0 should not be printed? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: String Array Bug!
by Peter Gerwinski 11 Jun '97

11 Jun '97

According to Bernhard Tschirren: > > I found another bug (hidden feature)! Take a look at the code snippet below: > [...] > For some reason, there are SPACES after CPUName! I am using GPC 970420 for > DJGPP 2.01. This bug does not show up with Linux, but with DJGPP - and only if _p_directvideo (a Boolean variable in the GPC RTS) is FALSE. I will have a look at this ... Thanks for the report, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Whats wrong?!?
by Peter Gerwinski 11 Jun '97

11 Jun '97

According to Bernhard Tschirren: > > WriteLn('*',Text,'*'); { Prints out with padded #0 } I think we agree that this is correct. (On Linux, the #0s don't appear on the screen ... I suspect the operating system (or the "terminal") "eats" them.) > WriteLn('*',Trim(Text),'*'); { Also prints out with padded #0 } ISO 10206 says - in a way I have problems to think of a more cryptic one - that the thing which is stripped from the String is "the character space". This implies that there must be exactly one "space" - #32. Or did I overlook something? > WriteLn('*',Asciiz2Str(Text),'*'); { Segment Violation } This is not correct, but it's an unrecognized problem in the source: A String without specified length cannot be returned as the result of a function. BP assumes 255 in this situation which is quite natural because it's BP's maximum size for Strings, but GPC does *not* assume 4G in this case ... but zero. :-( In my current development version, GPC warns about the problem and assumes 255 (like BP), but I do not recommend to rely on this. Better always specify a length for Strings to be returned by functions: "Type String255 = String ( 255 ); Function Foo: String255;". (Or even better: avoid to return Strings as function results at all; use "Var Foo: String" instead which *is* valid.) > Bye (Im having trouble coming up with unique greetings :-) Me too, ;-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Inline Assembler Problems
by Bernhard Tschirren 11 Jun '97

11 Jun '97

> Var > TheArray : Array[0..99] Of Integer; {32-bit} > Begin > Asm(" > ... Code ... > movl _Index, %esi (*you must double % if you use Ext. Asm*) > movl $_TheArray(,esi,4), %eax > ... Code ... > "); > End. DOHHH! I am an idiot! In my code I had the two operands switched around! The assembler was telling me that I was using an invalid 386 instruction. Is the following really illegal? movl %eax,$_TheArray(,esi,4) Now im doing it much nicer: Asm("... Code ... " "movl %0(,%1,4),%%eax " "... Code ... " : { No outputs } : "m" (TheArray), "r" (Index), : "eax"); I LOVE the inline assembler, except for the 15 local label limit. I know I can prefix locals with an 'L' except when the compiler inlines the code it creates duplicate labels. Is there any way around that? Thanks for your help ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Whats wrong?!?
by Bernhard Tschirren 11 Jun '97

11 Jun '97

The following does not work!?!? Is it a problem on my behalf or is it a GPC feature! :-) Function Asciiz2Str(Var InStr:{Packed} Array Of Char) : String; Var OutStr : String[255]; Index : Integer; Begin OutStr := ''; Index := 0; While (Index <= 255) And (InStr[Index] <> #0) Do Begin OutStr := OutStr + InStr[Index]; Inc(Index); End; Asciiz2Str := OutStr; End; Var Text : Packed Array[0..19] Of Char; Begin Text := 'Hello Word!'+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0; WriteLn('*',Text,'*'); { Prints out with padded #0 } WriteLn('*',Trim(Text),'*'); { Also prints out with padded #0 } WriteLn('*',Asciiz2Str(Text),'*'); { Segment Violation } End. Im using GPC 970420 for DJGPP 2.01. Im not very happy about the the Segmentation Violation. Also, it would be nice if the Trim cut out the trailing #0s, but this might break some programs... The first WriteLn is OK. Bye (Im having trouble coming up with unique greetings :-) ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

String Array Bug!
by Bernhard Tschirren 11 Jun '97

11 Jun '97

I found another bug (hidden feature)! Take a look at the code snippet below: PROGRAM: Type TStr10 = String[10]; Var CPUName : Array[0..5] Of TStr10 Value ('Unknown','80186','80286', '80386','80486','Pentium'); Var CPU : Integer; Begin For CPU := 0 To 5 Do WriteLn('*',CPUName[CPU],'*'); End. OUTPUT: *Unknown * *80186 * *80286 * *80386 * *80486 * *Pentium * For some reason, there are SPACES after CPUName! I am using GPC 970420 for DJGPP 2.01. Cya L8r ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

Help
by O. Patrick Barnes 11 Jun '97

11 Jun '97

I would appreciate help from anyone and everyone, if possible! I just downloaded the binary's to GPC for Win 95/NT. I then downloaded the cygwin.dll from ftp://ftp.cygnus.com/pub/gnu-win32/ I get a link error when I try to run any of the GPC programs. What have I installed wrong?! Any help will be appreciated! -Olan Patrick Barnes obarnes(a)online.emich.edu

2 1

Re: OOP
by The African Chief 11 Jun '97

11 Jun '97

On Tue, 10 Jun 1997 15:04:55 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> >As Pierre said: string comparison are less efficient than integer compares, >> >and generally I think *internal* things (i.e. things that must only be read >> >by computers, not by humans) should use integers rather than strings when >> >there's no real need for strings. Resource files, AFAIK, are binary files, >> >anyway, so what good would it be to have some strings scattered in them? >> >> Resource files (at least Windows resource files) can also hold strings in >> string tables. Most Windows programmers cannot do without these string >> tables. How would you represent the strings with integers? You need to >> store the actual strings in the resource file. > >That's something different! These strings (if I understood string tables >correctly) are actually to be read (or typed) by humans. Correct. > There's no question >that they must be stored as strings (unless, of course, one intentionally >wants to encrypt and/or compress them to make them unreadable in the binary). True. >But e.g. the IDs of the strings would be numerical (just as they are in >WinAPI/OWL, AFAIR). True. >> Would there be a problem if two or more programmers (unknown to each other) >> just happened to choose the same ID? [...] >If different programmers really happened to choose the same ID, it could >matter if they wanted to combine their sources (however, the compiler would >(should) notice this, so they could change the IDs, and they'd just have to >recompile everything once), or when they exchanged or shared data files >with these IDs in them (which, however, seems strange unless the sources >are combined, too). Suppose they put their code in dynamic linked libraries (meaning that any application that can load functions from such libraries can use the code) ? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Enumerated types
by Frank Heckenbach 10 Jun '97

10 Jun '97

Phil Nelson wrote: > Another problem ... it will make pred() and succ() harder if they must > do succ(Greater) => Strange and pred(Strange) => Greater. I think setting > the initial value would be reasonable, but not allowing a jump in the values. Another possibility would be to let succ (and inc) just increase the ordinal value by 1, then test (with the generic range checking procedure) if it's a valid ordinal value. I'm not sure if succ/inc are supposed to work this way or the other, what does the standard say? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: OOP
by Frank Heckenbach 10 Jun '97

10 Jun '97

The African Chief wrote: > >As Pierre said: string comparison are less efficient than integer compares, > >and generally I think *internal* things (i.e. things that must only be read > >by computers, not by humans) should use integers rather than strings when > >there's no real need for strings. Resource files, AFAIK, are binary files, > >anyway, so what good would it be to have some strings scattered in them? > > Resource files (at least Windows resource files) can also hold strings in > string tables. Most Windows programmers cannot do without these string > tables. How would you represent the strings with integers? You need to > store the actual strings in the resource file. That's something different! These strings (if I understood string tables correctly) are actually to be read (or typed) by humans. There's no question that they must be stored as strings (unless, of course, one intentionally wants to encrypt and/or compress them to make them unreadable in the binary). But e.g. the IDs of the strings would be numerical (just as they are in WinAPI/OWL, AFAIR). > Would there be a problem if two or more programmers (unknown to each other) > just happened to choose the same ID? As I described elsewhere, one could use some bits of the ID as a "programmer ID" and make it at least very improbable that ever two programmers would choose the same bits. Unless this would happen, all IDs by all programmers would automatically be different. > I am just asking, because I am not sure > whether this will affect anything else or not (it may very well not affect anything). If different programmers really happened to choose the same ID, it could matter if they wanted to combine their sources (however, the compiler would (should) notice this, so they could change the IDs, and they'd just have to recompile everything once), or when they exchanged or shared data files with these IDs in them (which, however, seems strange unless the sources are combined, too). -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: Inline Assembler Problems
by PredatorZeta 10 Jun '97

10 Jun '97

> A description of GPC's inline assembler was recently posted to this list > by somebody who calls himself "Predator Zeta". Hello boyz!! Do you want call me with my real name? :)) Well, is "Dario Angelo Anzani". Predator came from some Quake deadmatch that I did. ZzzZ stay for sleeper...8-))) >"StOp GrInNiNg AnD dRoP yOuR lInNeN...", so maybe you did not identify it >as something about assembler. ;-) In case you have lost that mail, you can I reveal the mystery: StOp GrInNiNg AnD dRoP yOuR lInNeN is a quote from an AC/DC song entitled "Shake a Leg". [album: Back In Black] There are no way to identify it as something about assembler, but I really like it.8-))) But OK, in the next release, the subject will be something like this: "Please read this message because I wrote an assembler doc and if you read it you can learn more about assembler. " This would be nice for those that push cancel BEFORE read the contents of message 8-X Here there is the snag corrected: > Var > TheArray : Array[0..99] Of Integer; {32-bit} > Begin > Asm(" > ... Code ... > movl _Index, %esi (*you must double % if you use Ext. Asm*) > movl $_TheArray(,esi,4), %eax > ... Code ... > "); > End. Cya. PrZ. -- [<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<] | Codename: PrEdAtOr~Z; Sex: Male; Status: Free coder | * E-mail: predatorzeta(a)geocities.com * | URL: http://www.geocities.com/SiliconValley/Vista/6573 | [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]

1 0

Re: Enumerated types
by Jakob Heinemann 09 Jun '97

09 Jun '97

Phil Nelson wrote: > > >type TComparisonResult=(Less value -1, Equals, Greater, Strange value 10); > > > >i.e. Ord(Less)=-1, Ord(Equals)=0, Ord(Greater)=1, Ord(Strange)=10. > > Another problem ... it will make pred() and succ() harder if they must > do succ(Greater) => Strange and pred(Strange) => Greater. I think > setting the initial value would be reasonable, but not allowing a > jump in the values. Only allowing to set the initial offset would make this kind of fetaure useless. Implementing succ and pred functions using a simple table will not cause much trouble. Imagine this (for me very actual) problem: Type assembler_instructions = ( add_x, sub_y, mul_a_x) ; (* course more complex*) register_type = ( ax, bx, dx, bc, de, hl ); objectfile = record ai : assembler_instruction; p1, p2 : register_type; end; (* using some ada-style for making the example *) for assembler_instructions use ( add_x => 27, sub_y => 37, mul_a_x => 127); for register_type use ( ax => 12, bx => 22, dx => 32, bc => 01, de => 17, hl => 33); The ord-function will, assuming you order the register-names in a simple index only cause code to extract the real ord number from a table, i.e. ord_values : array (.enumeration_type.) of integer; (* the array keeping the values*) Just suggesting :) /Jakob :) mailto:Jakob.Heinemann@ericsson.com Ericsson Saab Avionics AB Linköping +46 13 284249

1 0

Re: Inline Assembler Problems
by Peter Gerwinski 09 Jun '97

09 Jun '97

According to Bernhard Tschirren: > > I've hit a little snag - I cant convert one type of Intel instruction to the > AT&T format. Take a look at the example below: > [...] > I couldnt figure out how to code the memory reference! A description of GPC's inline assembler was recently posted to this list by somebody who calls himself "Predator Zeta". (The subject was "StOp GrInNiNg AnD dRoP yOuR lInNeN...", so maybe you did not identify it as something about assembler. ;-) In case you have lost that mail, you can retrieve it in the GPC Mailing list archive at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/misc/gpc-list.1997.gz but you can also directly download the information from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/gpcasm.zip Your problem is discussed in chapter 3 (snippet below). Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125] 8< --------------------------------------------------------------------------- - 3. Memory addressing - Intel: SELECTOR : [BASE + INDEX*SCALE + DISPLACEMENT] AT&T: SELECTOR : DISPLACEMENT (BASE, INDEX, SCALE) If you are able to decypher the scheme above, you are perfectly able to master memory addressing. If you couldn't grasp the meaning, go on reading this short explanation: -The SELECTOR, for both formats, must be in the first position. The SELECTOR is expressed by means of a segment register(CS,DS,ES,SS,GS or FS) and CANNOT be an immediate value. If the selector used by the instruction is the default one(ES for StoS, SS for stack opcodes, DS/ES for MovS and DS for all the other one), you must omit both the register AND the colon. -The BASE value is, for example, the address of the first element of an array. In the Intel format it is placed as the first element into the square braces. Can be any one of the general purpose registers. -The INDEX value represents, to continue the previous example, the index of an array. BASE + INDEX gives the address in memory of the INDEXth element of the array starting at BASE. INDEX should also be any one of the general purpose registers and can be modified by a scaling factor... -The SCALE is an immediate value, choosen from 2, 4 or 8. When computing the address, INDEX is multiplied by SCALE, so that if our beloved array has elements made up of 2, 4 or 8 bytes, we can address them directly. -The DISPLACEMENT, at last, is a costant immediate value to be added to the final address. Usually, the most common addressing schemes involve BASE & DISPLACEMENT or BASE & INDEX: it's very unlikely to find all of them in one opcode. Mov EAX, DWord PTR FS:[EBX] <===> MovL %FS:(%EBX), %EAX Mov EDI, DWord PTR [ECX+EBX*2] <===> MovL (%ECX,%EBX,2), %EDI Mov EAX, DWord PTR [12345678h] <===> MovL 0x12345678, %EAX Mov EBX, DWord PTR GS:[EDX*2] <===> MovL %GS:(,%EDX,2), %EBX Mov EAX, DWord PTR [ECX+12345h] <===> MovL 0x12345(%ECX), %EAX Mov EDI, DWord PTR ES:[12345h] <===> MovL %ES:0x12345, %EDI Mov BX, Word PTR [_MyVar] <===> MovW (_MyVar), %BX Now for some highlights: Have a look at the third example: did you notice that in the AT&T syntax there is no dollar sign("$") preceding the value 0x12435678? That's perfectly right... if you look at the Intel syntax, you'll notice that it is a memory reference, not an immediate value: _In AT&T syntax, __EVERY__ immediate value WITHOUT a dollar sign preceding it is considered a memory reference_ Now, what about the forth example? Is that comma in the right place? The answer is YES, and it is very important to understand why. In this opcode the BASE is null. If we omitted the comma, the assembler would have guessed wrong and would have produced this: Mov EBX, DWord PTR GS:[EDX] <===> MovL %GS:(%EDX,2), %EBX The "2", mistaken for a scale, would have been discarded and EDX would have been the only register to be considered... a BAD error indeed! __ALWAYS__ put 3 commas between the braces, whatever you want to do!

1 0

Re: Enumerated types
by Frank Heckenbach 09 Jun '97

09 Jun '97

Peter Gerwinski wrote: > If everybody agrees that there should be an extension like this in GPC: > It's probably not so hard to implement. Suggestions for the syntax? > Objections against it? Why not? If it's not too much work to do. Could it be a problem if Ord(EnumVal)<0 ? I don't see any. Suggestion: type TComparisonResult=(Less value -1, Equals, Greater, Strange value 10); i.e. Ord(Less)=-1, Ord(Equals)=0, Ord(Greater)=1, Ord(Strange)=10. Disadvantage: Range checking will get more difficult. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

Re: Enumerated types
by Dr E. Buxbaum 09 Jun '97

09 Jun '97

> > Is it possible to specify the value of an enumerated type? I was trying > to > > port a C header file which did something like this: > > > > typedef enum hello_everybody { > > hello_error = -1, > > hello_first = 0, > > hello_second, > > hello_third > Can this be done with GPC? I am noot quite sure what you whant to do here. Under Pascal you can write: type Hello_Everybody = (Hello_error, Hello_first, Hello_second, Hello_third); and then use the ORD function to get their numerical value. ORD(Hello_Error) would be 0, ORD(Hello_First) 1 and so on. This would be an enumerated type. The other option would be a record (similar to a C struct): type Hello_Everybody = record Hello_Error, Hello_First, Hello_Second, Hello_Third : integer; end; In this case you could assign any integer value you like to any of the records field, while in the case of enumeration types the ORD-value is given by the order of definition. Hope that helps

2 1

Inline Assembler Problems
by Bernhard Tschirren 09 Jun '97

09 Jun '97

I am -trying- to port a program to GPC which uses some inline INTEL assembler. Its protected mode already so it should be easy to port... Well, that what I thought!!! I've hit a little snag - I cant convert one type of Intel instruction to the AT&T format. Take a look at the example below: Var TheArray : Array[0..99] Of LongInt; {32-bit} Begin Asm ... Code ... mov esi,Index mov eax,[TheArray+esi*4] { THIS is the offending opcode } ... Code ... End; End. I couldnt figure out how to code the memory reference! I cannot move the address of 'TheArray' into a register and use that because I dont have any available registers - the code is already written (not by me) and I DO NOT want to rewrite it. The current code copiles OK using TMT Pascal (ugh). So Im positive that its not an illegal memory reference. Could somebody please help me... Thanks ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

CygWin32 and BPCompat
by The African Chief 09 Jun '97

09 Jun '97

Hi all, I have just succeeded over the weekend to compile SYSTEM.PAS, STRINGS.PAS, AND OBJECTS.PAS with CygWin. This has required some $IFDEFs and the addition of some new functions, just for CygWin - (so, AFAIK, the SYSTEM unit in BPCompat now compiles correctly under DJGPP, EMX, Linux, and CygWin - any other successes?) One thing which I am missing is the Win32 API in Pascal. Has anyone translated any of the CygWin32 C headers (esp. any Win32 API calls) to GPC? I would like to start a collection of these. Better still, is anyone willing to write a program that will parse a CygWin32 C headers and generate a GPC unit from it? Thanks. PS: I have found that many things are different under CygWin from the rest (e.g., the "stat" structure; the "errno", which is implemented as a macro); and many things which are in standard C headers are missing (e.g., strlwr(), strupr(), stricmp, etc.). Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

2 1

Re: CygWin32 and BPCompat
by The African Chief 09 Jun '97

09 Jun '97

On Mon, 9 Jun 1997 12:09:21 +0100 (WET DST) Jan-Jaap van der Heijden <janjaap(a)Wit381304.student.utwente.nl> wrote: > >I have converted just enough headers to be able to compile a basic GUI >application, where you do all the message handling yourself (no object >windows available :-( No sweat about object Windows (something can be done about that later). Can you please send me a copy of your converted headers? Thanks. There is no point in duplicating efforts, and I don't want to reinvent the wheel. >I did this for cygwin32 b16. Then I focussed more on the unix ascpects for >some time, but now I have a b18 GPC compiler, and I'm working on some >cygwin32 things (DLL's, building the RTS as a DLL etc.) I'm not sure that >function attibutes survive through the GPI mechanism (they didn't for >b16) so using units may not be possible. Well, I could simply "$INCLUDE" the sources - which is what I did when I first started using GPC anyway. > You need the >"__attribute__((stdcall))" feature to access win32 API functions. Yes, I saw this in some of the sample programs. >Building DLL's on doze95 is difficult (not just for GPC) in b18. >NT seemed fine, but my NT machine crashed a HD this weekend :-( Ooops! >> PS: >> I have found that many things are different under CygWin from the rest >> (e.g., the "stat" structure; the "errno", which is implemented as a macro); >> and many things which are in standard C headers are missing (e.g., >> strlwr(), strupr(), stricmp, etc.). >> > >cygwin32 is basically BSD. >I don't know about the unix (?) that cygwin32 differs from in your opinion, I was actually comparing it to the emx and djgpp headers - which I suppose I shouldn't. I didn't know that cygwin32 was based on BSD. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: OOP
by The African Chief 09 Jun '97

09 Jun '97

On Sun, 8 Jun 1997 17:03:09 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >Peter Gerwinski wrote: > >> > BTW: Do TV programs actually rely on the zeroing out, or is this just a >> > paranoia initialization? >> >> They do. > >Bad style! Well, at least then there should be a BIG warning in the BPCompat >objects.pas not to use the library with long strings or other schemata or >any initalized fields... The objects.pas unit in BPCompat does not zero out things. It actually does some "proper" initialisation :-) So, this is a place where I need to add some "!!!" comments to point out the differences with BP. >> I don't think it's so bad: Strings are more flexible than Integers. I really >> like to index a `RessourceFile' (in TV) with Strings ... > >As Pierre said: string comparison are less efficient than integer compares, >and generally I think *internal* things (i.e. things that must only be read >by computers, not by humans) should use integers rather than strings when >there's no real need for strings. Resource files, AFAIK, are binary files, >anyway, so what good would it be to have some strings scattered in them? Resource files (at least Windows resource files) can also hold strings in string tables. Most Windows programmers cannot do without these string tables. How would you represent the strings with integers? You need to store the actual strings in the resource file. >A different thing would be textual "resource" files (e.g. like Windoze .ini >files): for such things it can be useful to have a string ID (class name), >with the compiler switch we discussed, *additionally*, but I think the >primary ID should be an integer. (BTW: It might seem that string IDs are >"more unique" than integer IDs, but I think the opposite is the case: many >programmers will write some "TEdit" class (or "TWindow", "TString", ...), >but with integer IDs there are no problems if they choose a unique >programmer ID first.) Would there be a problem if two or more programmers (unknown to each other) just happened to choose the same ID? I am just asking, because I am not sure whether this will affect anything else or not (it may very well not affect anything). Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.60 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Re: Enumerated types
by Orlando Llanes 09 Jun '97

09 Jun '97

I translated a C program to Pascal once that had enumerated types, and in order to use typedefs like that, you need to re-arrange and improvise. What I did was put all enums as constants and set them to their appropriate values. You might be able to use $define's to acheive the desired effect. ---------- > Is it possible to specify the value of an enumerated type? I was trying to > port a C header file which did something like this: > > typedef enum hello_everybody { > hello_error = -1, > hello_first = 0, > hello_second, > hello_third > ... > > Can this be done with GPC?

1 0

Re: OOP
by Frank Heckenbach 08 Jun '97

08 Jun '97

Peter Gerwinski wrote: > Now suppose, the index 'EditImportantData' were an Integer, say 42. Of > course, there would be a constant declaration `Const EditImportantData = 42' > in some Unit, so the call would be the same but two apostrophies. Okay. > But now we introduce more dialogs which are thematically related to > the 'EditImportantData' dialog, e.g. 'EditEvenMoreImportantData'. A natural > choice for a numeric constant for it would be 43, but that's busy already. > So we can either change *all* numerical constants and recompile the whole > application or declare `Const EditEvenMoreImportantData = 3742' - whatever > is free - which invites for errors when forgetting which numbers represent > which dialogs. As I said, IDs must be chosen with a little more sophisticated mechanism. Since nobody told us anything about these Delphi/Windoze things, I'm just suggesting something. Let's say the ID is a 64 bit integer (if Delphi has 128 bit, that might be more compatible, but I don't know...). So let's say 32 of these 64 bits are a unique programmer ID. The other 32 bits can be used by the programmer as (s)he chooses. So you could use 16 bits as a unique unit ID (I guess you won't write more than 65536 units in your life), and 16 bits as a unique ID per unit (max. 65536 classes per unit). No renumbering necessary ever, even if you included someone else's sources! :-) So you could declare: const JHackerID=$E94F561A00000000; {Your ID, declared once, globally} const JEditorID=JHackerID+$12000000; {For each project} const EditUnitID=JEditorID+$240000; {For each unit} const EditCommandsID=ThisUnitID+$1000; {For each "kind" of IDs} const EditImportantData=EditCommandsID+42; You may or may not need either or all of project or unit level or "kinds" of IDs, that's any programmer's own choice. > > Object(...)[StringID,NumID] > > Why not? Looks reasonable ... Fine! :-) Then we've only got to decide about the size of the NumID. I think 64 or 128 bits are reasonable, but which? > (* However I still think it is the job of the library, not the compiler, > to provide such IDs. *) But typing "const ClassName:^String value @'EditImportantData';" is not very convenient, is it? (Apart from the fact that the syntax "@'...'" doesn't work, does it? So it would be even more complicated to declare, or one would have to use a CString.) Besides, a check for duplicate NumIDs could only be done at runtime. :-( So the compiler could help a little. Since it's only optional (it will not be linked in if not used), I see no disadvantage. > Delphi users: Please help us poor guys to understand how Delphi works, > then there is a chance that you can have all these nice features in GPC, > too, one day. Yes, please! > > In which class, and pointer to which class? Sure, a pointer to TObject could > > do anything, but would require type casts (which I consider bad style), or > > absolute declarations (even worse). > > Think of a large, well-established library. Now somebody wants to modify for > some unexpected situation. Then the programmer (i.e. the user of the library) > can either directly add fields whereever appropriate - then communication with > other applications which use the same library might become complicated - or > use these "hook" fields. I don't understand. Adding fields without code that accesses the new fields doesn't do anything. So if you add the new fields, you'll also have to provide new methods, won't you? So you'll have to derive new classes with the new methods, and those classes get the new fields. That's what one would do normally. > GCC has such extension fields at a number of places: For example, each > structure which represents a "type definition" has one "pointer" field > pointing to a "struct lang_decl" which must be defined by the language > front-end using the GCC back-end. We use this, for example, to store an > additional integer in the type definition node which tells whether something > is a String, a Schema, an Object, a variant Record, or just an ordinary type > - plus some pointers holding Object inheritance information and Schema > discriminants. > > Of course, this could have been achieved by deriving a successor object, > because this happens in the "highest level" of an "object hierarchy": there > are no "successor objects" of the "type definition object". But if there > were, inheritance would not work any more - this "hook" field still would. What kind of successors? AFAICS, these different types (Strings, Schemata, Object, variant Record, ...) *are* the natural descendants of the abstract type "TType". Can you give me an example of another "orthogonal" inheritance? If it is specific only to one language, this language would declare an abstract successor of "TType" with the "hook", which would probably be more specific than just "PObject" then. Other languages wouldn't have the hook. That's one of the main ideas behind OOP: not having to provide "holes" for any unknown future extensions, but being able to add what's needed when it's needed. > I agree that this would be nice, and I think that this would not be as hard > to implement as one would expect on the first guess. (Frank, it's a similar > thing as your suggested `iftype' for accessing variable argument lists.) I know, but AFAIR there wasn't much response to this suggestion. But with objects it seems easier to do than with normal types. > What does The Standard say about this? Actually, which standard? Do you mean Object Pascal? How much does gpc comply to this standard at all? (Up to now, we've only oriented on BP and some ideas of our own, haven't we?) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Machine Code...
by Orlando Llanes 08 Jun '97

08 Jun '97

I was wondering if there was a way to insert Machine Code into a GPC Program. The reason is that I'm trying to duplicate Borland Pascal's Port array by using 2 functions, one for port input, one for port output. My problem is that when I type "asm( 'inb %al, %dx' );" the compiler says "386 instruction not recognized" I tried using an INLINE statement, that didn't work either, I even tried "asm( '$EC' );" which is the machine code equivalent, still nothing, then I tried "asm( 'db $EC' );" which didn't do it either. I understand that GPC was meant to be cross platform, but I need port access. I also know that I could link it externally, but I don't want to have to do that unless it's absolutely necessary :( Thanks in advance! See ya! Orlando Llanes

2 1

Re: Procedural types
by Peter Gerwinski 08 Jun '97

08 Jun '97

According to Bernhard Tschirren: > > The GPC procedural types do not allow VAR parameters! I looked through all > the documentation but couldn't find any way of doing it - other than using > pointers. You mean: *Pointers* to procedures like implemented in gpc-2.0- don't allow `Var' parameters. Recent alpha versions allow both pointers to procedures with `Var' parameters as well as BP-stype "procedural variables": Type MyProc = Procedure ( Var x: Real ); MyProcPtr = ^Procedure ( Var x: Real ); (* `Var' parameter *) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Exit extension.
by Peter Gerwinski 08 Jun '97

08 Jun '97

According to Bernhard Tschirren: > > I have always missed (in BP) an extension to Exit in the form of > Exit(RetValue), just like C's return. GPC has `Return ( RetValue )'. :-), Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Enumerated types
by Peter Gerwinski 08 Jun '97

08 Jun '97

According to Bernhard Tschirren: > > Is it possible to specify the value of an enumerated type? AFAIK, this is not possible. Enumerated types are used whenever something abstract is needed where the numeric value does not matter. > I was trying to > port a C header file which did something like this: > > typedef enum hello_everybody { > hello_error = -1, > hello_first = 0, > hello_second, > hello_third > ... I would translate it into a forest of constants. If everybody agrees that there should be an extension like this in GPC: It's probably not so hard to implement. Suggestions for the syntax? Objections against it? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: OOP
by Peter Gerwinski 08 Jun '97

08 Jun '97

According to Frank Heckenbach: > > As Pierre said: string comparison are less efficient than integer compares, > and generally I think *internal* things (i.e. things that must only be read > by computers, not by humans) should use integers rather than strings when > there's no real need for strings. Resource files, AFAIK, are binary files, > anyway, so what good would it be to have some strings scattered in them? BO4 has the following `ExecDialog' procedure: Function ExecDialog ( Index: String; Data: Pointer ): Word; It gets the dialog from the resource file at index `Index' and lets it work on the data pointed to by `Data'. The return value is the command the user entered to leave the dialog. It's quite similar to TV's ExecDialog, except that you don't pass a pointer to the dialog but an index to the resource file - the object's ID. A typical call: Var MyImportantData: record foo, bar: Real; end (* MyImportantData *); if ExitDialog ( 'EditImportantData', @MyImportantData ) <> cmCancel then UpdateEverything; Now suppose, the index 'EditImportantData' were an Integer, say 42. Of course, there would be a constant declaration `Const EditImportantData = 42' in some Unit, so the call would be the same but two apostrophies. Okay. But now we introduce more dialogs which are thematically related to the 'EditImportantData' dialog, e.g. 'EditEvenMoreImportantData'. A natural choice for a numeric constant for it would be 43, but that's busy already. So we can either change *all* numerical constants and recompile the whole application or declare `Const EditEvenMoreImportantData = 3742' - whatever is free - which invites for errors when forgetting which numbers represent which dialogs. > [...] > > So both IDs could coexist peacefully... :-) > > Syntax proposal: > > Object(...)[StringID,NumID] Why not? Looks reasonable ... (* However I still think it is the job of the library, not the compiler, to provide such IDs. *) > [QueryInterface, etc. ...] Delphi users: Please help us poor guys to understand how Delphi works, then there is a chance that you can have all these nice features in GPC, too, one day. > In which class, and pointer to which class? Sure, a pointer to TObject could > do anything, but would require type casts (which I consider bad style), or > absolute declarations (even worse). Think of a large, well-established library. Now somebody wants to modify for some unexpected situation. Then the programmer (i.e. the user of the library) can either directly add fields whereever appropriate - then communication with other applications which use the same library might become complicated - or use these "hook" fields. > > [Example: GCC compiler back-end ...] > > Sorry, I don't really feel like wading through 100kB of C code now, but I > guess they put in the "unused" fields because they're emulating objects -- > for lack of an inheritance mechanism that allows to add fields when they're > really needed. So I don't see how this would apply to gpc OOP. GCC has such extension fields at a number of places: For example, each structure which represents a "type definition" has one "pointer" field pointing to a "struct lang_decl" which must be defined by the language front-end using the GCC back-end. We use this, for example, to store an additional integer in the type definition node which tells whether something is a String, a Schema, an Object, a variant Record, or just an ordinary type - plus some pointers holding Object inheritance information and Schema discriminants. Of course, this could have been achieved by deriving a successor object, because this happens in the "highest level" of an "object hierarchy": there are no "successor objects" of the "type definition object". But if there were, inheritance would not work any more - this "hook" field still would. > [Implicit type cast with `is' operator ...] > > I don't know how difficult this is to implement, but it would be a nice > feature. E.g., in a program I have some situations like: I agree that this would be nice, and I think that this would not be as hard to implement as one would expect on the first guess. (Frank, it's a similar thing as your suggested `iftype' for accessing variable argument lists.) What does The Standard say about this? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc