OSDK 1.14 RC

Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

User avatar
Dbug
Site Admin
Posts: 3052
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

OSDK 1.14 RC

Post by Dbug » Sat Apr 13, 2019 10:32 am

Hi,
for a change, this new version of the OSDK is not a full release, but a RELEASE CANDIDATE version, the reason being that it contains the very latest version of all the code changes made by Fabrice to the Oric compiler, including fixes to the -O3 mode, additional optimizations, bug fixes for float to int conversions, etc...

There are a few minor changes here and there (like a minor fix to Tap2DSK to handle tapes that have incorrect headers), but for all intent and purpose, it's the same feature set as the 1.13 version.

So, what I would you to do is:
- Fetch the version from http://www.osdk.org/files/osdk_1_14_rc.zip
- Unpack that somewhere else
- Change your OSDK environment variable to point to the new version
- Rebuild all your projects without changing anything, and see if they work fine
- Then edit your config files to add SET OSDKCOMP=-O3 (or force that in the make.bat if you want) and redo the same thing

Ideally, you would make a copy of the BUILD/TMP folders when you switch between -O2 and -O3, so we can gather some stats in term of code size difference between the code generated in -O2 and -O3 build mode.

I'll let you play with it during Easter, and next week, if nothing critical is found, that will become the new version, with -O3 becoming the new default.

Feedback welcome!

PS: I added a OSDKVERSION environment variable in make.bat, when building your program you should see the version at the end of the first line of text:

Code: Select all

Building the program HIPIC at adress $600 [OSDK 1.14RC]  <-- Version
Compiling main.C
  - preprocess
  - compile
  - convert C to assembly code
  - cleanup output
Assembling picture.S
Linking
D:\svn\public\pc\tools\osdk\main\Osdk\_final_\sample\c\compression_test
Assembling
Creating final program HIPIC.TAP
File 'build\HIPIC.tap' is 4549 bytes long (14 bytes header and 4535 bytes of data)  <-- O2
File 'build\HIPIC.tap' is 4197 bytes long (14 bytes header and 4183 bytes of data)  <-- O3
Build of HIPIC.tap finished

User avatar
Chema
Game master
Posts: 2510
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OSDK 1.14 RC

Post by Chema » Sat Apr 13, 2019 12:32 pm

Is this only related to the C compiler? Would any test with my games, which are mc only, be of any use?

User avatar
Dbug
Site Admin
Posts: 3052
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OSDK 1.14 RC

Post by Dbug » Sat Apr 13, 2019 12:54 pm

Is this only related to the C compiler? Would any test with my games, which are mc only, be of any use?
It's mostly C, but would be cool if there was no other regression introduced involuntarily :)

User avatar
iss
Squad Leader
Posts: 919
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OSDK 1.14 RC

Post by iss » Sat Apr 13, 2019 3:24 pm

I've updated my Linux toolchain with the new compiler - so far no problems, except one little fix:
After update from SVN 'debug.c' file was deleted:

Code: Select all

D    public/pc/tools/osdk/main/compiler/sources/debug.c
because the new compiler doesn't need it, but the file name remains in public/pc/tools/osdk/main/compiler/Makefile

Code: Select all

.........
SOURCES=sources/dag.c    \
	sources/debug.c  \                         <---------- remove this line
 	sources/decl.c   \
.........
... and compilation fails.
I'm starting to work with '-O3' and will give additional feedback about the results.

Thanks for your effort, Dbug!

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: OSDK 1.14 RC

Post by NekoNoNiaow » Sat Apr 13, 2019 4:16 pm

How fluffy!
Thanks DBug. ;)

I haz just installed it and am using it as my main compiler.

Edit: added preliminary result below.

Just compiled my test effect (100% C) and already getting better results with the OSDK 1.14 RC compared to 1.13.
As you can see below:
  • execution speed is higher (about 1/30 faster)
  • size file is lower (0.04% smaller :D)
OSDK 1.13:
Duration = 28.23s with -O3
File 'build\XS.tap' is 12175 bytes long (14 bytes header and 12161 bytes of data)

OSDK 1.14 RC:
Duration = 27.12s with -O3
File 'build\XS.tap' is 12123 bytes long (14 bytes header and 12109 bytes of data)

The program executes normally, with no visible changes in behavior.

User avatar
iss
Squad Leader
Posts: 919
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OSDK 1.14 RC

Post by iss » Sat Apr 13, 2019 9:55 pm

Just found a problem. This program:

Code: Select all

static unsigned char data[] = {
  0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
  0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
};
void main(void) { return; }
is processed by compiler to:

Code: Select all

/* 16-bit code V1.34 */
Ltest129
	DB($ffffff80)
	DB($ffffff81)

	DB($ffffff82)
	DB($ffffff83)

	DB($ffffff84)
	DB($ffffff85)

	DB($ffffff86)
	DB($ffffff87)

	STRING "01"
	STRING "23"
	STRING "45"
	STRING "67"
_main
	RET
... it obviously fails with XA:

Code: Select all

