OS3.9 -> OS4.1FE.....finally

[mritter0]

So I have finally started to port my program from OS3.9 to OS4.1FE. I am running into a few issues right off the bat:

1) implicit declaration of function 'stpcpy', 'strset', 'stcd_l'.
followed by 'incompatible implicit declaration of built-in function 'stpcpy'

I did a quick search, no real help. Came across CoreUtils-src.lha on OS4Depot. Include their code chunks or a better way I am not finding?


2) How are STRPTR TheString and CONST_STRPTR TheString different? The only time I would see using CONST_STRPTR would be for the locale strings, never change.


3) uint32 NumAppStrings=sizeof(CatCompArray) / sizeof(struct CatCompArrayType);
error: invalid application of 'sizeof' to imcomplete type 'struct CatCompArrayType[]'

Works on SAS/C. To get number of strings in the CatComp array.


4) UBYTE Path[1024]; or go to uint8 Path[1024]; or STRPTR Path; How much can STRPTR hold?


That's it for now....

[UberFreak]

I never coded in C/C++ specifically on Amiga, but regarding #3, I find it highly unlikely that any compiler would not give an error on that line.
sizeof cant work with incomplete types. "struct CatCompArrayType" just tells the compiler there's a struct named CatCompArrayType, there's no info on its contents so its size cannot be determined at compile time.

Basically, the standard way of calculating the size of an array is this:

int array[10];
int array_size = sizeof(array) / sizeof(array[0]);

This calculation will work with any type of array.

[matthey]

Originally Posted by mritter0

So I have finally started to port my program from OS3.9 to OS4.1FE. I am running into a few issues right off the bat:

What compiler (GCC I presume), version and system environment are you using?

Originally Posted by mritter0

1) implicit declaration of function 'stpcpy', 'strset', 'stcd_l'.
followed by 'incompatible implicit declaration of built-in function 'stpcpy'

stpcpy() came from Lattice on the Amiga and made its way into BSD, some Linux and GCC. Make sure that you have string.h included (which you should for SAS/C):

#include <string.h>

where the function declaration for SAS/C was:

extern char *stpcpy(char *, const char *);

It looks like GCC uses fancy unreadable defines to some built-in version of the function. It also uses restrict which helps optimization starting with C99 so the declaration if it existed, might look something like this:

char *stpcpy(char *resrtict to, const char *restrict from);

I don't know if that is a problem. At the very least, you could roll your own and call it something else:

char *stpcpy(char *, const char *);

char * stpcpy (char *dst, const char *src)
{
while ((*dst++ = *src++));
return (dst-1);
}

stpcpy() is more useful and more efficient than strcpy() with this version and I wouldn't be surprised if it was more efficient than the GCC built-in version. You could try adding the restrict for maximum efficiency.

strset() doesn't appear to be as popular. You can either search for an implementation on the internet or use a strlen()+memset(). stcd_l should probably be changed to strtol() if possible.

http://en.cppreference.com/w/c/string/byte/strtol

Originally Posted by mritter0

2) How are STRPTR TheString and CONST_STRPTR TheString different? The only time I would see using CONST_STRPTR would be for the locale strings, never change.

STRPTR is type defined as an unsigned char pointer while CONST_STRPTR is a const unsigned char pointer. See exec/types.h of the AmigaOS NDK includes.

Originally Posted by mritter0

4) UBYTE Path[1024]; or go to uint8 Path[1024]; or STRPTR Path; How much can STRPTR hold?

Does #include <exec/types.h> no longer work with AmigaOS 4? You should be able to include this header to avoid needing to change from UBYTE to uint8. You would probably get errors if you changed this and then used with Amiga functions. STRPTR is just a pointer to data (a string) and doesn't hold any data other than the address to which it points.

[mritter0]

@UberFreak: I think I found away around the sizeof() issue. I updated the code to not worry about the numer of strings. I will file that way, though.

@matthey: Yes, GCC. I didn't specify.

For some reason strings.h is not in the GCC include_h folder. I copied it from VBCC's and it worked. It didn't give me an error it wasn't found so didn't go looking.

Got around it with strcpy() and strcat() for what I was doing.

strset() is not ANSI so not in GCC. I think ClearMem() might be what I need.

stcd_l() to strtol() is what I used. I had it in another newer source file; just hadn't updated this one.

I can now get my project to compile and link, but not run yet. But for some reason it says it can't find -lamiga. It can find/use -lauto. Or is it automatically linking it?

[matthey]

Originally Posted by mritter0

For some reason strings.h is not in the GCC include_h folder. I copied it from VBCC's and it worked. It didn't give me an error it wasn't found so didn't go looking.

My AmigaOS 3 vbcc install doesn't have a strings.h (you may be able to get away with just including the more common string.h depending on which functions you use). Perhaps you used the strings.h from Frank Wille's posix.lib? That one is probably close to what an old version of GCC would have had. It's usually not recommended to swap header files between different versions of the same compiler let alone a different compiler. Be careful or you will get your compilers messed up so they don't work right.

Originally Posted by mritter0

Got around it with strcpy() and strcat() for what I was doing.

It's significantly slower and probably twice as much code but that works.

Originally Posted by mritter0

strset() is not ANSI so not in GCC. I think ClearMem() might be what I need.

Most memory clearing functions need a length and not a NUL terminated string. Try the following:

