1.6 development planning thread - page 4 - General Discussion and Assistance - CHDK Forum

1.6 development planning thread

  • 60 Replies
  • 2669 Views
*

Offline philmoz

  • *****
  • 3291
    • Photos
Re: 1.6 development planning thread
« Reply #30 on: 07 / December / 2020, 20:50:21 »
Advertisements
Changing to ARCHFLAGS+=-march=armv4t in platform/makefile_platform.inc and platform/makefile_sub.inc fixes the build with GCC9.
Have you checked to verify it doesn't break interworking? Like https://chdk.setepontos.com/index.php?topic=12115.msg118896#msg118896

This might not be obvious from just running a build, since many cams return with a thumb safe sequence *most* of the time.

I have compared the main.bin.dump files from GCC4 with and without change. Still checking GCC5.
DryOS cameras generate identical code with GCC4 & GCC5.

VxWorks cameras are identical except for a couple of functions where the return code is now generated as 'bx REG' instead of 'mov pc, REG'.
For example A410 task_start_hook function.
IMHO the 'bx REG' version (armv4t) would be technically correct; but as the functions in question are not called from thumb code either should work.

I don't have a working VxWorks camera so I can't verify that this change still runs.
EDIT: reyalp has confirmed this still works on VxWorks.

EDIT: with this change GCC9 generates the same interworking code for stubs and ARM return instructions as GCC5 so I don't expect there would be any interworking issues.

Phil.
« Last Edit: 08 / December / 2020, 00:25:07 by philmoz »
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline whim

  • ******
  • 2040
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: 1.6 development planning thread
« Reply #31 on: 08 / December / 2020, 00:39:31 »
@philmoz

Quote
I don't have a working VxWorks camera so I can't verify that this change still runs.

tested working (autoboot + CHDK menu function) on ixus70_sd1000_101b (digic 3 / vxworks)
for builds with gcc 493, 541, 831, 931.

This was on r5664 + your mod + arm_rules.inc changes to enable gcc 8 and 9.

thanks (also for fixing all the warnings !),

whim

*

Offline philmoz

  • *****
  • 3291
    • Photos
Re: 1.6 development planning thread
« Reply #32 on: 08 / December / 2020, 03:22:52 »
tested working (autoboot + CHDK menu function) on ixus70_sd1000_101b (digic 3 / vxworks)
for builds with gcc 493, 541, 831, 931.


Thanks for testing. Update 5665 should allow all cameras to be built with GCC 4, 5, 8 or 9.


Phil.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline philmoz

  • *****
  • 3291
    • Photos
Re: 1.6 development planning thread
« Reply #33 on: 08 / December / 2020, 03:28:53 »
Possible issue in the GPS code.

GCC9 generates new warnings in the GPS code - where the integer abs() function is being used with double/float values.

Code: [Select]
../../core/gps.c: In function 'draw_gps_course_info':
../../core/gps.c:298:9: warning: using integer absolute value function 'abs' when argument is of floating point type 'double' [-Wabsolute-value]
  298 |     if (abs(regressionChange (&deltareg))<0.5 || rest < 5.0) rest = 0.0;
      |         ^~~

../../core/gps_math.c: In function 'arctan':
../../core/gps_math.c:23:9: warning: using integer absolute value function 'abs' when argument is of floating point type 'double' [-Wabsolute-value]
   23 |     if (abs(x) < 1 )
      |         ^~~
../../core/gps_math.c:37:9: warning: using integer absolute value function 'abs' when argument is of floating point type 'double' [-Wabsolute-value]
   37 |     if (abs(x) >= 1 )
      |         ^~~

Looking at the generated assembly code the logic is doing integer abs() tests which may not be what was intended.

I don't have a GPS equipped camera so I can't do any testing to see if the logic is valid or not.
If the integer abs() logic is correct an option to disable to warning can be added.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)


*

Offline Caefix

  • ****
  • 436
  • Sorry, busy deleting test shots...
