Amiga GCC 8.3+gdb extension for Visual Studio Code

[deimos]

Originally Posted by Bartman

Hmm, haven't heard that one before. Have you tried installing the C/C++ extension?

I've now re-enabled the C/C++ extension and the error seems to have disappeared. Perhaps this requirement should be mentioned in the release notes, I'd disabled it because I took "no additional tools required" literally.

Originally Posted by Bartman

Ah yes, the dreaded spaces. Couldn't find a fix for it. IIRC gnumake doesn't like the spaces, not even when quoted.

Ah. I see, GNU make can't handle spaces in pathnames. Since 2002, no less.

[Bartman]

Originally Posted by deimos

I've now re-enabled the C/C++ extension and the error seems to have disappeared. Perhaps this requirement should be mentioned in the release notes, I'd disabled it because I took "no additional tools required" literally.

Thanks. Glad you got it working. Good to know, I will add the C/C++ extension to the "recommended extensions". I never noticed, cause I had it installed before

[deimos]

Could the example be extended to include an assembly source file as well as C? I've changed to the makefile to do this myself, but I'm not comfortable with makefiles / gnu make and don't know how to work around the a.mingw.s file that keeps appearing and wanting to be assembled.

# to generate assembler sources: -Wa,-ahl=$@.s

forward-to-backward = $(subst /,\,$1)

subdirs := $(wildcard */)
VPATH = $(subdirs)
csources := $(wildcard *.c) $(wildcard $(addsuffix *.c,$(subdirs)))
asmsources := $(wildcard *.s) $(wildcard $(addsuffix *.s,$(subdirs)))
cobjects := $(addprefix obj8mingw/,$(patsubst %.c,%.o,$(notdir $(csources))))
asmobjects := $(addprefix obj8mingw/,$(patsubst %.s,%.o,$(notdir $(asmsources))))
objects := $(cobjects) $(asmobjects)

# https://stackoverflow.com/questions/4036191/sources-from-subdirectories-in-makefile/4038459
# http://www.microhowto.info/howto/automatically_generate_makefile_dependencies.html

OUT = a.mingw
CC = m68k-amiga-elf-gcc

CCFLAGS = -g -MP -MMD -m68000 -Ofast -nostdlib -Wall -Wno-pointer-sign -Wno-unused-function -Wno-volatile-register-var -Wno-discarded-qualifiers -fomit-frame-pointer -fno-tree-loop-distribution -flto -fwhole-program
ASFLAGS = -Wa,-g,--register-prefix-optional
LDFLAGS = -Wl,--emit-relocs,-Ttext=0,-Map=$(OUT).map

all: $(OUT).exe

$(OUT).exe: $(OUT).elf
	$(info Elf2Hunk $(OUT).exe)
	@elf2hunk $(OUT).elf $(OUT).exe

$(OUT).elf: $(objects)
	$(info Linking a.mingw.elf)
	@$(CC) $(CCFLAGS) $(LDFLAGS) $(objects) -o $@
	@m68k-amiga-elf-objdump --disassemble -S $@ >$(OUT).s 

clean:
	$(info Cleaning...)
	@del /q obj8mingw $(OUT).* 2>nul || rmdir obj8mingw 2>nul || ver>nul

-include $(objects:.o=.d)

$(cobjects) : obj8mingw/%.o : %.c
	@if not exist "$(call forward-to-backward,$(dir $@))" mkdir $(call forward-to-backward,$(dir $@))
	$(info Compiling $<)
	@$(CC) $(CCFLAGS) -c -o $@ $(CURDIR)/$<

$(asmobjects) : obj8mingw/%.o : %.s
	@if not exist "$(call forward-to-backward,$(dir $@))" mkdir $(call forward-to-backward,$(dir $@))
	$(info Assembling $<)
	@$(CC) $(CCFLAGS) $(ASFLAGS) -xassembler-with-cpp -c -o $@ $(CURDIR)/$<

