Page 2 of 2

Re: OSDK 1.14 RC

Posted: Tue Apr 30, 2019 11:56 pm
by NekoNoNiaow
Dbug wrote: Tue Apr 30, 2019 6:36 am 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 :)
No no no ;). That is precisely the bug! \oO;/

As I mentioned in the original post about that bug (this one: viewtopic.php?f=3&t=1945#p19302), if you replace the call to clock() with setting the value directly, the bug does not trigger. Even though, clock() returns 1! :D

This makes no sense but that's how it is. ;)
Dbug wrote: Tue Apr 30, 2019 6:36 am What about putting in in osdk/sample/mixed/osdk_testsuite?
Indeed. ;)
Dbug wrote: Tue Apr 30, 2019 6:36 am 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.
Ah, I meant the output of the program generating program, which itself is a C program to be compiled on the Oric.
These programs can be quite large and I am not yet sure of how to keep them small since I barely started to read the documentation of that system and will probably not have much time to do so before long.

Re: OSDK 1.14 RC

Posted: Wed May 01, 2019 1:51 am
by NekoNoNiaow
I got another bug with 1.14 RC2 which did not exist in 1.13 (no idea about 1.14RC since I did not test with it).

What happens is that this line appears in linked.s, which obviously cannot be assembled since it is invalid syntax:

Code: Select all

beq *+8 : asl tmp : rol : dex : bne *-4 : ldx tmp :(tmp0,tmp1,tmp0)
the original macro code in the .c2 file is:

Code: Select all

	LSHW(tmp0,tmp1,tmp0)
and this happens because the macro (in MACROS.h) has no parameters:

Code: Select all

#define LSHW\
 beq *+8 :\
 asl tmp :\
 rol :\
 dex :\
 bne *-4 :\
 ldx tmp :\
This happens when compiling this function:

Code: Select all

typedef enum { Ident_1, Ident_2, Ident_3, Ident_4, Ident_5 } Enumeration;
void Proc_6 (Enumeration Enum_Val_Par, Enumeration *Enum_Ref_Par)
{
  *Enum_Ref_Par = Enum_Val_Par;
  if (! Func_3 (Enum_Val_Par))
    *Enum_Ref_Par = Ident_4;
  switch (Enum_Val_Par)
  {
    case Ident_1:
      *Enum_Ref_Par = Ident_1;
      break;
    case Ident_2:
      if (Int_Glob > 100)
        /* then */
      *Enum_Ref_Par = Ident_1;
      else *Enum_Ref_Par = Ident_4;
      break;
    case Ident_3: /* executed */
      *Enum_Ref_Par = Ident_2;
      break;
    case Ident_4: break;
    case Ident_5:
      *Enum_Ref_Par = Ident_3;
      break;
  }
}
This happens 7 times in total in different functions of that program as well, in very different code moreover (no switch) and always due to that LSHW macro.

The entire program is quite much bigger than that but I suppose that this should be enough for Fabrice to figure out what is going on.
I can send him the whole thing if needed. ;)

Re: OSDK 1.14 RC

Posted: Wed May 01, 2019 8:29 am
by Dbug
Ok, I signaled the two issues to Fabrice, I'll go back to you when/if we have a fix :)

Re: OSDK 1.14 RC

Posted: Sat May 04, 2019 1:09 am
by NekoNoNiaow
Dbug wrote: Wed May 01, 2019 8:29 am Ok, I signaled the two issues to Fabrice, I'll go back to you when/if we have a fix :)
Thanks!

Re: OSDK 1.14 RC

Posted: Sat May 04, 2019 11:27 am
by Dbug
New weekend, new version:
http://www.osdk.org/files/osdk_1_14_rc3.zip

This RC3 fixes (hopefully):
- Two bugs happening only in -O0 mode, causes by incorrect macros (with a special thanks from Fabrice saying "Please thank Neko, he is the only one doing his tests in -O0 so that's why he finds all these problems").
- The clock problem, that has nothing to do with clock at all, it's actually caused by printf/sprintf not correctly showing negative numbers: If you look at the result of clock, it actually returns FFFF, but the sprintf code incorrectly ovewrote the "-" sign so it looks like 1
- Implemented %u in printf/sprintf, so now instead of showing "u" it will actually show the value

I modified the test program to that:

Code: Select all

#include <time.h>

long clockValue;    // FF FF
long clockValue2;   // 8E 02

