Visual Studio Code Amiga C Extension

[Steam Ranger]

I'm having problems with includes. As far as I can tell, I just include

<proto/xxx>

for whatever library I want to use.

However including

 <proto/alib.h>

throws a ton of errors. Attached is the output when I try to build with it included.

Although, I would appreciate if someone would point me to working implementations of

CreateExtIO()

and

DeleteExtIO()

, because I'd be just fine programming them in myself, but I can't figure out what needs to be initialised in the

IORequest

structure. I've already made my own

CreatePort()

and

DeletePort()

.

Thanks in advance.

[a/b]

Something like:

createextio(reply_port, size):
io = AllocMem(size,MEMF_CLEAR|MEMF_PUBLIC); // handle failed alloc
io->io_Message.mn_Node.ln_Type = NT_REPLYMSG;
io->io_Message.mn_Length = size;
io->io_Message.mn_ReplyPort = reply_port;
return io;

deleteextio(io):
if (io) FreeMem(io,io->io_Message.mn_Length);

[Steam Ranger]

Originally Posted by a/b

io->io_Message.mn_Node.ln_Type = NT_REPLYMSG;
io->io_Message.mn_Length = size;
io->io_Message.mn_ReplyPort = reply_port;

So the only thing you have to fill in on the IORequest for it to be functional is the properties of it's message structure?

PS: Also do I have to abort the IORequest before removing it? The documentation says it's dangerous to abort a request that's never been used, how do I check if it's been used or not?

[a/b]

Yeah, NT_REPLYMSG tells that the previous I/O had been replied and is fully complete, and the request is ready for another or to be freed. Length is there so that you know whether it's standard, extended, etc. (how much extra data is there). ReplyPort is optional, it's there because typically it's always the same one so you fill it in once.
Other properties you have to fill in prior to doing an actual I/O, based on device, I/O type, etc.

You should only (try to, since it's not a 100% guarantee, there are device specific considerations) abort if it's in progress (if you haven't replied yet). If the type is set to NT_REPLYMSG, as I mentioned above, it's done.

[Steam Ranger]

I'm running into a problem with the timer device.
Here's the code I'm using to open it:

Devices.h

	
	
#define NewList(list) ({\
	struct List *_NewList_list = (&(MessagePort->mp_MsgList));\
	_NewList_list->lh_TailPred = (struct Node *)_NewList_list;\
	_NewList_list->lh_Head = (struct Node *)&_NewList_list->lh_Tail;\
	_NewList_list->lh_Tail = 0;\
})

struct MsgPort *CreatePort(char *Name, long int PRI) {
	long int SignalBit;
	struct MsgPort *MessagePort;

	if ((SignalBit = AllocSignal(-1L)) == -1) return NULL;

	MessagePort = (struct MsgPort*)AllocMem(sizeof(struct MsgPort), MEMF_PUBLIC|MEMF_CLEAR);
	if (MessagePort == 0) {
		FreeSignal(SignalBit);
		return NULL;
	}
	MessagePort->mp_Node.ln_Name	= Name;
	MessagePort->mp_Node.ln_Pri	= PRI;
	MessagePort->mp_Node.ln_Type	= NT_MSGPORT;
	MessagePort->mp_Flags		= PA_SIGNAL;
	MessagePort->mp_SigBit		= SignalBit;
	MessagePort->mp_SigTask		= FindTask(0L);

	if (Name != 0) AddPort(MessagePort);
	else NewList(&(MessagePort->mp_MsgList));

	return MessagePort;
}

...

struct IORequest *CreateExtIO(struct MsgPort *MessagePort, long int IOSize) {
	struct IORequest *Output = AllocMem(IOSize, MEMF_PUBLIC|MEMF_CLEAR);
	if (Output == 0) return NULL;
	Output->io_Message.mn_Node.ln_Type	= NT_REPLYMSG;
	Output->io_Message.mn_Length		= IOSize;
	Output->io_Message.mn_ReplyPort		= MessagePort;
	return Output;
}

...

