English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 23 August 2019, 12:14   #21
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 417
Quote:
Originally Posted by Bartman View Post
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 View Post
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.
deimos is online now  
Old 24 August 2019, 01:02   #22
Bartman
Registered User
 
Join Date: Feb 2019
Location: Munich, Germany
Posts: 14
Quote:
Originally Posted by deimos View Post
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
Bartman is offline  
Old 26 August 2019, 17:28   #23
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 417
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?

Last edited by deimos; 26 August 2019 at 19:40.
deimos is online now  
Old 01 September 2019, 21:54   #24
Bartman
Registered User
 
Join Date: Feb 2019
Location: Munich, Germany
Posts: 14
Thanks. That's all good suggestions, will have a look next week and get back to you.
Bartman is offline  
Old 11 September 2019, 14:18   #25
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 417
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?
deimos is online now  
Old 11 September 2019, 21:06   #26
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 857
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
nogginthenog is offline  
Old 11 September 2019, 21:25   #27
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 417
Quote:
Originally Posted by nogginthenog View Post
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.
deimos is online now  
Old 13 September 2019, 19:19   #28
JuanLuis
Registered User
 
Join Date: Dec 2018
Location: Málaga
Posts: 21
Quote:
Originally Posted by Bartman View Post
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.
JuanLuis is offline  
Old 13 September 2019, 23:36   #29
Marlon_
AmigaDev.com

Marlon_'s Avatar
 
Join Date: Mar 2016
Location: Sundsvall, Sweden
Age: 31
Posts: 599
Quote:
Originally Posted by JuanLuis View Post
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
Marlon_ is offline  
Old 18 September 2019, 22:39   #30
Bartman
Registered User
 
Join Date: Feb 2019
Location: Munich, Germany
Posts: 14
Quote:
Originally Posted by deimos View Post
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.
Bartman is offline  
Old 19 September 2019, 10:28   #31
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 417
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 View Post
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 is online now  
Old 24 September 2019, 18:48   #32
bmpeter
Registered User

 
Join Date: Sep 2019
Location: Brombachtal / Germany
Posts: 2
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
Attached Thumbnails
Click image for larger version

Name:	error_h.JPG
Views:	36
Size:	88.3 KB
ID:	64581  
bmpeter is offline  
Old 24 September 2019, 20:03   #33
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 417
Quote:
Originally Posted by bmpeter View Post
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"
    }
}
deimos is online now  
Old 24 September 2019, 21:20   #34
bmpeter
Registered User

 
Join Date: Sep 2019
Location: Brombachtal / Germany
Posts: 2
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!
bmpeter is offline  
Old 24 September 2019, 22:12   #35
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 417
Quote:
Originally Posted by bmpeter View Post
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.
deimos is online now  
Old 25 September 2019, 16:39   #36
Bartman
Registered User
 
Join Date: Feb 2019
Location: Munich, Germany
Posts: 14
Quote:
Originally Posted by deimos View Post
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.
Bartman is offline  
Old 09 October 2019, 17:14   #37
Martin Piper
Registered User

 
Join Date: Oct 2019
Location: Singapore
Posts: 2
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.

Last edited by Martin Piper; 12 October 2019 at 08:27.
Martin Piper is offline  
Old 12 October 2019, 14:10   #38
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 78
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;
}
Spec-Chum is offline  
Old 12 October 2019, 17:24   #39
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 417
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.
deimos is online now  
Old 12 October 2019, 18:48   #40
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 78
Quote:
Originally Posted by deimos View Post
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
Spec-Chum is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Amiga Assembly extension for Visual Studio Code prb28 Coders. Asm / Hardware 141 Today 14:19
Visual Studio Code Blitz Basic extension earok Coders. Blitz Basic 29 16 July 2019 18:59
very basic C/ASM/Visual Studio hand holding Sephnroth Coders. C/C++ 2 08 March 2016 21:15
Profiling WinUAE with Visual Studio 2013 mark_k support.WinUAE 3 14 January 2014 21:26

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:21.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.10486 seconds with 15 queries