And could clean be added to tasks.json?

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "compile",
            "type": "shell",
            "command": "${command:amiga.bin-path}\\gnumake.exe",
            "args": [
                "-f", "Makefile8mingw", "-j4",
            ],
            "options": {
                "cwd": "${workspaceRoot}",
                "env": {
                    "PATH": "${command:amiga.bin-path}\\opt\\bin;${command:amiga.bin-path}"
                }
            },
            "problemMatcher": [
                {
                    "base": "$gcc",
                    "fileLocation": "absolute"
                }
            ],
            "presentation": {
                "echo": true,
                "reveal": "silent",
                "focus": false,
                "panel": "shared",
                "showReuseMessage": false,
                "clear": true
            },
            "group": {
                "kind": "build",
                "isDefault": true
            }
        },
        {
            "label": "clean",
            "type": "shell",
            "command": "${command:amiga.bin-path}\\gnumake.exe",
            "args": [
                "-f", "Makefile8mingw", "-j4", "clean"
            ],
            "options": {
                "cwd": "${workspaceRoot}",
                "env": {
                    "PATH": "${command:amiga.bin-path}\\opt\\bin;${command:amiga.bin-path}"
                }
            },
            "problemMatcher": [
                {
                    "base": "$gcc",
                    "fileLocation": "absolute"
                }
            ],
            "presentation": {
                "echo": true,
                "reveal": "silent",
                "focus": false,
                "panel": "shared",
                "showReuseMessage": false,
                "clear": true
            },
            "build"
        }
    ]
}

Also, could the --register-prefix-optional option allow most of the first 28 lines of gcc8_a_support.s to be removed, or is there more to it than that?

[Bartman]

Thanks. That's all good suggestions, will have a look next week and get back to you.

[deimos]

Is there a way to call an assembly routine with arguments as specific registers with this version of gcc?

I want to call a bit of existing code that takes a pointer in a0 and returns its result in d0. I'm used to adding bits to the C prototype to get this to work in other compilers, but no variation I've tried will compile under this gcc.

As far as I can tell, the gcc 8.3 manual does not cover this situation, only mixing inline assembly.

There must be a way, right? Or should I give up and write a wrapper that takes parameters from the stack?

[nogginthenog]

AmigaOS ROM calls work this way via the inlines.

void MyFunc(register int d0 __asm("d0"));

MyFunc(2);

results in:

moveq #2,d0
jsr _MyFunc

[deimos]

Originally Posted by nogginthenog

AmigaOS ROM calls work this way via the inlines.

void MyFunc(register int d0 __asm("d0"));

MyFunc(2);

results in:

moveq #2,d0
jsr _MyFunc

Yes, but in this case they don't:

C:/Users/Me/Desktop/AmigaDevelopment/test/test.c:57:38: error: expected ';', ',' or ')' before '__asm'

for the code:

void AquireLock(register BYTE * lock __asm("a0"));

and:

    AquireLock(&tripleBufferedDisplay->displayFlippingLock);

Makes me think there's something missing, either in GCC 8.3 or in my code.

I've worked around this situation by using GCC's extended inline assembly:

    {
        register BYTE * lock asm ("a0") = &tripleBufferedDisplay->displayFlippingLock;
        asm volatile (
            "jsr    _ReleaseLock"
            :
            : "r" (lock)
        );
    }

but that's not an easily maintainable solution.

[JuanLuis]

Originally Posted by Bartman

I made an open-source VS Code extension for Amiga 500 demo development. Repo on GitHub

One-stop Visual Code Extention to compile and debug Amiga C programs compiled by included gcc 8.3.0 in WinUAE.

Features

• No additional tools required. Everything is included (except Kickstart ROM ?). Ready to go make your next Amiga 500 production!
• State-of-the-art code generation by GCC with Link-Time-Optimizations (LTO) for increased performance and smaller code size
• IntelliSense
• Full source-level and assembly-level debugging with callstack, breakpoints, watches, registers, memory view with GDB-enabled WinUAE
• Fully AmigaOS compatible via included .h files
• INCBIN support
• Output to debug console from WinUAE
• WinUAE warp-launch (turbo-boot)
• WinUAE warp-mode control from your Amiga project

Have a look at My Seminar 'Modern Amiga 500 Demo Development' at Evoke 2019 for more information about this and behind-the-scenes of our 64k intro CODA.

I'm here for any questions, just wanted to get the first release out there.

First release with install instructions

I tried the example and It worked fine, but I have several questions.

- Does this compiler work with Kickstart 3.1?
I tried to compile for A1200 and I couldn't run successfully

- Is it possible to use C++ standard libraries, for instance: <iostream>, <vector>, etc.?
Compilation fails because compiler doesn't find include files iostream and vector. I don't have experience using Visual Studio Code and perhaps it's a problem easy to fix.

Thanks for the new C++ compiler.

[Marlon_]

Originally Posted by JuanLuis

I tried the example and It worked fine, but I have several questions.



- Does this compiler work with Kickstart 3.1?

I tried to compile for A1200 and I couldn't run successfully



