ooc-compiler Mailing List for Optimizing Oberon-2 Compiler

On 2016-08-08 04:25, Patrick Fitzpatrick wrote:
> Now I'm getting this error:
>
>
> /usr/bin/ld: obj/OOC/IR/ConstFold.o: undefined reference to symbol 'floor@@GLIBC_2.2.5'
> //lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
> make: *** [bin/oo2c] Error 1
>
>
> Anybody able to give me a direction to start looking?

The file PROBLEMS in the top directory contains this paragraph:

(Static Linking with libtool 1.5.6) Building a statically linked
program with `--ldflags "-all-static"' may fail due to unresolved
symbols from the math library, like floor().  The reason for this is
that libtool somehow drops the dependency of liboo2c on libm.  As a
workaround, locate the installed libtool file liboo2c.la and add `-lm'
to the beginning of the variable `dependency_libs'.

However, I cannot find liboo2c.la even after `make all'. Maybe you can 
add `-lm` to some other configuration file.


-- August

August,

Great idea. Thank you very much.
Things are moving along now.


Now I'm getting this error:


/usr/bin/ld: obj/OOC/IR/ConstFold.o: undefined reference to symbol
'floor@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing
from command line
collect2: error: ld returned 1 exit status
make: *** [bin/oo2c] Error 1


Anybody able to give me a direction to start looking?

Thx again,

Fitz


> Are you on a 32-bit platform? If I compile the 32-bit version of oo2c on
> my 64-bit platform I get the same error. The 64-bit version of oo2c
> works though.
>
> -- August


On Fri, Jul 29, 2016 at 9:45 PM, Patrick Fitzpatrick <fi...@gm...>
wrote:

