Frank Heckenbach wrote:
Adriaan van Os wrote:
Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now.
: + chk_dialect ("ellipsis parameters are", GNU_PASCAL | MAC_PASCAL);
Just MAC_PASCAL is enough. GNU_PASCAL is assumed for all features, and named explicitly only if no other dialects apply.
OK.
BTW, "ellipsis parameters" here refers to external declarations for C compatible varargs routines such as
procedure p (foo: Integer; ...); external;
Does Mac Pascal really support this?
It does (I were equally surprised to find this feature in GPC).
(Note that GPC only allows declaration of such routines, not implementation of them. If MP does, how does implementation of them work there, BTW?)
Declaration of external C routines only, e.g. the following system routine in Mac OS Classic
function CallUniversalProc( theProcPtr: UniversalProcPtr; theProcInfo: ProcInfoType; ... ): Int32;
: - if (co->pascal_dialect & C_E_O_M_PASCAL) : + if (co->pascal_dialect & C_E_O_PASCAL) : build_predef_call (p_CaseNoMatchError, NULL_TREE);
Peter N. Lewis added Mac Pascal here in his original patch for MP dialect support (2003-03-31). Could you please make sure which one is correct?
This addresses a problem reported recently on the macpascal mailing list. In MPW, Think and MW Pascal, it is not an error if the case selector value matches no case constant (so I believe Peter was wrong).
Waldek Hebisch wrote:
Adriaan van Os wrote:
Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now.
I see one problem with the diff:
"-fignore-garbage-after-dot",
"-flongjmp-all-nonlocal-labels", "-fno-mixed-comments","-flongjmp-all-nonlocal-labels" has nothing to do with the dialect. I understand that it make sense to make "-flongjmp-all-nonlocal-labels" default on Mac OSX, but I is very confusing if dialect options change generated code, especially if it is a workaround for backend bugs.
I see.
The new gpc builds and passes the testsuite on powerpc-apple-darwin.
A few places in the source of the gpc compiler are unclear to me. They include:
- predef.c line 423 chk_dialect ("direct access to files without declared domain is",
B_D_PASCAL);
Extended Pascal standard allows direct acces to files only if you declare an index type like:
var direct_file : file [0..Maxint] of char;
OK, we can add another patch (change B_D_PASCAL to B_D_M_PASCAL here also).
predef.c line 713
flags = (co->pascal_dialect & (CLASSIC_PASCAL_LEVEL_0 |
CLASSIC_PASCAL_LEVEL_1)) ? NEG_ZERO_WIDTH_ERROR_MASK : (co->pascal_dialect & E_O_PASCAL) ? NEG_WIDTH_ERROR_MASK : (co->pascal_dialect & B_D_PASCAL) ? 0 : NEG_WIDTH_LEFT_MASK;
From `rts/constants.h':
#define NEG_ZERO_WIDTH_ERROR_MASK 8 COMMENT ((give an error when field width < 0)) #define NEG_WIDTH_ERROR_MASK 16 COMMENT ((give an error when field width < 0)) #define NEG_WIDTH_LEFT_MASK 32 COMMENT ((left adjusted output when the field width < 0))
There was a disscusion how GPC should handle negative width specification for `Write'. The code above implements results of the disscusion.
OK, I will have a further look.
expressions.c line 124
chk_dialect ("string concatenation without `Concat' or `+'
is", B_D_PASCAL);
That line check for thins like this:
program hell; begin writeln('Hell' 'o World') end
This is not supported by MW Pascal.
Thanks for the explanations.
Regards,
Adriaan van Os