void main()
{
  clockValue = clock();

  printf("A  %d\n", 1);
  printf("B  %d\n", -1);
  printf("C  %u\n", 1);
  printf("D  %u\n", -1);

  printf("E  %d\n", 1234);
  printf("F  %d\n", -1234);
  printf("G  %u\n", 1234);
  printf("H  %u\n", -1234);

  printf("clockValue         : %d\n", clockValue);          // will show "clockValue         : 1"
  printf("clockValue*100     : %d\n", clockValue*100);      // will show "clockValue*100     : 100"

  clockValue2=clockValue*100/100;
  printf("clockValue*100/100 : %d\n", clockValue2);  // should show "clockValue*100/100 : 1" but shows "clockValue*100/100 : 654"
  printf("\n");
}
which gives the following result:
OricutronLaurentClock.png
Hopefully that is what is expected.

Re: OSDK 1.14 RC

Posted: Sun May 05, 2019 2:29 am
by NekoNoNiaow
Dbug wrote: Sat May 04, 2019 11:27 am New weekend, new version:
http://www.osdk.org/files/osdk_1_14_rc3.zip
Nice, thanks! \(^^)/
Dbug wrote: Sat May 04, 2019 11:27 am with a special thanks from Fabrice saying "Please thank Neko, he is the only one doing his tests in -O0 so that's why he finds all these problems".
You are making me blush. (^^;)
Fabrice is obviously the one to be thanked for fixing these bugs. ;)
Dbug wrote: Sat May 04, 2019 11:27 am - The clock problem, that has nothing to do with clock at all, it's actually caused by printf/sprintf not correctly showing negative numbers: If you look at the result of clock, it actually returns FFFF, but the sprintf code incorrectly ovewrote the "-" sign so it looks like 1
Oh, that indeed explains the difference between direct assignation and clock() reading.
Dbug wrote: Sat May 04, 2019 11:27 am Hopefully that is what is expected.
Almost. ;)

I installed the release immediately and it does indeed fixes the display of -1.

However, that leaves open the question of why clock() returns -1 when it is supposed to return an unsigned value:

Code: Select all

typedef unsigned clock_t;
clock_t clock();
Also I found another bug by accident.
This program does not build when built with the OSDK with option -O3 (other options work fine):

Code: Select all

void main()
{
  unsigned long value = -1;
  printf("value*100/100 : %d\n", value*100/100);
}
And causes this output:

Code: Select all

Assembling
C:\Users\laurent\Desktop\dev\Oric\Sources\Tests\bug div\main.s(6):  06ef:Label 'mul16u' not defined
Break after 1 errors
The reason being that for some reason, linked.s does not include the "mult.s" file when compiled with -O3 whereas it is correctly included for other values of that option.

Hope this helps. ;)

Re: OSDK 1.14 RC

Posted: Sun May 05, 2019 11:41 am
by Dbug
Strange:

Code: Select all

D:\svn\users\dbug\tests\LaurentClockProblem>set osdk=D:\Downloads\osdk_1_14_rc3

D:\svn\users\dbug\tests\LaurentClockProblem>osdk_build.bat
Building the program HWSIMPLE at adress $800 [OSDK 1.14RC3]
Compiling MAIN.C
  - preprocess
  - compile
  - convert C to assembly code
  - cleanup output
Linking
D:\svn\users\dbug\tests\LaurentClockProblem
Assembling
Creating final program HWSIMPLE.TAP
File 'build\HWSIMPLE.tap' is 1380 bytes long (14 bytes header and 1366 bytes of data)
Build of HWSIMPLE.tap finished
and I guess that result in Oricutron:

value*100/100 : 654

The linked.s file looks like that:

Code: Select all

//
// This file was generated by Link65 version 0.066 
// Do not edit by hand
//
#file "D:\svn\users\dbug\tests\LaurentClockProblem\header.s"
(...)
#file "D:\svn\users\dbug\tests\LaurentClockProblem\MAIN.s"

