mirror of
https://github.com/vishapoberon/compiler.git
synced 2026-04-05 23:22:25 +00:00
Some more significant ReadMe work.
This commit is contained in:
David C W Brown
parent
a359e16ae9
commit
b495b2725c
15 changed files with 148 additions and 2997 deletions
|
|
@ -1,3 +1,18 @@
|
|||
The following Oberon types are independent of compiler size:
|
||||
|
||||
| Types | Size |
|
||||
| ----- | -------|
|
||||
| CHAR, SHORTINT | 8 bit |
|
||||
| REAL | 32 bit |
|
||||
| LONGREAL | 64 bit |
|
||||
|
||||
The following type sizes follow the built compiler size:
|
||||
|
||||
| Types | 32 bit builds | 64 bit builds |
|
||||
| ----- | ------------- | ------------- |
|
||||
| INTEGER | 16 bit | 32 bit |
|
||||
| LONGINT, SET | 32 bit | 16 bit |
|
||||
|
||||
HALT/exit code has been simplified. Exit now just calls the system exit API rather than calling the kill API and passing our own process ID. For runtime errors it now displayes the appropriate error message (e.g. Index out of range).
|
||||
|
||||
Compilation errors now include the line number at the start of the displayed source line. The pos (character offset) is still displayed on the error message line. The error handling code was already doing some walking of the source file to find start and end of line - I changed this to walk through the source file from the start identifying line end positions, counting lines and caching the position at the start of the last error line. The resultant code is simpler, and displays the line number without losing the pos. The performance cost of walking the source file is not an issue.
|
||||
|
|
@ -6,4 +21,3 @@ Compilation errors now include the line number at the start of the displayed sou
|
|||
- In his latest specs (around 2013) Wirth removed the 'COPY(a, b)' character array copy procedure, replacing it with 'b := a'. I have accordingly enabled 'b := a' in voc as an alternative to 'COPY(a, b)' (COPY is still supported.).
|
||||
|
||||
- Oberon code often writes to Oberon.Log expecting the text to appear on the screen. While voc has an Oberon.DumpLog procedure, I looked into making the behaviour automatic. Interestingly the voc source declares the Text notifier constants replace, insert and delete, but omits implementation of the notifier calls. The implementation turned out to be very little code, and I have used it to echo all text written to Oberon.Log to the console. This has the advantage over DumpLog that text is written immediately rather than only when DumpLog is called, and allows existing program source to work unchanged.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,6 @@
|
|||
### History
|
||||
|
||||
|
||||
#### Changes from 1.2 to 2.0
|
||||
|
||||
The biggest changes relative to Vishap Oberon 1.2 are in the build system and in the implementation of platform specific support. Where possible platform specific code has removed or replaced by platform agnostic code.
|
||||
|
|
@ -104,5 +107,3 @@ Linux is currently compiled using PlatfromUnix.Mod, but the integration of Windo
|
|||
|
||||
##### Issue 14 - 'separate rtl from SYSTEM?'.
|
||||
OS specific code is now all in Platformxxx.Mod. Memory management (including the loaded module list) is now in Heap.Mod. SYSTEM.h is platform independent, with minimal ifdefs to allow compiling on all platforms. For example, when SYSTEM.h/SYSTEM.c need to allocate memory, or to halt, they call into Platform.Mod.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,9 +5,9 @@
|
|||
|
||||
#### Building and installation summary
|
||||
|
||||
1. git clone https://github.com/dcwbrown/olang
|
||||
2. cd olang
|
||||
3. make full
|
||||
1. git clone https://github.com/vishaps/voc
|
||||
2. cd voc
|
||||
3. [sudo] make full
|
||||
|
||||
Since 'make full' will install the compiler and libraries, it needs root (unix) or administrator (windows) privileges.
|
||||
|
||||
|
|
@ -24,14 +24,6 @@ Since 'make full' will install the compiler and libraries, it needs root (unix)
|
|||
The size of compiler built is determined by the C compiler that runs, which is in turn determined by
|
||||
the shell or command prompt configuration you are running under.
|
||||
|
||||
The following Oberon types are independent of compiler size:
|
||||
|
||||
| Types | Size |
|
||||
| ----- | -------|
|
||||
| CHAR, SHORTINT | 8 bit |
|
||||
| REAL | 32 bit |
|
||||
| LONGREAL | 64 bit |
|
||||
|
||||
The following type sizes follow the built compiler size:
|
||||
|
||||
| Types | 32 bit builds | 64 bit builds |
|
||||
|
|
@ -102,37 +94,6 @@ And select
|
|||
|
||||
More / Administrative Command Prompt
|
||||
|
||||
#### A 'Hello' application
|
||||
|
||||
Anything appended to Oberon.Log is automatically displayed on the console, so the
|
||||
following conventional Oberon program will display 'Hello.':
|
||||
|
||||
MODULE hello;
|
||||
IMPORT Oberon, Texts;
|
||||
VAR W: Texts.Writer;
|
||||
BEGIN
|
||||
Texts.OpenWriter(W);
|
||||
Texts.WriteString(W, "Hello."); Texts.WriteLn(W);
|
||||
Texts.Append(Oberon.Log, W.buf)
|
||||
END hello.
|
||||
|
||||
Alternatively the Console may be accessed directly as follows:
|
||||
|
||||
MODULE hello;
|
||||
IMPORT Console;
|
||||
BEGIN
|
||||
Console.String("Hello."); Console.Ln;
|
||||
END hello.
|
||||
|
||||
Compile as follows:
|
||||
|
||||
voc hello.mod -m
|
||||
|
||||
The -m parameter tells voc that this is a main module, and to generate an
|
||||
executable binary.
|
||||
|
||||
Execute as usual on Linux ('./hello') or Windows ('hello').
|
||||
|
||||
#### How make adapts to each platform
|
||||
|
||||
On all platforms other than Visual C on Windows, make runs from a bash shell,
|
||||
|
|
|
|||
|
|
@ -1,39 +1,78 @@
|
|||
==how to port to a new platform==
|
||||
0) generate voc.par file for the target platform(if it does not exist in src/par).
|
||||
you can do it by compiling vocparam, and running it as "./vocparam > voc.par"
|
||||
1) generate voc, ocat, showdef source for target platform by running
|
||||
make -f makefile.gcc.<arch> port0
|
||||
(or copy corresponding voc.par to the source directory yourself, remove stage2 from port0 section of the makefile, and run make port0)
|
||||
2) transfer source to a target platform and write
|
||||
make port1
|
||||
(or use a crosscompiler)
|
||||
now you have voc, showdef, and ocat binaries for your target platform
|
||||
3) cp voc vocstatic
|
||||
make -f makefile for your target.
|
||||
that's how I've done x86 port.
|
||||
voc was originally run on x86_64.
|
||||
### Porting to a new platform
|
||||
|
||||
notes** in practice everything is not always simple, because you may need to edit Unix.Mod, Args.Mod and SYSTEM.h, and put them to src/lib/system/gcc/<yourtarget>, and create new makefile for your target.
|
||||
Porting to a new 32 or 64 bits platform is usually automatically handled
|
||||
by `make full`:
|
||||
|
||||
- The makefile compiles `src/tools/make/configure.c` with the
|
||||
platform's default C compiler.
|
||||
- `configure.c` determines which types to use for 32 and 64 bit
|
||||
variables, and their alignment.
|
||||
- `configure.c` uses a number of strategies to determine the
|
||||
operating system it is running on and what the appropriate
|
||||
installation directory will be.
|
||||
- `configure.c` sets makefile variables that are used to select
|
||||
which of 5 sets of preprepared C source files to build to create
|
||||
the bootstrap compiler.
|
||||
|
||||
On most systems this will be sufficient for `make full` to build
|
||||
and install the compiler and libraries.
|
||||
|
||||
`make full` will terminate with a message such as:
|
||||
|
||||
`--- Branch v2docs freebsd gcc LP64 confidence tests passed ---`
|
||||
|
||||
#### Updating configure.c
|
||||
|
||||
It should only be necessary to change `configure.c` if it
|
||||
cannot determine the correct install directory.
|
||||
|
||||
In this case add code to `src/tools/make/configure.c`'s
|
||||
function `determineOS()` to set the `os` variable to the name
|
||||
of the new OS platform.
|
||||
|
||||
The following variables are also set by `determineOS()` to the
|
||||
followind defaults:
|
||||
|
||||
variable | set to | example
|
||||
-------- | ------ | -------
|
||||
`platform` | Base platform | `"unix"`
|
||||
`binext` | Binary file extension | `""`
|
||||
`staticlink` | Static linking option | `"-static"`
|
||||
|
||||
If your new platform does not support static removing, set the
|
||||
`staticlink` variable to `""`.
|
||||
|
||||
Then modify `determineInstallDirectory()` to select the correct
|
||||
instalation root based on the changes you have made to `determineOS()`.
|
||||
|
||||
The `platform` variable selects which variety of the Platform
|
||||
module is compiled. Vishap provides two varieties, one specific
|
||||
to the Windows API (`Platformwindows.Mod`), and one suitable for
|
||||
Unix-like systems including Linux, BSD, Android and cygwin
|
||||
(`Platformunix.Mod`).
|
||||
|
||||
|
||||
==how to add a new option==
|
||||
#### How to add a new compiler option
|
||||
|
||||
define it in OPM as a constant before defopt is defined.
|
||||
define a BOOLEAN variable in OPM which will describe if setting is set.
|
||||
add handling of a new option in OPM.ScanOptions
|
||||
set your BOOLEAN value in OPM.OpenPari (or in ScanOptions, after the CASE) so you can check it later.
|
||||
check your boolean when necessary, (see useParFile in OPM.GetOptions)
|
||||
add it in OPC.GenHeaderMsg function.
|
||||
- Define it in OPM as a constant before defopt is defined.
|
||||
- Define a BOOLEAN variable in OPM which will describe if setting is set.
|
||||
- Add handling of a new option in OPM.ScanOptions
|
||||
- Set your BOOLEAN value in OPM.OpenPari (or in ScanOptions, after the
|
||||
CASE) so you can check it later.
|
||||
- Check your boolean when necessary, (see useParFile in OPM.GetOptions)
|
||||
- Add it in OPC.GenHeaderMsg function.
|
||||
|
||||
==known bugs==
|
||||
#### Known bugs
|
||||
|
||||
when using SYSTEM.LSH(s, n) where s is SET,
|
||||
c compiler generates an error like
|
||||
"error: duplicate 'unsigned'",
|
||||
When using SYSTEM.LSH(s, n) where s is SET,
|
||||
the C compiler generates an error like
|
||||
`error: duplicate 'unsigned'`,
|
||||
that's because SET is defined as unsigned in SYSTEM.h,
|
||||
while LSH is defined in SYSTEM.h as ((t)((unsigned t)(x)<<(n))),
|
||||
while LSH is defined in SYSTEM.h as ((t)((unsigned t)(x)<<(n))),
|
||||
and it makes not possible to make SYSTEM.LSH with type SET.
|
||||
I don't want to prohibit it at the parser level
|
||||
|
||||
I don't want to prohibit it at the parser level
|
||||
because C backend is only one of possible backends.
|
||||
|
||||
The solution currently is to cast set type to longint before lsh-ing it.
|
||||
And then casting it back to set if necessary.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue