You are not logged in.
Lost Password?


Register To Post



 Bottom   Previous Topic   Next Topic

#1
Fixing GCCVB 4.x Issues
Posted on: 2015/4/1 21:26
Virtual Freak
Joined 2014/8/31
USA
83 Posts
Long Time User (5 Years)App Coder
In my (nonexistent) spare time, I'd like to take a look at trying to fix GCCVB bugs. This means that I'd need a copy of the GCC source code to compile/make changes as well as the relevant patches to add the v810 backend.

First things first, before I attempt to fix ANY bugs, I need to compile the darn thing for Windows. I know there are instructions on how to compile GCCVB for Cygwin, but the 4.x version I have is in fact for MinGW. Does anyone have instructions on how compile for MinGW (I think RunnerPack did this port)?

Perhaps some of us could collaborate to create a document on how to build gccVB for Cygwin, Linux, and BSD users?

From what I know, GCCVB 4.x at present will sometimes generate code that points to code offsets in RAM, even when the linker script explicitly gives the correct code reigons, and a user didn't do the copy of code themselves to RAM (not that passing a fcn pointer to memcpy is legal C anyway :P). Are there any other bugs anyone has run into?
Top

#2
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/4/2 0:29
PVB Elite
Joined 2003/7/26
USA
1464 Posts
PVBCC EntryCoderContributorSpecial AchievementTop10 PosterHOTY09 EntryLong Time User (15 Years) App Coder20+ Game RatingsPVBCC 2013 Entry
Thanks for offering to look into this, cr1901!

If your MinGW installation includes the MSYS bash terminal, you should be able to follow the steps in this post, perhaps with a few minor modifications depending on whether you get errors and what they are.

The rest of that thread contains a lot of other information that might also be of use.

I don't recall where I got the actual patches I used, but they're in an archive attached to one of the gcc4-related threads, so the search function should get you there fairly quickly.
Top

#3
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/4/2 6:55
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (11 Years) App Coder
Off the top of my head:

1) Biggest problem so far is that GCCVB 4.x will sometimes generate relative jumps that are offset by some power of two ahead of where their proper destination should be. This becomes a huge problem when these jumps are executed repeatedly, as eventually the PC will wrap and wind up in video memory or elsewhere. I wrote a tool that operates on the final .elf file and attempts to correct these bogus jumps, but it's more of a bandaid than a solution. http://www.planetvb.com/modules/newbb ... t_id=31203#forumpost31203

2) Optimization is lousy. It's better in 4.x but still carries the baggage from the 2.x patches upon which the v810 support is based. So some operations such as 32-bit loads and subroutine calls are hardcoded as a certain sequence of assembly instructions when the compiler might be able to be clever about it (for example, doing several consecutive loads of RAM addresses-- movhi hi(0x05000000),rN should only need to be done once)

3) Found a bug recently in the version of gas that ships with GCCVB 4.x where sometimes a bne instruction-- written in the assembly source *as a bne instruction*-- will assemble to a be and a jr instruction. There is no reason whatsoever that I can think of why this should happen.

4) The frame pointer is assigned to register r29 I think, which is normally used by the bitstring instructions. I've never seen documentation for the v810 that says where the frame pointer should go, but since the frame pointer is irrelevant for VB development, I just pass -fomit-frame-pointer when compiling. I mention it here for completeness.
Top

#4
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/4/2 6:58
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (11 Years) App Coder
See also this post: http://www.planetvb.com/modules/newbb ... t_id=30370#forumpost30370
Top

#5
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/4/2 7:53
Virtual Freak
Joined 2014/8/31
USA
83 Posts
Long Time User (5 Years)App Coder
Quote:

Oh look, me bringing the exact same topic up months ago and not following through XD. What else is new in my life?

Erm, do you know if the 4.8 patches are floating around?

I have a Linux box in the living room. I think I want to massage the patches out on that before I attempt a MinGW build. One problem with MSYS for me is that builds using ./configure and make are slow as molasses due to POSIX emulation.

EDIT: I found your download link which includes just the patches. This permits me to apply to a unmodified source tree which is exactly what I wanted. Nice!

Where did the files binutils-2.20.1-vb.patch, gcc-4.4.2-vb.patch, and newlib-1.17.0-vb.patch (without authors appended) come from? Were those from back when v810 support was in the main tree?

EDIT 2: Is there any particular reason that the newlib patch needs to be 300kB? Most of the patch seems to be autoconf macros and other build system BS.
Edited by cr1901 on 2015/4/2 8:11
Edited by cr1901 on 2015/4/2 8:16
Top

#6
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/4/3 2:23
Virtual Freak
Joined 2014/8/31
USA
83 Posts
Long Time User (5 Years)App Coder
Using an Ubuntu 12.04 machine...

