Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited


Community Reputation

0 Neutral

About White-Elephant

  • Rank
  • Birthday 01/01/01
  1. ISO Modula-2 Documentation

    Hi, Does anyone know where we can get printable documentation concerning ISO Modula-2? We have the PIM books from Wirth but these don't desctibe the ISO enhancements. A reasonably priced book or PDF to print & search would be very helpful. For example, is there any way to tell ISO Modula-2 that variables are volatile? Ahlan
  2. XDS-C Fatal F450

    We were using a Modula-2 compiler for Motorola Mc68332 produced by the company HiWare. We are interested in converting our Modula to ANSI C so that we can eventually port the application to other hardware (probably Coldfire) Note TRANRAM should be a constant pointer. Ahlan
  3. XDS-C Use of constant pointers

    Hi, When we absolutely place a variable in modula we would expect this to result in a constant pointer rather than a normal pointer. The difference being that constant pointers can be loaded into ROM whereas normal pointers are allocated space in RAM and then have to be initialized by copying their initial values from ROM. This wastes RAM and presents a problem in initial setup code that wants to access these pointers before the chip selects have been programmed for the RAM or the RAM copy procedure has run. For example, in modula MODULE Example; FROM SYSTEM IMPORT ADDRESS; VAR TRANRAM1 [ADDRESS(0FFFFFD20H)] : CARDINAL; BEGIN TRANRAM1 := 42; END Example. currently produces static unsigned long *TRANRAM1 = (unsigned long *)(X2C_ADDRESS)0x0FFFFFD20u; X2C_STACK_LIMIT(100000l) extern int main(int argc, char **argv) { X2C_BEGIN(&argc,argv,1,2000000l,4000000l); *TRANRAM1 = 42ul; X2C_EXIT(); return 0; } whereas better would be static unsigned long *const TRANRAM1 = (unsigned long *)(X2C_ADDRESS)0x0FFFFFD20u; ie * const TRANRAM1 instead of * TRANRAM1 How can we tell XDS to generate constant pointers? Shouldn't this be the default if the output is ANSI-C? Ahlan
  4. XDS-C Fatal F450

    TRANRAM is used by other modules which is why it is placed in the def Using a variable pointer to access it not only requires that we alter all the code that accesses this memory mapped device but adds an extra level of redirection thereby making the code less efficient. If this is a compiler bug what are the chances of it getting fixed? Can we somehow pay for it to be fixed? Ie is there a level of support we can purchase that will enable us to get minor compiler bugs corrected? Ahlan
  5. XDS-C E202

    Hi, When compiling the following small example we get the message XDS Modula-2 v2.40 [ANSI C v4.20] - build 10.05.2005 Compiling "Fatal_2.Mod" * [*** 0.00 E202] * integer overflow in constant expression errors 1, no warnings, lines 3, time 0.03 we compile using xm +m2addtypes +m2extensions +nooptimize Fatal_2.Def xm +m2addtypes +m2extensions +nooptimize Fatal_2.Mod > Fatal_2.Err Fatal2.def DEFINITION MODULE Fatal_2; FROM SYSTEM IMPORT ADDRESS; VAR SCDR [ADDRESS(0FFFFFC0FH)] : CHAR; END Fatal_2. Fatal2.mod IMPLEMENTATION MODULE Fatal_2; END Fatal_2. We really don't see what is wrong with this. Curiously if we repplace CHAr with our own type BYte = Set of [0..7]; then it compiles Ok. Any ideas what we are doing wrong?
  6. XDS-C Fatal F450

    Hi, When compiling the following very small modula-2 example we get the message XDS Modula-2 v2.40 [ANSI C v4.20] - build 10.05.2005 Compiling "Fatal.Mod" * [*** 0.00 F450] * compilation aborted: type guard check which we don't understand. Any ideas what we are doing wrong? We compiled by: xm +m2addtypes +m2extensions +nooptimize Fatal.Def xm +m2addtypes +m2extensions +nooptimize Fatal.Mod > Fatal.Err Fatal.Def DEFINITION MODULE Fatal; FROM SYSTEM IMPORT ADDRESS; TYPE TransferArea = ARRAY [0..15] OF CARDINAL; VAR TRANRAM [ADDRESS(0FFFFFC00H)] : TransferArea; END Fatal. Fatal.Mod IMPLEMENTATION MODULE Fatal; END Fatal.