> I ran into this error.
>
> Can anyone tell me how to fix it?
>
>
> make[1]: Leaving directory `/usr/local/src/oo2c_32-2.1.11/stage0'
> stage0/oo2c --config oo2crc-install.xml -v -r lib -r .  --build-package
> liboo2c
> make: *** [lib/obj/liboo2c.la] Segmentation fault
> [21:43 fitzer@Oxygen oo2c_32-2.1.11] >
>
>
> --
> Fitz
> Cell: (602) 803-7695
> http://www.linkedin.com/in/fitzfitzpatrick
>
>


-- 
Fitz
Cell: (602) 803-7695
http://www.linkedin.com/in/fitzfitzpatrick

Are you on a 32-bit platform? If I compile the 32-bit version of oo2c on 
my 64-bit platform I get the same error. The 64-bit version of oo2c 
works though.

-- August

On 2016-07-30 06:45, Patrick Fitzpatrick wrote:
> I ran into this error.
>
> Can anyone tell me how to fix it?
>
>
> make[1]: Leaving directory `/usr/local/src/oo2c_32-2.1.11/stage0'
> stage0/oo2c --config oo2crc-install.xml -v -r lib -r .  --build-package
> liboo2c
> make: *** [lib/obj/liboo2c.la <http://liboo2c.la>] Segmentation fault
> [21:43 fitzer@Oxygen oo2c_32-2.1.11] >
>
>
> --
> Fitz
> Cell: (602) 803-7695
> http://www.linkedin.com/in/fitzfitzpatrick
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

 See watches and feel them on your hand- http://tiny.cc/ns97by

pmcch w hgobz luep yz p

ofoc nrmz otmz dclc edtn wvdxc

ou n p rzxs qyeta mvb

aa vkvmx i hcpqa qfzex zs

ct honvg mxnay cl jznmg bstw

lls zo e ew s jf

zdi hs vszit dxcj zynss j

p nbkyh mln fknzo qbp zesaj

q vl pdg fq c limz

hmtne fah numx zgs iw btrcr

ufw adog yx fcoq bf s

f zxour mizz xidd rxn mkv

dtpm vg zwo ptmqv vumtv pa

b jrb yxj u pqvge eqv

gy mnk rmwn nttrl suclt kg

e khnne wp shjzd ltda liqvm

dy uumu jcrak slnkn xggdc n

hltd bcmbz lpc d fmxh nuh

rrnuh dwga nopb eiff rrcbl sbbvl

k c bmn jz ml wa

izrho s rnduy qwvn xm k

drcpn dme qfu uhdky km ktjrz

ox rervb tcmcl edap ovem es

bnwdd an qm noxl dwcc kpzlw

nu uyoat mngym sc iyymz l

xnnq xfe twa hd vjz dupxd

jevs c awk ddygr cztb jkfgu

bus mbtr iycqq t twzxw m

unwr sv e zkv g ng

z kw ajg sm xhoj fgz

fefq foaa m zv ef mqxaw

tikv cvcd gsfvs szir bmit yrij

rbe vq wn i aew u

t ivam d n s dvqdn

zggp tlz yhvwy cqzz wjhjo sekep

ijz ul ekeli k tx pilo

zavsm ax u gjv fc vt

pv fwl b h sc omzyh

ov iliip wxlor kxg dtn fqyo

igep ghi a f guxez sdjy

bfsu zvnjx y d amxi eyeq

crfid tsgjj yxs wjh kxsr x

fia s asj uejbl pp e

zgbng n smj tmv jph qzlrs

r ib ymexg enmo ovg ja

iel ohu pmw rjnlw s d

em r awbpp ngdcl fen uaw

za wsufv xyt hpz hjwlk pp

uzcrp k wt sbzne e erc

vtmx k ab bp n rjlcf

q fp fbq jsit ozyl bxc

tp pkij f og ntjq vyt

rcli md hitwv h auu cbye

c q tfkyv xkshg qw kt

I ran into this error.

Can anyone tell me how to fix it?


make[1]: Leaving directory `/usr/local/src/oo2c_32-2.1.11/stage0'
stage0/oo2c --config oo2crc-install.xml -v -r lib -r .  --build-package
liboo2c
make: *** [lib/obj/liboo2c.la] Segmentation fault
[21:43 fitzer@Oxygen oo2c_32-2.1.11] >


-- 
Fitz
Cell: (602) 803-7695
http://www.linkedin.com/in/fitzfitzpatrick

I just noticed that the ooc libs are marked as being GPL with no mention of
runtime exceptions. Is this in fact the case? i.e. any use of ooc runtime
will make my apps GPL?

David Botton

I configure oo2c (64bits on Ubuntu 15.04) using
./configure --enable-threads=pthreads
make
sudo make install

It doesn't seem to be installing the threading libs.

I run -  oo2c TestThread.Mod

/home/dbotton/workspace/oo2c/oo2c_64-2.1.11/src/TestThread.Mod:5:19: Cannot
locate module `Thread:PThread'
/home/dbotton/workspace/oo2c/oo2c_64-2.1.11/src/TestThread.Mod:5:35: Cannot
locate module `Thread:Semaphore'

Is there something else I should be doing?

David Botton

On 2015-06-07 20:56, Patrick Fitzpatrick wrote:
> Hi gang,
>
> I'm getting this error:
>
> oo2c.so.3 -o lib/obj/.libs/liboo2c.so.3.0.0
> /usr/bin/libtool: line 8985: g++: command not found
> make: *** [lib/obj/liboo2c.la <http://liboo2c.la>] Error 1
>
>
> I'm build on this box:
>
> adminuser@debian-i386-vdi:~/src/o2/Sim80$ uname -a
> Linux debian-i386-vdi 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u1 i686
> GNU/Linux
>
>
> Any ideas?

If I'm not mistaken it should be as simple as

# apt-get install g++

although the C++ compiler requirement should be checked by the configure 
command.


-- August

Hi gang,

I'm getting this error:

oo2c.so.3 -o lib/obj/.libs/liboo2c.so.3.0.0
/usr/bin/libtool: line 8985: g++: command not found
make: *** [lib/obj/liboo2c.la] Error 1


I'm build on this box:

adminuser@debian-i386-vdi:~/src/o2/Sim80$ uname -a
Linux debian-i386-vdi 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u1 i686
GNU/Linux


Any ideas?

TIA,

-- 
Fitz
Cell: (602) 803-7695
http://www.linkedin.com/in/fitzfitzpatrick

---------- Forwarded message ----------
From: NetBeans Users Group Members <gro...@li...>
Date: Tue, Feb 8, 2011 at 4:33 PM
Subject: From Liza van Dongelen and other NetBeans Users group members on
LinkedIn
To: Patrick Fitzpatrick <fi...@gm...>


 Linkedin GroupsFebruary 8, 2011 NetBeans Users

*Latest:* Discussions
(1)<http://www.linkedin.com/e/-bqte31-gjxg5avx-m/vgq/107402/EML_anet_ques_hm/>
  Discussions (1)  *Groovy 1.7.7 and 1.8-beta-4 now
available*<http://www.linkedin.com/e/-bqte31-gjxg5avx-m/ava/42900999/107402/EML_anet_di_pst_ttle/>
Comment
or flag »<http://www.linkedin.com/e/-bqte31-gjxg5avx-m/ava/42900999/107402/EML_anet_di_pst_cmnt/>
Like »<http://www.linkedin.com/e/-bqte31-gjxg5avx-m/lvi/107402/42900999/member/true/EML_anet_di_pst_like/>

Started by Liza van Dongelen, Content Manager at JTraining


Don't want to receive email notifications? Adjust your message
settings.<http://www.linkedin.com/e/-bqte31-gjxg5avx-m/ahs/107402/EML_anet_settings/>

Stop inappropriate content the moment it is posted. Send me an email for
each new discussion
»<http://www.linkedin.com/e/-bqte31-gjxg5avx-m/snp/107402/true/grp_email_subscribe_new_posts/>

LinkedIn values your privacy. At no time has LinkedIn made your email
address available to any other LinkedIn user without your permission. ©
2011, LinkedIn Corporation.




-- 
Fitz
Cell: (602) 803-7695
http://www.linkedin.com/in/fitzfitzpatrick

For the record:

Alexander has CVS permissions for the "ooc" project and will try
to do some CVS wrestling to get the patch into the repository.

-- mva


On 11 June 2012 23:28, Alexander Iljin <aj...@ya...> wrote:
> Hello, Bernhard and Michael!
>
>> If there are only some minor fixes, you should feed them back to MvA
>> So that they can be included, especially if you will abandon it again ...
>
>> If you don't find the time to feed it back to MvA, I could try to extract the
>> fixes from github and get them back to him ...
>
>  I've attached a file that with a DIFF between the OO2C CVS sources (as of July 2011) and my fixes combined with fixed by Alexander Shiryaev. My Git repository with commented commits can be found here: https://github.com/AlexIljin/oo2c
>  Michael, please consider importing the fixes into the OO2C CVS repository on SourceForge.
>
> ---=====---
>  Alexander

Hello, Bernhard and Michael!

> If there are only some minor fixes, you should feed them back to MvA
> So that they can be included, especially if you will abandon it again ...

> If you don't find the time to feed it back to MvA, I could try to extract the
> fixes from github and get them back to him ...

  I've attached a file that with a DIFF between the OO2C CVS sources (as of July 2011) and my fixes combined with fixed by Alexander Shiryaev. My Git repository with commented commits can be found here: https://github.com/AlexIljin/oo2c
  Michael, please consider importing the fixes into the OO2C CVS repository on SourceForge.

---=====---
 Alexander

So, I noticed that a simple REAL division on ARM gives unexpected results.
Then I solved it by doing shifts instead of using division, cause I had 
to finish the project in time.

This is obviously ooc bug, cause it generates different code on ARM and 
on x86(_64):

In attached examples you can inspect generated C output:

<   f0 = 5.3300000000000000E+2f/2.5600000000000000E+2f;
---
 >   f0 = 0.0000000000000000f/0.0000000000000000f;

First line was generated on x86_64 while the last one was generated on 
32bit ARM/GNU+Linux.

I've compiled ooc as usual under GNU/Linux.
The system I've tested it is maemo (core is Debian)


Hope anybody knows where to search for a problem.
Actually I can try to debug ooc in free time. Just its already hard 
because one have to debug non readable generated C code, and its even 
harder on maemo without my favourite ddd.

Sincerely,
Norayr

I've described how to do it here:
http://norayr.arnet.am/weblog/?p=4470

Norayr

So, I've prepared bindings to libusb, and various Unix libs with the 
Stewart Greenhill's H2O, then have been written i2c.Mod, which basicly 
implements functions to connect to i2c devices via i2c-tiny-usb board

Also, I've added ds1621 temperature sensor and hmc6352 compass modules, 
and a test example, which shows how to work with them.

i2c.Mod code is based on original C example by Tim Harbaum, author of 
the i2c-tiny-usb project.

My Oberon code and examples can be found at 
http://norayr.arnet.am/src/i2c_tiny_usb_in_oberon/

Sincerely,

Norayr Chilingarian

Hello!

  I was able to port a console application ImportGraph (12 modules) based on Amadeus-3
  (XDS Oberon-2) to oo2c. I had to remove some of the functions from the ported modules
  and leave only the necessary parts in. That took one day and helped me discover quite
  a few differences between the two compilers.

  The resulting application is not portable, because it relies on non-portable modules from
  the Amadeus library, such as Files and Paths.

  The summary of how oo2c differs from the XDS discovered so far:
  - different pragmas and system flags;
  - no SYSTEM.GET and SYSTEM.PUT procedures;
  - no "--" wing comment;
  - ORD() can't be used on a BOOLEAN exression or variable, only on characters;
  - curly braces and some other characters in published comments ("(**...") must be escaped with "@";
  - no Out.Open procedure;
  - special string types: arrays, STRING type, CSTRING flag, NO_LENGTH_INFO and 
    NO_DESCRIPTOR flags. Also, the "STATIC_POINTER" flag, which is documented, but rejected
    by the compiler. Not sure yet how all these string (sub-)types get along with each other;
  - Win.SetFileTime accepts VAR [NIL_COMPAT] parameters of type Win.FILETIME, but it does not 
    accept variables of type POINTER TO Win.FILETIME as factual parameters;
  - can't use LONG() to promote an integer constant size;
  - SYSTEM.VAL can't be used in a constant declaration;
  - no typed SETs.

---=====---
 Alexander

I've tried your code with Ofront, which is based on OP2.
---
MODULE test;

CONST x = SYSTEM.VAL (SET, 10);

BEGIN

END test.
---

# ./ofront test.Mod
test.Mod  translating test
     pos    58  err 50

err 50 means
Expression should be constant.
I guess OP2 behave exactly the same way.

Sincerely,
Norayr

On 08/03/11 18:34, Alexander Iljin wrote:
> Hello!
>
>>      I found that it's impossible to do "CONST x = SYSTEM.VAL (SET, 10)",
>>     because "10" is 1 byte, and SET is 4 bytes. And if I do "CONST x =
>>     SYSTEM.VAL (SET, LONG(LONG(10)))", then suddenly I get "expression
>>     is not constant error".
>>     Somehow "10" is a constant, and "LONG(LONG(10))" is not.
>>
>>     Is this a compiler bug or an intentional behaviour?
>
>    I was wrong, the problem is not only with LONG(LONG()), but with SYSTEM.VAL as well.
>
>    Here is the only way to convert integer constant value 10 to SET I found:
>
> VAR
>     set: SET;
>     long: LONGINT;
> BEGIN
>     long := 10;
>     attr := SYSTEM.VAL (SET, long);
>
>    If you try to use "10" instead of "long" in the last line, you'll get the size mismatch error
>    ("Size mismatch between type and expression"). Presumably this is because 10 is 1 byte,
>    and SET is 4 bytes. OK, sounds reasonable.
>
>    But shouldn't it be possible to use LONG() for size promotion? The following also compiles
>    without errors (LONGINT replaced with SHORTINT, added two LONG() calls):
>
> VAR
>     set: SET;
>     short: SHORTINT;
> BEGIN
>     short := 10;
>     set := SYSTEM.VAL (SET, LONG(LONG(short)));
>
>    Now there are two things that surprize me:
> 1. LONG(LONG(10)) does not produce a LONGINT constant 10. And neither does "0000000AH";
> 2. SYSTEM.VAL can't be used in a constant definition (more on that later).
>
>    Is it at all possible to create a constant of a given size? We have 1.E0 and 1.D0 to distinguish
>    between REAL and LONGREAL constants, but do we have a mechanism to say, I need "10"
>    in a LONGINT? SYSTEM.VAL (LONGINT, short) fails with the same size mismatch error.
>
>    The SYSTEM.VAL surprize boils down to this:
>
> CONST num = SYSTEM.VAL (SHORTINT, 10);
>
>    This produces the following error: "Expression is not constant". In this example the SYSTEM.VAL
>    call is a no-op. My question is: what is not constant about it?
>    Doesn't SYSTEM.VAL ALWAYS produce constant result no matter what type it casts to?
>
>    I'd like to ask everyone, Michael van Acken in particular, for advice on this situation. I'm willing
>    to dig into the sources if this is something to be fixed.
>
> ---=====---
>   Alexander
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos&  much more. Register early&  save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler

Was it under MinGW?

I am trying to guess whether that delay caused by oo2c or GNU gcc/binutils.
I think I always noticed that ooc translates fast, and then gcc/ld work 
slow.

Norayr

On 08/03/11 17:44, Alexander Iljin wrote:
> Hello!
>
>    I thought I found a bug: the compiler would hang on a source file, one procedure in particular.
>    I commented the procedure body, and then started to uncomment it line by line to find the
>    stumbling block. Gradually I realized that it didn't hang, it just took an unusually long to
>    complete. With every branching instruction added (a loop or an IF statement) the compilation
>    time doubled! That's an interesting property...
>
>    When I moved parts of code into local procedures the stubmling block was removed.
>    It forced me to simplify the code, which is kind of good, but still a bit weird.
>
> ---=====---
>   Alexander
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos&  much more. Register early&  save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

 >    trying to figure out the perspectives of porting the Amadeus-3 
library from XDS
 >    Oberon-2 to oo2c.
I know I influenced you to try ooc, but I am afraid you need to talk to 
Michael van Acken and/or Eric Nikitin about license exception, cause ooc 
library is distributed under GPL thus cannot be linked to proprietary 
products.

Norayr

On 08/02/11 11:32, Alexander Iljin wrote:
> Hello, Stewart!
>
>>       oob ADT:ArrayList
>
>    I saw it mentioned in the documentation, but I haven't had time to study the toolkit yet.
>
>    Recently I tried to install the compiler under MinGW+msys, then I found a crash and
>    tried to fix it, just to see how hard was that. After that I tried to run the "make test",
>    which I failed to make work in MinGW at the moment, so I tried to install it in a
>    VirtualBox'ed Linux. When that failed one Alexander Shiryaev, the maintainer of the
>    OpenBSD port of oo2c, provided me with an OpenBSD VM along with some patches
>    he developed. The patches fix some failed "informal" tests in the oo2c "make test" run.
>
>    Now that I have a working MinGW installation, a successfully fixed bug, a testing
>    environment and a windows interface module I can finally return to my initial goal:
>    trying to figure out the perspectives of porting the Amadeus-3 library from XDS
>    Oberon-2 to oo2c.
>
>    I've never worked with CVS and I reckon I never will, so I have setup a public Git
>    repository ( https://github.com/AlexIljin/oo2c ). You can see the (short) commit history
>    here:
>    https://github.com/AlexIljin/oo2c/commits/master
>    (To see changes introduced by a commit, click on the hexadecimal link next to the "commit"
>    word on the right side of the table.)
>
>    If we can get more fixes to warrant a new release, I'll publish it on SourceForge, as usual,
>    with the author's permission, of course.
>
> ---=====---
>   Alexander
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos&  much more. Register early&  save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler

Hello!

> I usually disable both gc and libs by using --disable-libs --without-gc 
>  configure options.

  You mean I have to run ./configure, rebuild the compiler, and then 
  compile my application?
  Is there a way to let the compiler use GC, but disable it just for my
  application?

---=====---
 Alexander

I usually disable both gc and libs by using --disable-libs --without-gc 
configure options.
This way I get even more fat binaries, cause oo2c libs are statically 
linked.
However, resulting program does not require liboo2c.so anymore.
Sincerely,
Norayr

On 08/02/11 12:53, Stewart Greenhill wrote:
> Hi Alexander,
>
> On 2/08/11 2:40 PM, Alexander Iljin wrote:
>> Hello, Stewart!
>>
>>>        strip Example4.exe
>>
>>     I didn't know that either! Thanks for the hint, now it's 108 Kb, which is more tolerable.
>>     I think to truly shine it should be build with -O2 option (currently it's -ggdb instead),
>>     and I could remove the GC, since it is never used. But I'll leave that tweaking for
>>     another day, unless you have a prepared recipe.
>
> OK, that's more like it. In my experience, the GC takes about 100K. You
> can remove the GC, but I can't remember how to do it. Another option
> (once you've debugged stuff) for optimising is --no-rtc which disables
> run-time checking, and may also speed up object/pointer-heavy code.
>
>>>    Unfortunately, there's no support for unsigned integers - everything is
>>>    mapped to signed types. I don't know of any Oberon dialects that include
>>>    unsigned integer types.
>>
>>     XDS Oberon-2 compiler supports unsigned integers in the form of SYSTEM.CARD8,
>>     SYSTEM.CARD16 and SYSTEM.CARD32. But then again, the XDS compiler also
>>     supports Modula-2, and allows you to mix the two languages in one project (as
>>     separate modules which can import one another).
>
> Sound useful, especially for interfacing to foreign code. Often it makes
> little difference (eg. integer addition), and providing nothing special
> happens on overflow you can live with the results. Probably most
> annoying is where you need constants that fill the entire width of the
> type - these sometimes have to be converted to negative numbers to stop
> the compiler complaining.
>
> Cheers,
>     Stewart
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos&  much more. Register early&  save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Hello!

>    I found that it's impossible to do "CONST x = SYSTEM.VAL (SET, 10)",
>    because "10" is 1 byte, and SET is 4 bytes. And if I do "CONST x = 
>    SYSTEM.VAL (SET, LONG(LONG(10)))", then suddenly I get "expression
>    is not constant error".
>    Somehow "10" is a constant, and "LONG(LONG(10))" is not.
>  
>    Is this a compiler bug or an intentional behaviour?

  I was wrong, the problem is not only with LONG(LONG()), but with SYSTEM.VAL as well.

  Here is the only way to convert integer constant value 10 to SET I found:

VAR
   set: SET;
   long: LONGINT;
BEGIN
   long := 10;
   attr := SYSTEM.VAL (SET, long);

  If you try to use "10" instead of "long" in the last line, you'll get the size mismatch error
  ("Size mismatch between type and expression"). Presumably this is because 10 is 1 byte,
  and SET is 4 bytes. OK, sounds reasonable.

  But shouldn't it be possible to use LONG() for size promotion? The following also compiles
  without errors (LONGINT replaced with SHORTINT, added two LONG() calls):

VAR
   set: SET;
   short: SHORTINT;
BEGIN
   short := 10;
   set := SYSTEM.VAL (SET, LONG(LONG(short)));

  Now there are two things that surprize me:
1. LONG(LONG(10)) does not produce a LONGINT constant 10. And neither does "0000000AH";
2. SYSTEM.VAL can't be used in a constant definition (more on that later).

  Is it at all possible to create a constant of a given size? We have 1.E0 and 1.D0 to distinguish
  between REAL and LONGREAL constants, but do we have a mechanism to say, I need "10"
  in a LONGINT? SYSTEM.VAL (LONGINT, short) fails with the same size mismatch error.

  The SYSTEM.VAL surprize boils down to this:

CONST num = SYSTEM.VAL (SHORTINT, 10);

  This produces the following error: "Expression is not constant". In this example the SYSTEM.VAL
  call is a no-op. My question is: what is not constant about it?
  Doesn't SYSTEM.VAL ALWAYS produce constant result no matter what type it casts to?

  I'd like to ask everyone, Michael van Acken in particular, for advice on this situation. I'm willing
  to dig into the sources if this is something to be fixed.

---=====---
 Alexander

Hello!

  I thought I found a bug: the compiler would hang on a source file, one procedure in particular.
  I commented the procedure body, and then started to uncomment it line by line to find the
  stumbling block. Gradually I realized that it didn't hang, it just took an unusually long to
  complete. With every branching instruction added (a loop or an IF statement) the compilation 
  time doubled! That's an interesting property...

  When I moved parts of code into local procedures the stubmling block was removed.
  It forced me to simplify the code, which is kind of good, but still a bit weird.

---=====---
 Alexander

Hello, Stewart!

>  >    XDS Oberon-2 compiler supports unsigned integers in the form of SYSTEM.CARD8,
>  >    SYSTEM.CARD16 and SYSTEM.CARD32.
>  Sound useful, especially for interfacing to foreign code. Often it makes 
>  little difference (eg. integer addition), and providing nothing special 
>  happens on overflow you can live with the results. Probably most 
>  annoying is where you need constants that fill the entire width of the 
>  type - these sometimes have to be converted to negative numbers to stop 
>  the compiler complaining.

  As far as I remember from the docs oo2c treats hexadecimal constants as unsigned.
  I.e. to fill a 2-byte word, you can simply use 0FFFFH, which is quite readable. Or did
  you mean something else?

---=====---
 Alexander

Hello!

  I found that it's impossible to do "CONST x = SYSTEM.VAL (SET, 10)",
  because "10" is 1 byte, and SET is 4 bytes. And if I do "CONST x = 
  SYSTEM.VAL (SET, LONG(LONG(10)))", then suddenly I get "expression
  is not constant error".
  Somehow "10" is a constant, and "LONG(LONG(10))" is not.

  Is this a compiler bug or an intentional behaviour?

---=====---
 Alexander