Re: 1.6 development planning thread
« Reply #34 on: 08 / December / 2020, 10:57:26 »
 :xmas
-- (abs(x) < 1 )
++ ((x*x)< 1 )

Edit: stdlib.h Line 232:  extern int abs( int v );
« Last Edit: 08 / December / 2020, 15:59:07 by Caefix »
All lifetime is a loan from eternity.

Re: 1.6 development planning thread
« Reply #35 on: 08 / December / 2020, 11:32:15 »
Possible issue in the GPS code.

GCC9 generates new warnings in the GPS code - where the integer abs() function is being used with double/float values.

I don't have a GPS equipped camera so I can't do any testing to see if the logic is valid or not.
If the integer abs() logic is correct an option to disable to warning can be added.
I was probably the last person to monkey with that GPS code, although it was mostly trying to get the UI understandable IIRC.  But I do still have my S100 so could test your GCC9 build  (I'm still on gcc4) if we can work out a test case.

Edit :  f/w 1.02A
« Last Edit: 08 / December / 2020, 11:33:58 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3291
    • Photos
Re: 1.6 development planning thread
« Reply #36 on: 08 / December / 2020, 16:09:47 »
Possible issue in the GPS code.

GCC9 generates new warnings in the GPS code - where the integer abs() function is being used with double/float values.

I don't have a GPS equipped camera so I can't do any testing to see if the logic is valid or not.
If the integer abs() logic is correct an option to disable to warning can be added.
I was probably the last person to monkey with that GPS code, although it was mostly trying to get the UI understandable IIRC.  But I do still have my S100 so could test your GCC9 build  (I'm still on gcc4) if we can work out a test case.

Edit :  f/w 1.02A


It doesn't require a GCC9 build - the generated code is the same for GCC4 & 5. It's just that GCC9 shows the warning about integer/float usage.
The code in question is in the draw_gps_course_info and arctan functions. Arctan is only called by draw_gps_course_info (via rect2polar).


If draw_gps_course_info appears to be working correctly then the warning is probably a false positive and we can ignore it.


Phil.
« Last Edit: 08 / December / 2020, 16:11:28 by philmoz »
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline whim

  • ******
  • 2040
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: 1.6 development planning thread
« Reply #37 on: 08 / December / 2020, 16:27:46 »
@philmoz

hi,

checked for errors/warnings while compiling r5665 for a set of my cams representing digic 1 ~ 6
(including 1 w/ GPS) using gcc 6, 7, 8, and 9.

Interestingly, "odd" compilers (gcc 7 & 9) still produce a few warnings when OPT_WARNINGS is
activated, while "even" compilers show none.

Just showing the gcc 7 warnings here (hmmm...there's 3 sections like this for a 7 cam compile ? )
Quote
games/gui_sudoku.c: In function 'sudoku_search_candidates':
games/gui_sudoku.c:1118:1: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
 };
 ^
games/gui_sudoku.c:1118:1: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:1118:1: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:1118:1: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:422:5: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
 int sudoku_search_candidates()
     ^~~~~~~~~~~~~~~~~~~~~~~~
games/gui_sudoku.c:422:5: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:422:5: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:422:5: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c: At top level:
cc1.exe: warning: unrecognized command line option '-Wno-cast-function-type'


DISKBOOT.BIN size tends to decrease with higher numbered gcc releases, but on the cams tested
here I got 950~1050 bytes larger files with gcc 9 as compared to those from gcc 8.

Also, happy to report that r5665 compiles fine with gcc 10.1.1 - and seems to run OK,
with only a minor tweak to CFLAGS; according to the doc gcc 10 now defaults to '-fno-common',
had to add '-fcommon' to keep the linker from complaining about multiply defined globals.
It's still experimental (not released for production code by developer.arm.com)
Apart from the gps-related 'abs' warnings found with gcc 9, it came up with an interesting
implicit conversion warning in usb_remote.c:
Quote
../../core/usb_remote.c: In function 'set_usb_remote_state':
../../core/usb_remote.c:395:62: warning: implicit conversion from 'enum VIRTUAL_REMOTE_STATE' to 'enum LOGIC_MODULE_STATE' [-Wenum-conversion]
  395 |     virtual_remote_state = driver_state = logic_module_state = REMOTE_RESET ;
      |                                                              ^
../../core/usb_remote.c:395:41: warning: implicit conversion from 'enum LOGIC_MODULE_STATE' to 'enum DRIVER_STATE' [-Wenum-conversion]
  395 |     virtual_remote_state = driver_state = logic_module_state = REMOTE_RESET ;
      |                                         ^
../../core/usb_remote.c:395:26: warning: implicit conversion from 'enum DRIVER_STATE' to 'enum VIRTUAL_REMOTE_STATE' [-Wenum-conversion]
  395 |     virtual_remote_state = driver_state = logic_module_state = REMOTE_RESET ;
      |                          ^


BTW IIRC the gps code was contributed by our CHDK-DE friends @msl and/or @rudi ?

cheers, 1.6.0 seems off to a great start !


whim






*

Offline philmoz

  • *****
  • 3291
    • Photos
Re: 1.6 development planning thread
« Reply #38 on: 08 / December / 2020, 16:52:01 »

Thanks @whim.

Just showing the gcc 7 warnings here (hmmm...there's 3 sections like this for a 7 cam compile ? )
Code: [Select]
games/gui_sudoku.c: In function 'sudoku_search_candidates':
games/gui_sudoku.c:1118:1: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
 };
 ^
games/gui_sudoku.c:1118:1: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:1118:1: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:1118:1: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:422:5: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
 int sudoku_search_candidates()
     ^~~~~~~~~~~~~~~~~~~~~~~~
games/gui_sudoku.c:422:5: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:422:5: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c:422:5: warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true [-Wstrict-overflow]
games/gui_sudoku.c: At top level:
cc1.exe: warning: unrecognized command line option '-Wno-cast-function-type'

Hmm, that looks like a compiler bug - it's showing the warning at the end of the file in a function from early in the file. Normally it should show the actual line with the warning. I'm not too fussed about it - supporting GGC 4, 5, 8 & 9 is probably enough.

Quote
Apart from the gps-related 'abs' warnings found with gcc 9, it came up with an interesting
implicit conversion warning in usb_remote.c:
Code: [Select]
[size=0.7em]../../core/usb_remote.c: In function 'set_usb_remote_state':
../../core/usb_remote.c:395:62: warning: implicit conversion from 'enum VIRTUAL_REMOTE_STATE' to 'enum LOGIC_MODULE_STATE' [-Wenum-conversion]
  395 |     virtual_remote_state = driver_state = logic_module_state = REMOTE_RESET ;
      |                                                              ^
../../core/usb_remote.c:395:41: warning: implicit conversion from 'enum LOGIC_MODULE_STATE' to 'enum DRIVER_STATE' [-Wenum-conversion]
  395 |     virtual_remote_state = driver_state = logic_module_state = REMOTE_RESET ;
      |                                         ^
../../core/usb_remote.c:395:26: warning: implicit conversion from 'enum DRIVER_STATE' to 'enum VIRTUAL_REMOTE_STATE' [-Wenum-conversion]
  395 |     virtual_remote_state = driver_state = logic_module_state = REMOTE_RESET ;
      |                          ^
[/size]

I don't get this warning with 9.3.1 - what version of GCC9 do you have?

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline whim

  • ******
  • 2040
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: 1.6 development planning thread
« Reply #39 on: 08 / December / 2020, 17:09:07 »
Hi phil,
Sorry for awfull typography - always struggling with html editors.It's actually GCC 10.1.1. Produces same warning as 9.3.1 plus the quoted new warnings. Was just trying to say it looks like we might be able to use 10 in the future without major headaches.

whim

 

Related Topics