obj/test/test.o2:line 273: 06bb:Syntax error
 .byt $ffffff81
Can any one try if it works correctly under Windows?

Else, I can't call this a bug, because I'm using a compiled from sources compiler under Linux.
The issue comes from how 'printf' function handles "%x" - this is known to be very compiler (standard library) dependent.
This is the original code in file 'gen.c':

Code: Select all

void defconst(int ty, Value v) {
    if (graph_output) return;
    switch (ty) {
    case C: print("\tDB(%d)\n",   v.uc); break;
    case S: print("\tDB(%d)\n",   v.us); break;
    case I: print("\tDW(%d)\n",   v.i ); break;
    case U: print("\tDW($%x)\n",  v.u ); break;
    case P: print("\tDW($%x)\n",  v.p ); break;
    case F: printfloat(v.f); break;
    case D: printfloat(v.d); break;
    default: assert(0);
    }
}
and with this modification I think it will work with any host compiler:

Code: Select all

void defconst(int ty, Value v) {
    if (graph_output) return;
    switch (ty) {
    case C: print("\tDB(%d)\n",   v.uc&0xFF ); break;
    case S: print("\tDB(%d)\n",   v.us&0xFF ); break;
    case I: print("\tDW(%d)\n",   (unsigned)v.i&0xFFFF ); break;
    case U: print("\tDW($%x)\n",  (unsigned)v.u&0xFFFF ); break;
    case P: print("\tDW($%x)\n",  (unsigned)v.p&0xFFFF ); break;
    case F: printfloat(v.f); break;
    case D: printfloat(v.d); break;
    default: assert(0);
    }
}
Attached is the modified file 'gen.c'.
gen.c.zip
(7.96 KiB) Downloaded 47 times
BTW, did you noticed above how the values between 32 and 127 are compiled as string :),
for me it's fun and bit "over-engineered", but yes, it gives better readability of assembler source... anyway - if it works - it's OK!

User avatar
Dbug
Site Admin
Posts: 3052
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OSDK 1.14 RC

Post by Dbug » Sat Apr 20, 2019 2:10 pm

Fabrice asked me to thank ISS for the discovery of the bug, adding that "the actual issue was in defstring, not in defconst).

The new RC is available at http://www.osdk.org/files/osdk_1_14_rc2.zip and the source code has been submitted on SVN.

Regarding Chema's original question, there was actually some changes to the Linker to accommodate the changes to the macro file (multiple instructions per line instead of carriage returns), so technically that can also impact assembler code.

@NekoNoNiaow, glad it worked for you, Fabrice is to thank at least as much as me, all I did was the Linker/integration fixes, he did all the work on the compiler, including fixing the crashes you found.

The more testers we have now, the more chances we do not commit a broken version :)

User avatar
iss
Squad Leader
Posts: 919
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OSDK 1.14 RC

Post by iss » Sat Apr 20, 2019 10:59 pm

I can confirm that last update in compiler works for me - no more problems with compilation found yet.
@Dbug: can you check one of your demos: http://miniserve.defence-force.org/svn/ ... emos/Cube/
It works by me with old compiler, but not with the new one - after 3-4 frames the cube is drawn at random places
and screen becomes garbage. I didn't debug the program yet just want to know that the issue is not by me only.
I used compiler with last update and with both flags (-O2 and -O3) it's the same.

User avatar
Chema
Game master
Posts: 2510
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: OSDK 1.14 RC

Post by Chema » Sun Apr 21, 2019 1:07 am

I am on Easter vacation, sorry for being quite unhelpful. As soon as I can, I will test this.

User avatar
Dbug
Site Admin
Posts: 3052
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OSDK 1.14 RC

Post by Dbug » Sun Apr 21, 2019 10:23 am

iss wrote:
Sat Apr 20, 2019 10:59 pm
I can confirm that last update in compiler works for me - no more problems with compilation found yet.
@Dbug: can you check one of your demos: http://miniserve.defence-force.org/svn/ ... emos/Cube/
It works by me with old compiler, but not with the new one - after 3-4 frames the cube is drawn at random places
and screen becomes garbage. I didn't debug the program yet just want to know that the issue is not by me only.
I used compiler with last update and with both flags (-O2 and -O3) it's the same.
It's working here for me, both in -O2 and -O3
Could you clean your temp/build folders, try again, and then zip the content for both temp and build so I can compare file by file what is happening?

User avatar
iss
Squad Leader
Posts: 919
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: OSDK 1.14 RC

Post by iss » Tue Apr 23, 2019 8:05 am

I've checked and the problem is NOT in new compiler, so no further action required. :)

For the sake of completeness only: the issue appears with the newer version of XA - 2.3.9, where the symbol '^' in quoted strings is parsed as CTRL+(next character) i.e.:

Code: Select all

.asc "^A^B"
is assembled as only 2 bytes 0x01,0x02 instead of 0x5e,0x41,0x5e,0x42.
That's it!

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: OSDK 1.14 RC

Post by NekoNoNiaow » Sat Apr 27, 2019 3:48 am