#include <string.h>  /* you need this for memset() and strlen() */

#define strset(s,c) memset(s,c,strlen(s))

Put it at the top of your code after any includes or in a header file. I tested it here with vbcc and it did what I expected, provided I understand the functions well enough.

Originally Posted by mritter0

I can now get my project to compile and link, but not run yet. But for some reason it says it can't find -lamiga. It can find/use -lauto. Or is it automatically linking it?

It's quite possible that GCC doesn't need -lamiga. I have a project like that where vbcc needs to be linked with amiga.lib and my GCC 3.4.0 doesn't seem to need it.

[mritter0]

Getting most things worked out and updated. One thing that shocked me was the size of the executable. It went from 330K on OS3.9 to over 1.5MB on OS4. I expected at least a 64K jump, but not that much! What is up with that?!

I haven't gotten it to run and open the window yet. A couple things:

In my Locale code to get the built-in or external catalog strings, this line

String=GetCatalogStr(Catalog,ID,Builtin);

gives warning: assignment discards qualifiers from pointer target type

The variable types all match.

	if (OpenDevice(TIMERNAME,UNIT_VBLANK,TimerIO,0))

warning: passing argument 4 of 'IExec->OpenDevice' from incompatible pointer type.
TimerIO is: struct TimeRequest *TimerIO;


EDIT: if (OpenDevice(TIMERNAME,UNIT_VBLANK,(struct IORequest *)TimerIO,0))
gets rid of the warning. Haven't tested it yet.


I haven't dug too deep into this one. I know devices handles differently on OS4. These are the last 2 major warnings.

[matthey]

Originally Posted by mritter0

Getting most things worked out and updated. One thing that shocked me was the size of the executable. It went from 330K on OS3.9 to over 1.5MB on OS4. I expected at least a 64K jump, but not that much! What is up with that?!

PPC code can easily be twice as large as 68k code but what you have is excessive. Maybe the problem is GCC using stubs by default for Amiga functions which bloats code. You might try including protos like:

#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/intuition.h>

It may allow inlined Amiga functions and should help 68k GCC code optimization also. You probably are using a low level of optimization right now causing the PPC to read and write variables in memory more often which takes several instructions on the PPC. The situation should improve with -O2.

Most of your questions are getting into the AmigaOS 4 realm of which I don't know and have no experience. There are only a few people here on EAB who can help you. If they don't help, you might consider asking your AmigaOS 4 specific questions on Amigaworld.net.

[mritter0]

I was purposely not using any extra optimization for speed.

Before using -O2: 1602162 bytes
After using -O2: 941726 bytes

Still almost 3 times the size as OS3.9, but better.

[matthey]

Originally Posted by mritter0

I was purposely not using any extra optimization for speed.

Before using -O2: 1602162 bytes
After using -O2: 941726 bytes

Still almost 3 times the size as OS3.9, but better.

Have you stripped the debug info or compiled without debug info? That can make quite some difference. I would expect 32 bit PPC code to be 40%-50% larger than 68k code. I could probably disassemble the 68k AmigaOS 3.9 version of your program and tell you how to get it down to 300kB but I'm not much help with PPC.

[mritter0]

No debug turned on by me; no debug code put in by me. Does it need to be turned off? I would think it is off by default.

[matthey]

Originally Posted by mritter0

No debug turned on by me; no debug code put in by me. Does it need to be turned off? I would think it is off by default.

I believe the GCC default includes some symbols and debugging information (the vbcc default is off). You can try to turn it off with -g0 (zero) or there are debug stripping programs (often easier than making separate compiles with and without debug).

You might try linking (LFLAGS) with -noixemul. I don't know if that is still important with AmigaOS 4.

[mritter0]

Here is a weird one that has me thrown for a loop:

int32 HistorySelected= -2;   // set in globals.h
......
if (HistorySelected== -2)
{
...
}
else
{
...
}

It never honors the -2, even if I set again in the main loop before going to this check.

If I display the value in a requester, it says it is -1803748384 (some crazy number).

[matthey]

Originally Posted by mritter0

Here is a weird one that has me thrown for a loop:

int32 HistorySelected= -2;   // set in globals.h

The proper signed 32 bit fixed width C99 data type would be:

int32_t HistorySelected= -2;   // set in globals.h

I recommend using C99 types over some UNIX type. Be sure to include stdint.h for the C99 types:

#include <stdint.h>

You will need an external variable declaration making it a global variable somewhere also:

extern int32_t HistorySelected;

[mritter0]

Didn't make any difference.

[matthey]

Originally Posted by mritter0

Didn't make any difference.

You could try renaming the variable and see if it makes any difference. It's unlikely that there would be a name conflict with such a long variable name though. If you are good with a debugger and know a little PPC assembler, you might be able to see what is happening. I could probably give you a hint if the problem occurred with the 68k executable.

Edit: You could try deleting all the .o files that are generated by the build process and start the build again. Sometimes stale data or an incorrect build system will cause problems.

[mritter0]

OMG....finally figured out what was going on with the -2 issue. I was setting it in globals.h, but then a portion of code I couldn't use under OS3.9 but now do under OS4.1FE, was setting it (or not setting it) to 0. Spent 3 days on this. Simplest things can be the most frustrating.

Thanks for the input and ideas, matthey.