_main
	ldx #8 : lda #0 : jsr enter :
	ldy #6 : lda #<( $ffffffff) : sta (fp),y : iny : lda #>( $ffffffff) : sta (fp),y :
	lda #<(LMAIN130) : ldy #0 : sta (sp),y : iny : lda #>(LMAIN130) : sta (sp),y :
	ldy #6 : lda (fp),y : sta tmp0 : iny : lda (fp),y : sta tmp0+1 :
	lda #<(100) : sta op1 : lda #>(100) : sta op1+1 : lda tmp0 : sta op2 : lda tmp0+1 : sta op2+1 : jsr mul16u : stx tmp0 : sta tmp0+1 :
	lda tmp0 : sta op1 : lda tmp0+1 : sta op1+1 : lda #<(100) : sta op2 : lda #>(100) : sta op2+1 : jsr div16u : stx tmp0 : sta tmp0+1 :
	lda tmp0 : ldy #2 : sta (sp),y : iny : lda tmp0+1 : sta (sp),y :
	ldy #4 : jsr _printf :
	jmp leave :
LMAIN130
	.asc "value*100/100 : %d"
	.byt $a
	.byt $0
(...)
#file "D:\svn\users\dbug\tests\LaurentClockProblem\printf.s"
(...)
_printf
(...)
#file "D:\svn\users\dbug\tests\LaurentClockProblem\mult.s"

mul16u
(...)
#file "D:\svn\users\dbug\tests\LaurentClockProblem\tail.s"
(...)
osdk_stack
	.dsb 256

osdk_check
	.asc "Dbug"

osdk_end 
(...)
(Just noticed that the #file paths are not pointing to the right path, they seem to use the current working directory instead of actual path)

are you using the exact version downloaded, or is it a modified/recompiled version?

Re: OSDK 1.14 RC

Posted: Sun May 05, 2019 1:32 pm
by iss

Code: Select all

C:\Users\laurent\Desktop\dev\Oric\Sources\Tests\bug div\main.s(6):  06ef:Label 'mul16u' not defined
Sorry if it's not related to the issue, but you are using path that contains 'space' character.
I'm always suspicious of such things :).

Re: OSDK 1.14 RC

Posted: Sun May 05, 2019 5:52 pm
by NekoNoNiaow
Dbug wrote: Sun May 05, 2019 11:41 am Strange:
[...]
(Just noticed that the #file paths are not pointing to the right path, they seem to use the current working directory instead of actual path)

are you using the exact version downloaded, or is it a modified/recompiled version?
iss wrote: Sun May 05, 2019 1:32 pm

Code: Select all

C:\Users\laurent\Desktop\dev\Oric\Sources\Tests\bug div\main.s(6):  06ef:Label 'mul16u' not defined
Sorry if it's not related to the issue, but you are using path that contains 'space' character.
I'm always suspicious of such things :).
I guess you guys are indeed onto something regarding paths and spaces.
I am using the downloaded 1.14RC3 version to which I added support %OSDK% paths with spaces (which I use constantly) by fixing bin/execute.bat and bin/make.bat.
I suspect that my changes miss a few cases but I do not understand why this happens only in -O3 and not in -O0.
I will be checking that right now, thanks for your input!

Re: OSDK 1.14 RC

Posted: Sat Jun 01, 2019 11:27 am
by Dbug
NekoNoNiaow wrote: Sun May 05, 2019 5:52 pm I guess you guys are indeed onto something regarding paths and spaces.
I am using the downloaded 1.14RC3 version to which I added support %OSDK% paths with spaces (which I use constantly) by fixing bin/execute.bat and bin/make.bat.
I suspect that my changes miss a few cases but I do not understand why this happens only in -O3 and not in -O0.
I will be checking that right now, thanks for your input!
Have you managed to find anything?

I'd like to release 1.14 officially, but for that I need to make sure there's been no real regression compared to 1.13 :)

Re: OSDK 1.14 RC

Posted: Fri Jun 07, 2019 8:58 pm
by NekoNoNiaow
Dbug wrote: Sat Jun 01, 2019 11:27 am
NekoNoNiaow wrote: Sun May 05, 2019 5:52 pm I guess you guys are indeed onto something regarding paths and spaces.
I am using the downloaded 1.14RC3 version to which I added support %OSDK% paths with spaces (which I use constantly) by fixing bin/execute.bat and bin/make.bat.
I suspect that my changes miss a few cases but I do not understand why this happens only in -O3 and not in -O0.
I will be checking that right now, thanks for your input!
Have you managed to find anything?

I'd like to release 1.14 officially, but for that I need to make sure there's been no real regression compared to 1.13 :)
I think I managed to fix it but this required a few changes to the build .bat files of the OSDK.
I do not remember what my changes were, I can send them to you tonight once I connect back to my machine.