- Is it possible to use C++ standard libraries, for instance: <iostream>, <vector>, etc.?

Compilation fails because compiler doesn't find include files iostream and vector. I don't have experience using Visual Studio Code and perhaps it's a problem easy to fix.



Thanks for the new C++ compiler.

AFAIK, only C is enabled, not C++. Hence the errors

[Bartman]

Originally Posted by deimos

Is there a way to call an assembly routine with arguments as specific registers with this version of gcc?

I want to call a bit of existing code that takes a pointer in a0 and returns its result in d0. I'm used to adding bits to the C prototype to get this to work in other compilers, but no variation I've tried will compile under this gcc.

As far as I can tell, the gcc 8.3 manual does not cover this situation, only mixing inline assembly.

There must be a way, right? Or should I give up and write a wrapper that takes parameters from the stack?

Have a look at https://github.com/BartmanAbyss/vsco...nline/macros.h

That's how it's done for the AmigaOS interface. You should be able to adapt from there.

Otherwise the default calling convention is to just push all arguments on the stack.

[deimos]

Thanks, that's exactly what I was looking for. In fact, I'm not sure why I didn't find it myself.

Originally Posted by Bartman

Have a look at https://github.com/BartmanAbyss/vsco...nline/macros.h

That's how it's done for the AmigaOS interface. You should be able to adapt from there.

Otherwise the default calling convention is to just push all arguments on the stack.

[bmpeter]

Hi,
great work, very good environment.
The sample project compiles well.

But when I look at a (Amiga) *.h file in Visual Studio Code (including the one from the sample project) the first 11 lines or so are displayed as error "Syntax Error" (see picture).
Am I missing something? All other files are without errors.

I also miss the stdlib.h, where can I find it?

Many greetings
Peter

[deimos]

Originally Posted by bmpeter

Hi,
great work, very good environment.
The sample project compiles well.

But when I look at a (Amiga) *.h file in Visual Studio Code (including the one from the sample project) the first 11 lines or so are displayed as error "Syntax Error" (see picture).
Am I missing something? All other files are without errors.

I also miss the stdlib.h, where can I find it?

Many greetings
Peter

I don't get a single squiggle in that or any of the other files in the sample project. I don't know what you could be missing, but I'm using this environment so maybe we can compare. I do seem to remember changing file associations for header files. Does your .vscode/settings.json file look like this:

{
    "C_Cpp.default.compilerPath": "c:\\Users\\bmpeter\\.vscode\\extensions\\bartman-abyss.amiga-debug-0.7.1\\bin\\opt\\bin\\m68k-amiga-elf-gcc.exe",
    "files.associations": {
        "*.h": "c"
    }
}

[bmpeter]

In my .vscode/settings.json file the entry with the files.associations was missing.
After editing and restarting Visual Studio Code the display of the *.h files now works correctly.

Thank you very much!

[deimos]

Originally Posted by bmpeter

Thank you very much!

No problem.

I hope you find your stdlib.h. I don't think it's included - my impression is that this project is aimed at coding directly against Amiga libraries / hardware, which is how I'm using it, i.e. using AllocMem instead of malloc, with only a handful of basic functions included in the support code / string.h.

[Bartman]

Originally Posted by deimos

No problem.

I hope you find your stdlib.h. I don't think it's included - my impression is that this project is aimed at coding directly against Amiga libraries / hardware, which is how I'm using it, i.e. using AllocMem instead of malloc, with only a handful of basic functions included in the support code / string.h.

Correct. No standard C library is provided. memcpy, memset is required because the compiler uses it even if it's not used in the original source.

[Martin Piper]

Very very impressive. Excellent and very easy integration. I also encountered the space in file paths issue, but it's only a small issue really. I unzipped VSCode C:\Temp\Downloads\VSCode and used portable mode (create a data directory) ( https://code.visualstudio.com/docs/editor/portable ) which put the extension and all the tools into the "data" directory.

The debugger support is also really very good.

I was looking around the tool chain build code but couldn't find the option to generate code for an absolute address instead of relocatable code? The use case here is to auto generate an ADF with a custom boot block that simply loads a whole chunks of tracks in raw mode into a fixed memory address (e.g. 0x20000) and just executes. Debugging that would be rather useful.

-- Edit --
After a bit of digging if I change the tasks.json LDFLAGS from: -Wl,--emit-relocs,-Ttext=0,-Map=$(OUT).map
To: LDFLAGS = -Wl,--emit-relocs,-Ttext=0,-Map=$(OUT).map,--section-start=.text=0x20000

