vishapoberon/compiler
1
0
Fork 0
mirror of https://github.com/vishapoberon/compiler.git synced 2026-04-05 23:22:25 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Minor documentation updates.

Browse source
This commit is contained in:
David Brown 2016-11-02 12:12:59 +00:00
parent c63bc9e093
commit 668c2ef508
2 changed files with 22 additions and 45 deletions
Download patch file Download diff file Expand all files Collapse all files

40
doc/Porting.md
View file

@ -1,8 +1,6 @@
#### (Work in progress)
### Porting to a new platform
Porting to a new 32 or 64 bits platform is usually automatically handled
Porting to a new 32 or 64 bit platform is usually automatically handled
by `make full`:
- The makefile compiles `src/tools/make/configure.c` with the
@ -13,7 +11,7 @@ by `make full`:
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
which of 5 sets of pre-prepared C source files to build to create
the bootstrap compiler.
On most systems this will be sufficient for `make full` to build
@ -23,10 +21,11 @@ and install the compiler and libraries.
`--- 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.
Most likely you will only need 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
@ -41,7 +40,7 @@ variable | set to | example
`binext` | Binary file extension | `""`
`staticlink` | Static linking option | `"-static"`
If your new platform does not support static removing, set the
If your new platform does not support static linking, set the
`staticlink` variable to `""`.
Then modify `determineInstallDirectory()` to select the correct
@ -53,28 +52,7 @@ to the Windows API (`Platformwindows.Mod`), and one suitable for
Unix-like systems including Linux, BSD, Android and cygwin
(`Platformunix.Mod`).
If you are porting to a system that does not provide a Unix style API, it will
be necessary to implement a new variant of Platform.Mod providing the same
interface as Platformunix.Mod and Platform Windows.Mod.
#### 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.
#### Known bugs
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))),
and it makes not possible to make SYSTEM.LSH with type SET.
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.