struct IORequest *FabricateExtIO(long int IOSize) {
	struct MsgPort *MessagePort = CreatePort(0L,0L);
	if (MessagePort == 0) return NULL;
	struct IORequest *Output = CreateExtIO(MessagePort, IOSize);
	if (Output == 0) DeletePort(MessagePort);
	return Output;
}

Timer.h

	
	
#include "Devices.h"

struct Library *TimerBase;

struct timerequest *OpenTimer() {
	struct timerequest *Timer = (struct timerequest*)FabricateExtIO(sizeof(struct timerequest));
	if (Timer == NULL) return NULL;
	if (OpenDevice(TIMERNAME, UNIT_MICROHZ, (struct IORequest*)Timer, 0L) != 0) {
		DismantleExtIO((struct IORequest*)Timer);
		return NULL;
	}
	TimerBase = (struct Library*)Timer->tr_node.io_Device;
	return Timer;
}

...

long int GetTimestamp() {
	struct timeval *SysTime;
	GetSysTime(SysTime);
	return SysTime->tv_secs * 1000L + SysTime->tv_micro / 1000L;
}

It compiles fine, manages to open the device without errors, puts a seemingly correct address into

TimerBase

,
and yet when

GetSysTime()

is called it gives this in a pop-up:

Failed to get Stack Trace: Cannot access memory at address 0xaea00f8 (from data-disassemble -s 0x0aea00f8 -e 0x0aea015c -- 5)

And outputs this:

B-Trap FFFF at 000A9CD2 -> 00F80AE8

Your Amiga program just did something terribly stupid 0AEA00F8 PC=00F80BC4

...

CPU halted: reason = 3 PC=00f80bc4

Please help...

[a/b]

Probably not related, but...
1. NewList macro is not using its parameter list, looks like there's a hardcoded outside variable in the first line, right-hand side. It should probably be: struct List *_NewList_list = list;
2. NewList macro again, why ({...})? () is typically associated with function calls, you should probably only use {}

[Steam Ranger]

I copied character for character the existing newlist macro, as for whatever reason the one in my includes wasn't working.

[Steam Ranger]

Here's

Timer.h

and

Devices.h

, incase more info is needed. I cannot figure out why this isn't working, especially since no part of the opening process gives an error. It just all worked correctly and then

WinUAE Error 3

.

They've got

*.c

extensions just so I can upload them, but they're

*.h

Files.

[a/b]

