headers
Anders Magnusson | 8 Feb 2009 10:51
Picon

Status update.

Not much has been written on the mailing list last month, but some
things has happened anyway, so I could just write some about it.

Most notably is the gcc compat attribute stuff, that now should work
at least in some sense.  The yacc code still needs sanity-check by
someone, I think but cannot be sure that it does the right thing.

All attributes should therefore be handled correctly.
Support for them says:

        aligned (partly supported)
        packed (supported)
        section (supported)

        unused (understood)
        deprecated (understood)
        noreturn (understood)
        format (understood)
        bounded (understood)
        nonnull (understood)
        sentinel (understood)

"supported" means that the attribute is handled as it should be.

"understood" means that the attribute syntax is checked but the compiler
ignores their meaning.

-- Ragge
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anders Magnusson | 8 Feb 2009 11:02
Picon

Using only softfloat in the compiler.

Hi,

I'm thinking on using only emulated floating point in the compiler.  Some
while ago I fixed softfloat routines for the DEC D and F float, so that
it could be cross-compiled on like an i386.  Anyway, I was thinking of
doing this for all other targets also to help up cross-compilation.

Currently cross-compilation do not work always, like on machines
where the the float sizes differ (even if both is ieee arithmetic).

The increase in compile time should be ~nil, not so much floating point
arithmetic is done in the compiler. The increase in code size should
also be very small, fmul would be replaced by a subroutine call.

Any comments?

-- Ragge
Permalink | Reply | 3 comments |
headers
Anders Magnusson | 8 Feb 2009 17:55
Picon

Target writers: soname syntax change.

(Technical information for target hackers...)

I've changed the syntax of the symtab soname member:
- If it is NULL, use exname(sp->sname) to get the external name for the symbol.
- If it is non-null, use it as the external name.

This means that renamed symbols, name mangled symbols etc. can set soname to
something useful that will not be touched by someone.

-- Ragge
Permalink | Reply | 0 comments |
headers
Gregory McGarry | 8 Feb 2009 21:01

Re: Using only softfloat in the compiler.

> I'm thinking on using only emulated floating point in the  
> compiler.  Some
> while ago I fixed softfloat routines for the DEC D and F float, so  
> that
> it could be cross-compiled on like an i386.  Anyway, I was thinking of
> doing this for all other targets also to help up cross-compilation.
>
> Currently cross-compilation do not work always, like on machines
> where the the float sizes differ (even if both is ieee arithmetic).
>
> The increase in compile time should be ~nil, not so much floating  
> point
> arithmetic is done in the compiler. The increase in code size should
> also be very small, fmul would be replaced by a subroutine call.
>
> Any comments?

I thought it would be better to keep floats in internal format and  
doing the conversion when the float is emitted.  That would speed up  
evaluation of expressions inside pcc.  But I can see that this would  
not work on hosts with a "smaller" float range.  Maybe there is  
benefit in having both mechanisms?

A few years ago I was using Matt Fredette's TME (the machine  
emulator) .  I recall that there was an extensive library for  
converting between floating-point formats.  It might be a good start.
Permalink | Reply | 2 comments |
headers
Joel Dahl | 8 Feb 2009 21:35
Picon
Favicon

Re: Status update.

Anders Magnusson skrev:
> Not much has been written on the mailing list last month, but some
> things has happened anyway, so I could just write some about it.

Thanks for the update.  It's good to see this project moving forward.

--
Joel
Permalink | Reply | 0 comments |
headers
Thorsten Glaser | 8 Feb 2009 21:24
Picon
Gravatar

Re: Using only softfloat in the compiler.

Gregory McGarry dixit:

> I thought it would be better to keep floats in internal format and doing the
> conversion when the float is emitted.

Loss of precision.

> converting between
> floating-point formats.

Loss of precision.

//mirabilos
--

-- 
23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)
23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit
     ⎜  grml hab, das muss ich dann gleich mal auf usb-stick installieren
-- Michael Prokop von grml.org über MirGRML und MirOS bsd4grml
Permalink | Reply | 0 comments |
headers
Anders Magnusson | 9 Feb 2009 18:25
Picon

Re: Using only softfloat in the compiler.

Gregory McGarry wrote:
>> I'm thinking on using only emulated floating point in the compiler.  Some
>> while ago I fixed softfloat routines for the DEC D and F float, so that
>> it could be cross-compiled on like an i386.  Anyway, I was thinking of
>> doing this for all other targets also to help up cross-compilation.
>>
>> Currently cross-compilation do not work always, like on machines
>> where the the float sizes differ (even if both is ieee arithmetic).
>>
>> The increase in compile time should be ~nil, not so much floating point
>> arithmetic is done in the compiler. The increase in code size should
>> also be very small, fmul would be replaced by a subroutine call.
>>
>> Any comments?
> 
> I thought it would be better to keep floats in internal format and doing
> the conversion when the float is emitted.  That would speed up
> evaluation of expressions inside pcc.  But I can see that this would not
> work on hosts with a "smaller" float range.  Maybe there is benefit in
> having both mechanisms?
> 
It just don't work having floats stored in the host floating point
format, it must be in the target format.  There are too many possible
differences when cross-compiling.

> A few years ago I was using Matt Fredette's TME (the machine emulator)
> .  I recall that there was an extensive library for converting between
> floating-point formats.  It might be a good start.
> 
The few float ops needed are not especially complex.  Look at the stuff I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Kuschnerus | 12 Feb 2009 16:56
Picon
Picon

Problem with FLEX

Hallo,

I tried a build on Ubuntu 6.06,
I did get problems with FLEX, 
Version of FLEX is 2.5.31
Version of GCC is 4.0.3

The following errors:
cpp/scanner.l: lines 537, 682, 804 yytext_ptr undeclared
ccom/scan.l: line 566 yytext_ptr undeclared

I did the following workaround, 
not being shure that this is quite ok:
I changed in the Makefiles the definition of LEX to LEX=flex -l
and removed -Werror
In cpp.h I changed "extern char *yytext;" to "extern char yytext[];"
In scan.l I removed the line 227.

With these changes the build did run successfully.
I assumme there is a little problem with config and version of FLEX.

Regards
Peter Kuschnerus
Permalink | Reply | 0 comments |
headers
Rudi Ludwig | 14 Feb 2009 22:26
Picon
Picon

daily tar-files with strange file names


Hello,

I was curious about pcc and downloaded the latest
tar.gz from ftp://pcc.ludd.ltu.se/pub/pcc/

pcc-cvs-090214.tgz

All filenames end in ",v" and trying to make sense out
of their contents it seams they got the version system's
information embedded.

I then used cvs which worked fine for me.

Rudi
Permalink | Reply | 1 comment |
headers
Anders Magnusson | 15 Feb 2009 10:06
Picon

Re: daily tar-files with strange file names

Rudi Ludwig wrote:
> Hello,
>
> I was curious about pcc and downloaded the latest
> tar.gz from ftp://pcc.ludd.ltu.se/pub/pcc/
>
> pcc-cvs-090214.tgz
>
> All filenames end in ",v" and trying to make sense out
> of their contents it seams they got the version system's
> information embedded.
>
> I then used cvs which worked fine for me.
>   
:-)  You fetched the raw copy of the cvs repository, hence the name cvs
in the filename.  What you want is pcc-090214.tgz, which is the 
distribution.

-- Ragge
Permalink | Reply | 0 comments |

Gmane