Dbug wrote:
Sat Apr 20, 2019 2:10 pm
@NekoNoNiaow, glad it worked for you, Fabrice is to thank at least as much as me, all I did was the Linker/integration fixes, he did all the work on the compiler, including fixing the crashes you found.

The more testers we have now, the more chances we do not commit a broken version :)
Indeed, thank him again for the fixes!

By the way, any news regarding the floating point issues I mentioned in viewtopic.php?f=3&t=1945#p19302 ?

User avatar
Dbug
Site Admin
Posts: 3052
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OSDK 1.14 RC

Post by Dbug » Sat Apr 27, 2019 7:13 pm

NekoNoNiaow wrote:
Sat Apr 27, 2019 3:48 am
By the way, any news regarding the floating point issues I mentioned in viewtopic.php?f=3&t=1945#p19302 ?
It was in the original post: bug fixes for float to int conversions, etc...

Your last post on the other thread was on the April 13, which is the same day as when I posted the 1.14 RC, and your post does not say anything about if it was on 1.13 or the new RC.

I suggest you run the test again, and if it's still wrong, then post a minimal code that shows the exact issue, removing all the non relevant things (I doubt we need "clock" or "time.h", or are they necessary?), and the expected values :)

Actually, based on the recent Ibissum post, maybe we could collect a bunch of small checks like that and put them together in some OSDK Test sample project that can be used to see if things compile, and if the results are correct, so to detect regressions.

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: OSDK 1.14 RC

Post by NekoNoNiaow » Tue Apr 30, 2019 3:28 am

Dbug wrote:
Sat Apr 27, 2019 7:13 pm
It was in the original post: bug fixes for float to int conversions, etc...
Gargl! I am soooo blind. :(
I promise to wake up before reading new posts next time. ;)
Dbug wrote:
Sat Apr 27, 2019 7:13 pm
Your last post on the other thread was on the April 13, which is the same day as when I posted the 1.14 RC, and your post does not say anything about if it was on 1.13 or the new RC.
Yup, I indeed forgot to mention it. This was for 1.13.
Dbug wrote:
Sat Apr 27, 2019 7:13 pm
I suggest you run the test again, and if it's still wrong, then post a minimal code that shows the exact issue, removing all the non relevant things (I doubt we need "clock" or "time.h", or are they necessary?), and the expected values :)
Just downloaded the 1.14RC2 and it still exhibits the issue.
The minimum program which reproduces it:

Code: Select all

#include <time.h>
void main()
{
  unsigned long clockValue;
  clockValue = clock();
  printf("clockValue         : %d\n", clockValue);          // will show "clockValue         : 1"
  printf("clockValue*100     : %d\n", clockValue*100);      // will show "clockValue*100     : 100"
  printf("clockValue*100/100 : %d\n", clockValue*100/100);  // should show "clockValue*100/100 : 1" but shows "clockValue*100/100 : 654"
  printf("\n");
}
Dbug wrote:
Sat Apr 27, 2019 7:13 pm
Actually, based on the recent Ibissum post, maybe we could collect a bunch of small checks like that and put them together in some OSDK Test sample project that can be used to see if things compile, and if the results are correct, so to detect regressions.
Yup, this is a great idea! Where should we put them?

I recently looked into a program which generates C programs designed to verify that C compilers generate proper arithmetic code. If it can be adapted to write small C programs that can run on the Oric it would be a nice testsuite for the OSDK but I am not sure yet of how small its output programs can be configured to be. I will post about it when I get there (do not hold your breath ;)).

User avatar
Dbug
Site Admin
Posts: 3052
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: OSDK 1.14 RC

Post by Dbug » Tue Apr 30, 2019 6:36 am

NekoNoNiaow wrote:
Tue Apr 30, 2019 3:28 am
Just downloaded the 1.14RC2 and it still exhibits the issue.
The minimum program which reproduces it:

Code: Select all

#include <time.h>
void main()
{
  unsigned long clockValue;
  clockValue = clock();
  (...)
}
The comments seem to assume that clockValue contains 1, so maybe a minimum program would not call "clock()" but just have "unsigned long clockValue = 1;" and the #include <time.h>" could also be removed :)

NekoNoNiaow wrote:
Dbug wrote:
Sat Apr 27, 2019 7:13 pm
Actually, based on the recent Ibissum post, maybe we could collect a bunch of small checks like that and put them together in some OSDK Test sample project that can be used to see if things compile, and if the results are correct, so to detect regressions.
Yup, this is a great idea! Where should we put them?

I recently looked into a program which generates C programs designed to verify that C compilers generate proper arithmetic code. If it can be adapted to write small C programs that can run on the Oric it would be a nice testsuite for the OSDK but I am not sure yet of how small its output programs can be configured to be. I will post about it when I get there (do not hold your breath ;)).
What about putting in in osdk/sample/mixed/osdk_testsuite?

Regarding the output, it does not have to output to screen, it can just send to the printer output, that will be redirected to a text file on both Euphoric and Oricutron, which means technically it's probably possible to automatically build, run, validate the result in a single script.

Post Reply