11 September 2021, 22:32 | #1 |
Registered User
Join Date: Sep 2008
Location: Germany
Age: 49
Posts: 137
|
Amiga C - BPTR vs. int32_t - different results regarding size of variable
hello,
well I could probably ignore this since I know how to get around this but I really want to understand what is happening here. I guess I am doing things wrong but I'm really not sure where. I made up a small example showing my issue. Let's assume we have 3 files main.c Code:
#include <proto/exec.h> #include <proto/dos.h> #include "types.h" #define __NOLIBBASE__ struct Library *DOSBase; extern BPTR con; extern void init_con(void); __saveds int main (void){ if (DOSBase = OpenLibrary ("dos.library",0L)){ init_con(); Write(con,"Hello, world!\n",14); CloseLibrary (DOSBase); } return (RETURN_OK); } Code:
#include <proto/dos.h> #include "types.h" BPTR con; void init_con(void) { con = Output() } Code:
typedef unsigned int uint32_t; typedef signed int int32_t; Code:
/opt/vbcc/bin/vc +kick13sm -g -sc -sd -c99 -I/opt/NDK_3.9/Include/include_h -o "build/dos.o" -c dos.c /opt/vbcc/bin/vc +kick13sm -g -sc -sd -c99 -I/opt/NDK_3.9/Include/include_h -o "build/main.o" -c main.c the C compiler is vbcc V0.9g in my project I started using the portable data types like 'uint16_t' etc. When I compile the above example with Code:
int32_t con; When I declare 'con' as a BPTR (which is in dos.h a 'typedef long BPTR;') then the result is a 32 bit access in storing and loading (as expected). Code:
BPTR con; |
11 September 2021, 22:58 | #2 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,160
|
with "stdint.h" included (and not a custom types.h file), int32_t is guaranteed to be 32 bits. So if the compiler produces a move.w from that, then there's a problem!
I suspect that "int" is 16 bit. Then your definitions are wrong Code:
typedef unsigned int uint32_t; typedef signed int int32_t; If stdint.h isn't available, try to print sizeof(int) and sizeof(long). Then maybe change int by long and you're okay (create your own version of stdint.h after having checked what the compiler does) |
12 September 2021, 00:53 | #3 |
Registered User
Join Date: Jan 2005
Location: UmeƄ
Age: 43
Posts: 922
|
vc +kick13s/kick13sm gives 16-bit int, so as already said, the definitions for uint32_t and int32_t is wrong.
|
12 September 2021, 11:09 | #5 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
I admit it is confusing, and this is certainly my fault.
From Apollo's reaction I assume that he didn't expect the kick13smconfig file to enable 16-bit int. He probably thought that the 's' stands for small code/data, which is also used here. It adds to the confusion that small data linker libs have an 's' appended: vcs.lib, amigas.lib, m881s.lib. But for the config files the 's' stands for "short int" (16-bit), as the 16-bit version of the m68k compiler backend is also called vbccm68ksinstead of vbccm68k(default, 32 bit int). The choice of the data model doesn't need a different config file. Just add -scand/or -sdas you need it. But for small-data don't forget to link with the correct libraries: -lvcsis required to override the -lvcfrom the config file. At last: As you already enabled C99, please feel free to include <stdint.h>which might replace your own types.h. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
BPTR alignment | sparhawk | Coders. Asm / Hardware | 32 | 28 February 2020 12:59 |
Amiga Game Development Contest - Results | MikeyG | Coders. Contest | 91 | 07 November 2019 09:00 |
Amiga Test Kit memory results | NoBrain2k | support.Hardware | 5 | 25 April 2019 01:02 |
Results of the Amiga Games Award 2011 | Daff | News | 1 | 04 February 2012 12:42 |
Results of the Amiga Games Award 2010 | Daff | News | 0 | 09 February 2011 14:51 |
|
|