Binutils compiled ok with blitter's script, since -Wno-error was on :P.

JWeinberg's patch to the predicates machine description file does not apply correctly:


What gcc/config/v810/predicates.md actually contains (line 79):

(define_predicate "special_symbolref_operand"
  
(match_code "symbol_ref")
{
  if (
GET_CODE (op) == SYMBOL_REF)
    return (
SYMBOL_REF_FLAGS (op) & (SYMBOL_FLAG_ZDA SYMBOL_FLAG_TDA SYMBOL_
FLAG_SDA
)) != 0;
  else if (
GET_CODE (op) == CONST)
    return (
GET_CODE (XEXP (op0)) == PLUS
            
&& GET_CODE (XEXP (XEXP (op0), 0)) == SYMBOL_REF

            
&& GET_CODE (XEXP (XEXP (op0), 1)) == CONST_INT
            
&& CONST_OK_FOR_K (INTVAL (XEXP (XEXP (op0), 1))));

  return 
FALSE;
})



What the JWeinberg's patch thinks is at that location:

(define_predicate "special_symbolref_operand"
   
(match_code "symbol_ref")
 {
+  if (
GET_CODE (op) == CONST
+      && 
GET_CODE (XEXP (op0)) == PLUS
+      && GET_CODE (XEXP (XEXP (op0), 1)) == CONST_INT
+      && CONST_OK_FOR_K (INTVAL (XEXP (XEXP (op0), 1))))
+    
op XEXP (XEXP (op0), 0);
+
   if (
GET_CODE (op) == SYMBOL_REF)
-    return (
SYMBOL_REF_FLAGS (op) & (SYMBOL_FLAG_ZDA SYMBOL_FLAG_TDA SYMBOL
_FLAG_SDA
)) != 0;
-  else if (
GET_CODE (op) == CONST)
-    return (
GET_CODE (XEXP (op0)) == PLUS
-           && GET_CODE (XEXP (XEXP (op0), 0)) == SYMBOL_REF
-           && ENCODED_NAME_P (XSTR (XEXP (XEXP (op0), 0), 0))
-           && 
GET_CODE (XEXP (XEXP (op0), 1)) == CONST_INT
-           && CONST_OK_FOR_K (INTVAL (XEXP (XEXP (op0), 1))));
+    return (
SYMBOL_REF_FLAGS (op)
+           & (
SYMBOL_FLAG_ZDA SYMBOL_FLAG_TDA SYMBOL_FLAG_SDA)) != 0;

   return 
FALSE;
 })


Perhaps this was an oversight that wasn't caught? I only found it by accident, tbh.
Top

#7
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/4/3 9:15
Nintendoid!
Joined 2007/12/14
169 Posts
CoderLong Time User (11 Years) App Coder
v810 support hasn't been in GCC mainline since version 2.x IIRC. I got the 4.4.2 patches from dasi; perhaps he wrote them originally but I honestly have no idea. I think the v810 patches are largely based on existing support for the v850, which is similar.

The 4.8 patches are part of "devkitV810," which as far as I can tell is just a fancy name for GCC + some auxiliary tools. It's supposedly being worked on by dasi and/or Guy Perfect, but I haven't seen or heard anything from either of them regarding that project in a long time. I think they might be floating around out there on a Git server somewhere...
Top

#8
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/8 7:55
Virtual Freak
Joined 2014/8/31
USA
83 Posts
Long Time User (5 Years)App Coder
I'm just going to go ahead and use my best judgment to combine the incompatible patches.

Most of the work is obviously done... my first step is to examine the machine description language and see if I can't figure out what's going on.

Against my better judgment, I may attempt to just port against a clean GCC tree- I recently figured out how to add a dummy i8086 (not a typo) target just for kicks, and it's not like the .md format has changed significantly. It's more work though :/.

Also, I want to make something clear- this is a project that will take me months on and off working on it. Mainly getting used to the GCC source tree and finding things that work and things that don't. But it's worth a try, just to say I did it :P.
Top

#9
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/8 20:01
Nintendoid!
Joined 2006/11/16
139 Posts
Long Time User (12 Years)
How about porting V810 to LLVM instead of trying to fix the gcc port? Added benefit of re-usability, clang, etc.

cYa,

Tauwasser
Top

#10
Re: Fixing GCCVB 4.x Issues
Posted on: 2015/5/9 10:59
Virtual Freak
Joined 2014/8/31
USA
83 Posts
Long Time User (5 Years)App Coder
Well, I'm not good with C++11, and in my experience dealing with GCC's machine descriptions is easier than dealing with LLVM IR.

Nevertheless, since this a months-long thing, it's worth a try, and I already have my own personal fork of LLVM to play with.
Top

 Top   Previous Topic   Next Topic


Register To Post