In message <576E69AA.4090201@aaug.net>
John Tytgat <John.Tytgat@aaug.net> wrote:
>It's roughly two years ago I last contributed to AsAsm so I'm not 100%
>sure any more about all following details.
>
>The idea of AsAsm is to be compatible with ROOL's ObjAsm (incl. command
>line options) and on top of that not only support AOF but also the ELF
>file format. That also means following what ARM adds as functionality
>to their assembler. So that's why at some point the -cpu/-fpu options
>appeared and the -soft-float one got dropped.
>
>It is (was) work in progress. For how things are to be implemented in
>the ELF file format I followed what ARM defined in their public EABI/ELF
>documents. Those -cpu/-fpu options are, partly, defining the EABI
>flavour needs to be written, including the EABI object attributes. That
>hasn't happened, hence, I believe we're now writing a pre-EABI ELF
>format which is rightfully considered hard-float by the binutils linker.
>
>By just defining ELF_EABI at build time you fall by default in the
>soft-float case (but also claim to be EABI compliant which I'm not sure
>if that's really true) but the real way forward is to write proper EABI
>object attributes based on command line options and attributes specified
>in the assembler source.
>
>Personally I find it pity that I ran out of steam doing all this,
>hopefully someone can pick up this project. I'm happy to give advice if
>wanted. If the RISC OS developer community wants to leverage on the
>existing free/open compiler/linker tools (gcc, llvm ecosystem, binutils,
>etc.) for RISC OS, as OS, development, this realistic rules out AOF and
>only leaves ELF file format. And then AsAsm is important piece in that
>puzzle. Or alternatively have to teach non-free/open ObjAsm to output
>ELF + DWARF and then also support ELF fully in the link linker...
Thanks for filling in the background, John. It explains the symptoms
I saw.
I think it's most unlikely that I could contribute - I'm not a good
enough programmer, certainly from the POV of reading other people's
code and understanding what needs to be done, on a large project
such as this, so I have to hope that someone cleverer than me can
do so.
Anyway, having discussed it and understood more: I guess the right
thing for me to do now is put in a bug report so it can be tracked?
Dave
____________________________________________________________
Send any screenshot to your friends in seconds...
Works in all emails, instant messengers, blogs, forums and social networks.
TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if2 for FREE
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Sunday, 26 June 2016
Saturday, 25 June 2016
Re: [gccsdk] asasm always claims to want hardware FP
On 06/23/2016 04:23 PM, Dave Higton wrote:
> There seems to be a problem with asasm of gcc 4.7.4. See the ROOL
> Community Support forum, topic "DeskLib and GCC 4.7.4" for details.
>
> In short, even the most trivial code assembled with asasm 2.01 r6919
> results in an ELF file that claims to use hardware FP (even though
> there is no FP in the code at all), and I haven't found it possible
> to influence this. r5871 accepted a command line option -soft-float
> that r6919 doesn't. r6919 accepts an option -fpu= but none of the
> 53 options available causes it to change its behaviour.
It's roughly two years ago I last contributed to AsAsm so I'm not 100%
sure any more about all following details.
The idea of AsAsm is to be compatible with ROOL's ObjAsm (incl. command
line options) and on top of that not only support AOF but also the ELF
file format. That also means following what ARM adds as functionality
to their assembler. So that's why at some point the -cpu/-fpu options
appeared and the -soft-float one got dropped.
It is (was) work in progress. For how things are to be implemented in
the ELF file format I followed what ARM defined in their public EABI/ELF
documents. Those -cpu/-fpu options are, partly, defining the EABI
flavour needs to be written, including the EABI object attributes. That
hasn't happened, hence, I believe we're now writing a pre-EABI ELF
format which is rightfully considered hard-float by the binutils linker.
By just defining ELF_EABI at build time you fall by default in the
soft-float case (but also claim to be EABI compliant which I'm not sure
if that's really true) but the real way forward is to write proper EABI
object attributes based on command line options and attributes specified
in the assembler source.
Personally I find it pity that I ran out of steam doing all this,
hopefully someone can pick up this project. I'm happy to give advice if
wanted. If the RISC OS developer community wants to leverage on the
existing free/open compiler/linker tools (gcc, llvm ecosystem, binutils,
etc.) for RISC OS, as OS, development, this realistic rules out AOF and
only leaves ELF file format. And then AsAsm is important piece in that
puzzle. Or alternatively have to teach non-free/open ObjAsm to output
ELF + DWARF and then also support ELF fully in the link linker...
John.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> There seems to be a problem with asasm of gcc 4.7.4. See the ROOL
> Community Support forum, topic "DeskLib and GCC 4.7.4" for details.
>
> In short, even the most trivial code assembled with asasm 2.01 r6919
> results in an ELF file that claims to use hardware FP (even though
> there is no FP in the code at all), and I haven't found it possible
> to influence this. r5871 accepted a command line option -soft-float
> that r6919 doesn't. r6919 accepts an option -fpu= but none of the
> 53 options available causes it to change its behaviour.
It's roughly two years ago I last contributed to AsAsm so I'm not 100%
sure any more about all following details.
The idea of AsAsm is to be compatible with ROOL's ObjAsm (incl. command
line options) and on top of that not only support AOF but also the ELF
file format. That also means following what ARM adds as functionality
to their assembler. So that's why at some point the -cpu/-fpu options
appeared and the -soft-float one got dropped.
It is (was) work in progress. For how things are to be implemented in
the ELF file format I followed what ARM defined in their public EABI/ELF
documents. Those -cpu/-fpu options are, partly, defining the EABI
flavour needs to be written, including the EABI object attributes. That
hasn't happened, hence, I believe we're now writing a pre-EABI ELF
format which is rightfully considered hard-float by the binutils linker.
By just defining ELF_EABI at build time you fall by default in the
soft-float case (but also claim to be EABI compliant which I'm not sure
if that's really true) but the real way forward is to write proper EABI
object attributes based on command line options and attributes specified
in the assembler source.
Personally I find it pity that I ran out of steam doing all this,
hopefully someone can pick up this project. I'm happy to give advice if
wanted. If the RISC OS developer community wants to leverage on the
existing free/open compiler/linker tools (gcc, llvm ecosystem, binutils,
etc.) for RISC OS, as OS, development, this realistic rules out AOF and
only leaves ELF file format. And then AsAsm is important piece in that
puzzle. Or alternatively have to teach non-free/open ObjAsm to output
ELF + DWARF and then also support ELF fully in the link linker...
John.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] asasm always claims to want hardware FP
On Fri, 24 Jun 2016 23:00:43 +0100, Theo Markettos <theo@markettos.org.uk> wrote:
> Possibly
> -apcs nofp/softfp
>
> since the default is:
> 3/noropi/norwpi/32bit/swstackcheck/fp/nointerwork/hardfp
> I think you need to flip the 'fp' and 'hardfp' parts of that.
Just to avoid any confusion, the APCS options /fp and /nofp are nothing to
do with floating point - they're talking about whether functions use r11 as
a frame pointer register.
Ben
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Possibly
> -apcs nofp/softfp
>
> since the default is:
> 3/noropi/norwpi/32bit/swstackcheck/fp/nointerwork/hardfp
> I think you need to flip the 'fp' and 'hardfp' parts of that.
Just to avoid any confusion, the APCS options /fp and /nofp are nothing to
do with floating point - they're talking about whether functions use r11 as
a frame pointer register.
Ben
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Friday, 24 June 2016
Re: [gccsdk] [Bug 263] New: Set Alias$command containing |M in generated !Run files causes trouble for string comparison
In message <bug-263-73@http.www.riscos.info/bugzilla3/>
bugzilla-daemon@riscos.info wrote:
> http://www.riscos.info/bugzilla3/show_bug.cgi?id=263
>
> Summary: Set Alias$command containing |M in generated !Run
> files causes trouble for string comparison
> Product: GCC/GCCSDK
> Version: other
> Platform: Other
> OS/Version: RISC OS
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Porting Scripts and Packaging
> AssignedTo: gccsdk-bugzilla@markettos.org.uk
> ReportedBy: bugzilla@markettos.org.uk
> Estimated Hours: 0.0
>
>
> Carlos Michael Santillan writes:
>
> I found a problem with some packages at riscos.info. I use the
> Vorbis-Tools for my little application OggTag. It looks that a lot of
> the command line programms at riscos.info has this problem.
>
>
> In Vorbis-Tools !Boot is the command
>
> Set Alias$vorbiscomment WimpSlot -min 686k |M Run
> <Vorbis-Tools$Dir>.vorbiscomment %%*0
>
> In !Run of OggTag I wanted to check for vorbiscomment with
>
> If "<Alias$vorbiscomment>" = "" Then Error OggTag requires the
> Vorbis-Tools
>
Why? you can check for the existance of the (simple) variable Vorbis-Tools$Dir or use
IfThere <Vorbis-Tools$Dir>.vorbiscomment Then Else Error OggTag requires the Vorbis-Tools
That would show that that directory has been booted, and that vorbiscomment exists.
BTW, checking for the existance of the alias, is still no guarantee that it is set up to work correctly, just that it exists, so no improvement really.
I appreciate your enthusiasm for tackling the obey language though.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
bugzilla-daemon@riscos.info wrote:
> http://www.riscos.info/bugzilla3/show_bug.cgi?id=263
>
> Summary: Set Alias$command containing |M in generated !Run
> files causes trouble for string comparison
> Product: GCC/GCCSDK
> Version: other
> Platform: Other
> OS/Version: RISC OS
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Porting Scripts and Packaging
> AssignedTo: gccsdk-bugzilla@markettos.org.uk
> ReportedBy: bugzilla@markettos.org.uk
> Estimated Hours: 0.0
>
>
> Carlos Michael Santillan writes:
>
> I found a problem with some packages at riscos.info. I use the
> Vorbis-Tools for my little application OggTag. It looks that a lot of
> the command line programms at riscos.info has this problem.
>
>
> In Vorbis-Tools !Boot is the command
>
> Set Alias$vorbiscomment WimpSlot -min 686k |M Run
> <Vorbis-Tools$Dir>.vorbiscomment %%*0
>
> In !Run of OggTag I wanted to check for vorbiscomment with
>
> If "<Alias$vorbiscomment>" = "" Then Error OggTag requires the
> Vorbis-Tools
>
Why? you can check for the existance of the (simple) variable Vorbis-Tools$Dir or use
IfThere <Vorbis-Tools$Dir>.vorbiscomment Then Else Error OggTag requires the Vorbis-Tools
That would show that that directory has been booted, and that vorbiscomment exists.
BTW, checking for the existance of the alias, is still no guarantee that it is set up to work correctly, just that it exists, so no improvement really.
I appreciate your enthusiasm for tackling the obey language though.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] asasm always claims to want hardware FP
On Thu, Jun 23, 2016 at 03:23:44PM +0100, Dave Higton wrote:
> In short, even the most trivial code assembled with asasm 2.01 r6919
> results in an ELF file that claims to use hardware FP (even though
> there is no FP in the code at all), and I haven't found it possible
> to influence this. r5871 accepted a command line option -soft-float
> that r6919 doesn't. r6919 accepts an option -fpu= but none of the
> 53 options available causes it to change its behaviour.
In the absence of anyone more knowledgeable chipping in, I think you might
want an -apcs flag.
The table of options is here:
http://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Ftools%2Fasasm%2Fsrc%2Fmain.c
Possibly
-apcs nofp/softfp
since the default is:
3/noropi/norwpi/32bit/swstackcheck/fp/nointerwork/hardfp
I think you need to flip the 'fp' and 'hardfp' parts of that.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> In short, even the most trivial code assembled with asasm 2.01 r6919
> results in an ELF file that claims to use hardware FP (even though
> there is no FP in the code at all), and I haven't found it possible
> to influence this. r5871 accepted a command line option -soft-float
> that r6919 doesn't. r6919 accepts an option -fpu= but none of the
> 53 options available causes it to change its behaviour.
In the absence of anyone more knowledgeable chipping in, I think you might
want an -apcs flag.
The table of options is here:
http://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Ftools%2Fasasm%2Fsrc%2Fmain.c
Possibly
-apcs nofp/softfp
since the default is:
3/noropi/norwpi/32bit/swstackcheck/fp/nointerwork/hardfp
I think you need to flip the 'fp' and 'hardfp' parts of that.
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] [Bug 183] Updated VNCServe
http://www.riscos.info/bugzilla3/show_bug.cgi?id=183
Theo Markettos <bugzilla@markettos.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |bugzilla@markettos.org.uk
Resolution| |FIXED
--- Comment #1 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:34:37 PDT ---
Jeffrey Lee has taken up maintenance, so I think VNCServe is well covered for
the time being.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Theo Markettos <bugzilla@markettos.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |bugzilla@markettos.org.uk
Resolution| |FIXED
--- Comment #1 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:34:37 PDT ---
Jeffrey Lee has taken up maintenance, so I think VNCServe is well covered for
the time being.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] [Bug 245] SWI &4C4152 not know
http://www.riscos.info/bugzilla3/show_bug.cgi?id=245
Theo Markettos <bugzilla@markettos.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #4 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:28:30 PDT ---
In the absence of any further info I'm closing this as a suspected emulator
bug. Happy to reopen if there's more details.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Theo Markettos <bugzilla@markettos.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #4 from Theo Markettos <bugzilla@markettos.org.uk> 2016-06-24 14:28:30 PDT ---
In the absence of any further info I'm closing this as a suspected emulator
bug. Happy to reopen if there's more details.
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Subscribe to:
Comments (Atom)