home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 8 / FreshFishVol8-CD2.bin / bbs / dev / oberon-a-1.4ß.lha / Oberon-A / texts / C2Oberon.txt next >
Text File  |  1994-05-28  |  18KB  |  420 lines
  1.      $RCSfile: C2Oberon.txt $
  2.   Description: Hints for converting C code into Oberon
  3.  
  4.    Created by: fjc (Frank Copeland)
  5.     $Revision: 1.2 $
  6.       $Author: fjc $
  7.         $Date: 1994/05/13 19:26:48 $
  8.  
  9.   Copyright © 1994, Frank Copeland.
  10.   This file is part of Oberon-A.
  11.   See Oberon-A.doc for conditions of use and distribution.
  12.   ________________________________________________________________________
  13.  
  14.   [This document is only partly complete (there was more, but DME ate it).
  15.   :-(  It is here because what there is might still be useful.  It will be
  16.   finished for a future release. FJC]
  17.  
  18.   Introduction
  19.   ------------
  20.  
  21.   This document contains advice for translating source code written in C
  22.   into Oberon.  It covers both simple syntax conversion and broader,
  23.   program organisation issues.
  24.  
  25.   C and Oberon both belong to the same tradition of imperative, procedural
  26.   languages that trace their origins back to Algol in the late 1950's.
  27.   They are both general purpose languages and are sufficiently low-level
  28.   that they can be used as system-programming languages (C is more
  29.   conciously directed to this use).  Where they mainly differ is in the
  30.   areas of modularity and type safety; Oberon is stronger in both these
  31.   areas.
  32.  
  33.   In most cases the syntaxes are similar enough to allow a straightforward
  34.   translation from one language to the other.  A text editor with a macro
  35.   facility can help simplify this task.  Difficulties arise when
  36.   encountering constructs common in C which are missing in Oberon, such as
  37.   union types and unsigned integers.  Other, more subtle difficulties may
  38.   arise as a result of C's less strict (often non-existant) type checking.
  39.   Finally, C's approach to modular programming is completely different to
  40.   Oberon's, and may require a complete restructuring of the source code.
  41.  
  42.  
  43.   Simple Data Types
  44.   -----------------
  45.  
  46.   Simple data types are the basic building blocks of all data structures.
  47.   As they are determined by the underlying architecture common to almost
  48.   all modern computers, C and Oberon have a very similer range of basic
  49.   types.  However, while the ANSI C standard specifies minimum sizes and
  50.   ranges for all of these types, Oberon leaves much more up to the
  51.   implementor.  The equivalences given are those for Amiga C compilers and
  52.   the Oberon-A compiler.
  53.  
  54.   The following table helps to explain the equivalences:
  55.  
  56.   ANSI C         Min. Size  Oberon-A
  57.   ------         ---------  --------
  58.  
  59.   char           1 byte     When used to hold ASCII values, the equivalent
  60.                             is CHAR; when used as a small integer, the
  61.                             equivalent is SHORTINT.
  62.   unsigned char  1 byte     When used to hold ASCII values, the equivalent
  63.                             is CHAR; when used as a small integer, the
  64.                             equivalent is BYTE.  For BYTE see below.
  65.   short          2 bytes    INTEGER.
  66.   int            2 bytes    INTEGER or LONGINT.  Some C compilers have
  67.                             16-bit ints, others have 32-bit ints.  For
  68.                             16-bit ints, use INTEGER, otherwise use
  69.                             LONGINT.
  70.   unsigned int   2 bytes    No equivalent.  See below.
  71.   long           4 bytes    LONGINT.
  72.   unsigned long  4 bytes    No equivalent.  See below.
  73.   float          6 digits   REAL.
  74.   double         10 digits  LONGREAL.
  75.   long double    10 digits  LONGREAL.
  76.  
  77.   The BYTE type is strictly limited in Oberon (it is removed in Oberon-2).
  78.   It may be used to represent an unsigned byte-sized value (0-255), but
  79.   the only operation allowed is assignment.  To perform arithmetic on BYTE
  80.   values, you must first assign them to INTEGER variables.
  81.  
  82.   Oberon does not allow for unsigned integers apart from the limited BYTE
  83.   type.  In many cases this is no problem since a signed integer can be
  84.   used instead without problems, although it may be necessary to use a
  85.   larger type (INTEGER instead of SHORTINT, for instance).
  86.  
  87.   The main problem occurs when you must specify a type with the same
  88.   size as the unsigned type; this often occurs when declaring Oberon
  89.   equivalents for the Amiga system data structures.  You cannot use a
  90.   larger type in this case; the system WILL crash if you do.  Often the
  91.   operating system defines unsigned constants to be placed in these
  92.   variables with values that are larger than the maximum for a signed
  93.   integer of that size. These must be converted to negative values using
  94.   this formula:
  95.  
  96.     <constant> - (<max value of unsigned type> + 1).
  97.  
  98.   For example:
  99.  
  100.     An unsigned int constant 0xFFFE or 65534 converts to:
  101.  
  102.       (65534 - (65535 + 1)) = -2.
  103.  
  104.   Often unsigned integers are used as bit fields, which are directly
  105.   equivalent to the Oberon SET type.  An unsigned char bit field is
  106.   equivalent to the SYSTEM.BYTESET type; an unsigned int is equivalent to
  107.   the SYSTEM.WORDSET type; an unsigned long corresponds to the SET type.
  108.   If the exact size of the variable doesn't matter, use the SET type; the
  109.   other two types are unique to the Oberon-A implementation and are not
  110.   portable.
  111.  
  112.   C has no direct equivalent to Oberon's BOOLEAN type, but ints are often
  113.   used for the same purpose.  When they are, a value of zero equates to
  114.   FALSE and any other value equates to TRUE.
  115.  
  116.   Oberon has no equivalent to C's enumerated data types, but they can be
  117.   simulated very easily using integer constants.  For instance:
  118.  
  119.     enum days = { Sun,Mon,Tues,Wed,Thurs,Fri,Sat };
  120.  
  121.   becomes:
  122.  
  123.     CONST
  124.       Sun = 0; Mon = 1; Tues = 2; Wed = 3;
  125.       Thurs = 4; Fri = 5; Sat = 6;
  126.  
  127.  
  128.   Constant values
  129.   ---------------
  130.  
  131.   Character literals in C are defined using single quotes: 'a', 'Z', etc.
  132.   String literals use double quotes: "This is a string".  Oberon uses
  133.   double quotes for both.  This can create an unexpected difficulty.
  134.   Oberon has no way of distinguishing a string literal with a single
  135.   character in it from a character literal except from the context in
  136.   which it is used.  If the compiler does not contain special code to deal
  137.   with the anomaly, perfectly legal code may generate errors.  (Oberon-A
  138.   now handles this anomaly).
  139.  
  140.   String and character literals in C may contain escape sequences such as
  141.   '\n' and "\x5c".  Oberon does not recognise escape sequences (but
  142.   Oberon-A does, as an extension; see OC.doc.)  Character literals in
  143.   Oberon may be expressed as hexadecimal ASCII codes instead: '\n' becomes
  144.   0AX.
  145.  
  146.   In C, any numeric literal starting with "0x" or "0X" is a hexadecimal
  147.   value.  Upper and lower case characters can be used for the hexadecimal
  148.   digits.  Oberon uses an "H" character at the end of the literal to
  149.   indicate a hexadecimal number and hex digits must be in upper case.  A
  150.   number must start with a numeric character, the same as in C.  Example:
  151.   "0xa5d3" becomes "0A5D3H".  Any integer constant in C starting with "0"
  152.   (except for hex constants, obviously) is interpreted as an octal number.
  153.   Oberon has no equivalent for this and the constant must be converted
  154.   into its decimal or hexadecimal equivalent.
  155.  
  156.   A "U" at the end of an integer constant indicates an unsigned number.
  157.   Oberon has no equivalent for this (see above).  An "L" at the end of an
  158.   integer constant indicates that it has a long int type.  This is
  159.   unnecessary in Oberon, which handles all the necessary type conversions
  160.   automagically.
  161.  
  162.   Floating point constants are generally defined the same way in C and
  163.   Oberon, except that an exponent must be indicated with an uppercase "E"
  164.   in Oberon.  C constants usually are of type double; Oberon defaults to
  165.   type REAL.  To specify a LONGREAL constant, Oberon uses a "D" in the
  166.   exponent instead of an "E".  C uses an "L" at the end of a floating
  167.   point constant to indicate it is a long double type; remove this when
  168.   converting to Oberon.
  169.  
  170.   Bit field constants in C are usually defined in one of two ways.  One is
  171.   to use the form: "(1<<bit)" or "(1L<<bit)".  This is equivalent to
  172.   Oberon's: "{bit}".  The other is to use a hex literal, such as:
  173.   "0xC801".  The only way out here is to determine which bits are set in
  174.   the binary representation of the number, remembering that bits are
  175.   numbered st