English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. C/C++ (http://eab.abime.net/forumdisplay.php?f=118)
-   -   Amiga GCC 8.3+gdb extension for Visual Studio Code (http://eab.abime.net/showthread.php?t=98525)

deimos 23 August 2019 12:14

Quote:

Originally Posted by Bartman (Post 1340619)
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.

Quote:

Originally Posted by Bartman (Post 1340619)
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 24 August 2019 01:02

Quote:

Originally Posted by deimos (Post 1340828)
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 26 August 2019 17:28

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.

Code:

# 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?

Code:

{
    // 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 01 September 2019 21:54

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

deimos 11 September 2019 14:18

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 11 September 2019 21:06

AmigaOS ROM calls work this way via the inlines.

Code:

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

MyFunc(2);
results in:

Code:

moveq #2,d0
jsr _MyFunc


deimos 11 September 2019 21:25

Quote:

Originally Posted by nogginthenog (Post 1344974)
AmigaOS ROM calls work this way via the inlines.

Code:

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

MyFunc(2);
results in:

Code:

moveq #2,d0
jsr _MyFunc


Yes, but in this case they don't:

Code:

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

Code:

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

Code:

    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:

Code:

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

but that's not an easily maintainable solution.

JuanLuis 13 September 2019 19:19

Quote:

Originally Posted by Bartman (Post 1339949)
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_ 13 September 2019 23:36

Quote:

Originally Posted by JuanLuis (Post 1345306)
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 18 September 2019 22:39

Quote:

Originally Posted by deimos (Post 1344898)
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 19 September 2019 10:28

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

Quote:

Originally Posted by Bartman (Post 1346372)
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 24 September 2019 18:48

1 Attachment(s)
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 24 September 2019 20:03

Quote:

Originally Posted by bmpeter (Post 1347528)
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:

Code:

{
    "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 24 September 2019 21:20

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 24 September 2019 22:12

Quote:

Originally Posted by bmpeter (Post 1347569)
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 25 September 2019 16:39

Quote:

Originally Posted by deimos (Post 1347592)
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 09 October 2019 17:14

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 12 October 2019 14:10

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
Code:

__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

Code:

#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 12 October 2019 17:24

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 12 October 2019 18:48

Quote:

Originally Posted by deimos (Post 1350742)
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 :)


All times are GMT +2. The time now is 19:40.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.04990 seconds with 11 queries