AbortIOInProgress should use != instead of == (you're aborting if type == NT_REPLYMSG).

And again, what is the purpose of ({...})? After NewList macro expansion you end up with
if (...) {...} else ({...})
instead of
if (...) {...} else {...}
I don't know what compiler you're using, if it's a gcc port it could be OK since this is not a valid c, it's a gcc extension, and I don't know what will other compilers produce.
In any case there's no need for () because, as far as I can see, macro is not intended to be used as a right-hand expression (it would always "return" 0).

[Thomas Richter]

Is there actually a reason why you don't use NewList() in amiga.lib, CreateMsgPort() in exec and CreateExtIO() in exec? Or their corresponding counterparts from amiga.lib?

[Steam Ranger]

Whenever I include it it throws errors because of

_stdargs

or something before every function definition, but if I splice those out of the file the functions fail. So I decided to make my own set of functions, which also has the benefit that I can tweak them to have additional features.

PS:

NewList

by default expands to have those brackets around it, but even once I've removed them it doesn't alter the functionality one bit. Also, I'm using

gcc 8

.

[Steam Ranger]

Ah, I just realised. In

GetTimestamp()

my intention was to create a

struct timeval

in stack memory, pass a pointer to it into

GetSysTime()

and then return some values from it.

I forgot that declaring a pointer to the structure doesn't create it, but instead you have to declare the structure and use

&

to get a pointer.

Thanks for your help anyway.

[phx]

Originally Posted by Steam Ranger

Whenever I include it it throws errors because of

_stdargs

or something before every function definition

Probably

__stdargs

as in

clib/compiler_specific.h

:

#if (defined(__GNUC__) && defined(AMIGA)) || defined(__SASC)
#define __STDARGS__ __stdargs

Then the person who did your specific gcc-port forgot to include the attribute, or named it differently.

but if I splice those out of the file the functions fail.

Which means the default ABI of your compiler is incompatible to most other 68k compilers. Usually an 68k compiler will pass arguments on the stack. The

_stdargs

attribute is for those compilers which don't. Which makes it especially annoying when such an attribute is missing. Maybe there is an option for the command line?

So I decided to make my own set of functions

You can probably make your own NDK.
Or switch to a more compatible compiler. My observation is that the version of a gcc-port directly correlates to the incompatibility with classic AmigaOS compilers.

[JOB]

I'm also using gcc from the BartmanAbyss VS code extension (like you, if I have a look at your first attached file), and to get rid of the errors I just "undefine" __stdargs by specifying -D__stdargs= in the Makefile at the end of the CCFLAGS (and then I write my own code of the alib functions I want to use)

[emiespo]

Originally Posted by JOB

I'm also using gcc from the BartmanAbyss VS code extension (like you, if I have a look at your first attached file), and to get rid of the errors I just "undefine" __stdargs by specifying -D__stdargs= in the Makefile at the end of the CCFLAGS (and then I write my own code of the alib functions I want to use)

I have some code where I was doing exactly this (MacOs), now for some reason I need to recompile the whole thing under Windows, and indeed it started failing complaining about __stdargs. The same code - clean checkout - compiles just fine in MacOs.

Now I wonder: why is that? I can't see anything Win (nor Darwin) specific in the includes under the extension folder... also, where could I find an example `clib/compiler_specific.h` file?


NB. Using that -D setting did the trick, although there were a few extra quirks under windows, eventually *it seems* to have compiled. Will check if it works tomorrow.

[Olaf Barthel]

Originally Posted by emiespo

I have some code where I was doing exactly this (MacOs), now for some reason I need to recompile the whole thing under Windows, and indeed it started failing complaining about __stdargs. The same code - clean checkout - compiles just fine in MacOs.

Now I wonder: why is that? I can't see anything Win (nor Darwin) specific in the includes under the extension folder... also, where could I find an example `clib/compiler_specific.h` file?

Have a look at the AmigaOS Native Development Kit 3.2 Release 4 archive, please. When unpacked, you should be able to find the "compiler-specific.h" file (note the dash between "compiler" and "specific"!) under "NDK3.2/Include_H/clib". You do not need to include "clib/compiler-specific.h" in your source code. The operating system header files will pull it in "automatically" when it is needed.

The NDK3.2R4 'C' header files were last updated in February 2022 and AmigaOS NDK 3.2 Release 5 is still in the works. While the version of "compiler-specific.h" in NDK 3.2R4 is not as good as it could possibly be (vbcc, gcc support need updating, and thanks to both Christian Sauer & Frank Wille, will be improved in release 5), it should see you through.

Please check if your current 'C' header files are much older than what you can find in the AmigaOS NDK 3.2 Release 4 archive. As a rule, you should not be forced to reimplement the fundamental functions which the native development kit already provides for you.

[emiespo]

Originally Posted by Olaf Barthel

Have a look at the AmigaOS Native Development Kit 3.2 Release 4 archive, please. When unpacked, you should be able to find the "compiler-specific.h" file (note the dash between "compiler" and "specific"!) under "NDK3.2/Include_H/clib". You do not need to include "clib/compiler-specific.h" in your source code. The operating system header files will pull it in "automatically" when it is needed.

The NDK3.2R4 'C' header files were last updated in February 2022 and AmigaOS NDK 3.2 Release 5 is still in the works. While the version of "compiler-specific.h" in NDK 3.2R4 is not as good as it could possibly be (vbcc, gcc support need updating, and thanks to both Christian Sauer & Frank Wille, will be improved in release 5), it should see you through.

Please check if your current 'C' header files are much older than what you can find in the AmigaOS NDK 3.2 Release 4 archive. As a rule, you should not be forced to reimplement the fundamental functions which the native development kit already provides for you.

Thanks a lot for your insights, I'll give them a look asap (I am on a Mac now, where for some reason FS-UAE doesn't work anymore in Ventura). The VSCode extension does not include std*.h definitions, I believe it needs GCC specific implementations of the stdlib?

What puzzled me is that the same code compiles in OSX, gives errors in Windows. The OS includes seem to be the same.