Then this does change the code "_start" address in the ELF disassembly from 0x0 to 0x20000.
e.g. 20000: 4ef9 0002 0006 jmp 20006 <main>

Then in Makefile8mingw
Add to the: $(OUT).exe: $(OUT).elf
@elf2hunk $(OUT).elf $(OUT).bin.rel -bin -pcrel

This will output the ELF as a binary file which will 0x20000 zero bytes at the start since the --section-start uses that offset.

[Spec-Chum]

Awesome work.

Had a quick play and converted my asm takeover code to C and it worked

One snag, however, I couldn't figure out how to put the copperlist array into chip mem? I tried

__chip

but it didn't work. Using attributes didn't work either as it just says they're disabled.

Any idea how to specify something needs to be in chip mem?

Here's the full code, it kinda just draws a flag, but I'm quite a noob, so this probably isn't the best way of doing it lol

#include "support/gcc8_c_support.h"
#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/graphics.h>
#include <graphics/gfxbase.h>
#include <graphics/view.h>
#include <exec/execbase.h>
#include <hardware/Custom.h>
#include <hardware/intbits.h>

struct ExecBase *SysBase;
struct GfxBase *GfxBase;
volatile struct Custom *Custom;

struct View *OldView;
static UWORD oldInt;
static UWORD oldDMA;

APTR cl;

// Copperlist (FIXME: This should be in chipmem)
static UWORD copperlist[] = 
{
	    0x0100, 0x0200,		// don't need any Bitplanes
        0x0180, 0x0f00,		// Colour00 = red
        0x8001, 0xff00,     // wait until VPos = 0x80
        0x0180, 0x0fff,     // Colour00 = white
        0xd001, 0xff00,		// wait until VPos 0xd0
        0x0180, 0x000f, 	// Colour00 = blue
		0xffff, 0xfffe		// end list
};

int main()
{
	SysBase = *((struct ExecBase**)4UL);
	Custom = (struct Custom*)0xdff000;

	GfxBase = (struct GfxBase*)OpenLibrary("graphics.library", 0);

	// put copperlist in chip mem (FIXME: must be a way to put copperlist[] there?)
	cl = AllocMem(sizeof(copperlist), MEMF_CHIP);
	CopyMem(copperlist, cl, sizeof(copperlist));

	// Save original view
	OldView = GfxBase->ActiView;

	// Set clean view
	LoadView(0);
	WaitTOF();
	WaitTOF();

	// Save interrupts and DMA
	oldDMA = Custom->intenar;
	oldInt = Custom->dmaconr;

	// disable all interrupts
	Custom->intena = 0x7fff;

	// disable all DMA
	Custom->dmacon = 0x7fff;

	// set cl1 to our copper
	Custom->cop1lc = (ULONG)cl;
	
	// enable selected DMA
	Custom->dmacon = 0x8280;	// No Blitter or sprites, only copper

	// loop until mouse clicked
	while(((*(volatile UBYTE*)0xbfe001) & 64))
	{

	}

	// restore interrupts and DMA
	Custom->dmaconr = oldDMA | 0x8000;
	Custom->intenar = oldInt | 0x8000;

	// restore orginal copper
	Custom->cop1lc = (ULONG)GfxBase->copinit;

	// restore old view
	LoadView(OldView);
	WaitTOF();
	WaitTOF();

	// free copperlist memory
	FreeMem(cl, sizeof(copperlist));

	CloseLibrary((struct Library*)GfxBase);

	return 0;
}

[deimos]

I don't believe you can because the elf format has no concept of chip ram. At the moment I'm just using a CopyToChipMem function that allocates chip memory and copies data over. Not ideal. I think the only way round this would be to rework the link step so that your chip memory data can be done as amiga hunks, possibly from assembler, but I'm not sure it's possible without losing too many of the advantages this environment gives. There's another thread that talks about possible approaches somewhere. I've just decided to not worry about it until I have too much chip memory data to hold two copies of.

[Spec-Chum]

Originally Posted by deimos

I don't believe you can because the elf format has no concept of chip ram. At the moment I'm just using a CopyToChipMem function that allocates chip memory and copies data over. Not ideal. I think the only way round this would be to rework the link step so that your chip memory data can be done as amiga hunks, possibly from assembler, but I'm not sure it's possible without losing too many of the advantages this environment gives. There's another thread that talks about possible approaches somewhere. I've just decided to not worry about it until I have too much chip memory data to hold two copies of.

Ah, of course, forgot it was elf.

Thanks