Re: Ancient Fortran, help please

Re: Ancient Fortran, help please

[Bud Davis]

H Ben,

On first glance you have a mismatch between the type of a variable and
the data you are trying to initialize.  

But, in most cases, we here at gcc-help give erroneous advice when all
we see is a code fragment.  If you could make us a small, "should be
compilable" fragment showing both the declaration and the
data statement, maybe we can help out.

Here is an example that I think shows your problem, but it works !!

$ cat data.f
 
       INTEGER T
       DATA T      /'VHF     '/
       PRINT*,T
       END
$ g77 data.f
$ ./a.out
 541476950

also the output of "g77 --version" can be useful.


--bud 

Re: Ancient Fortran, help please

[Benjamin Joseph]

Ooops.  Yeah that might help.

Here's a complete picture of this section of code:

-----------beginning of file-----------------
       BLOCK DATA BNCSRC
       IMPLICIT REAL*8 (A-H,O-Z)
       INTEGER*2 ITABL, ITABL1, ITABL2
       LOGICAL*1 OTABL
       COMMON /BIAS/ TYPE(25), ITABL(5,25), OTABL(5,20)
       DIMENSION ITABL1(5,14), ITABL2(5,11)
       EQUIVALENCE  ( ITABL(1,1), ITABL1(1,1)) ,
      *             ( ITABL(1,15), ITABL2(1,1))
       DATA TYPE      /'VHF     ','MINITRCK','C-BAND  ','S-BAND  ',
      1                'USB30   ','USB85   ','VLFS    ','ATS     ',
      2                'ATS GRDD','NDS     ','SRE     ','LASER   ',
      3                'OPTICAL ','X-Y MMMM','        ','        ',
      4                '        ','        ','        ','        ',
      5                'PCE     ','LANDMARK','OABIAS  ','LANDMRK2',
      6                'HAP     ' /

 	some more stuff involving ITABL,ITABL1,ITABLE2...
-------------EOF---------------------------------
Here is the output of g77 --version

GNU Fortran (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
Copyright (C) 2004 Free Software Foundation, Inc.

---------------------------------------------

It looks like it's just defining a variable TYPE with a character array. 
Anyway, as far as compilability is concerned, this works for Intel Fortran 
Compiler 8.1.

Thanks for your patience.

-Ben

On Sat, 18 Dec 2004, Bud Davis wrote:

> H Ben,
>
> On first glance you have a mismatch between the type of a variable and
> the data you are trying to initialize.
>
> But, in most cases, we here at gcc-help give erroneous advice when all
> we see is a code fragment.  If you could make us a small, "should be
> compilable" fragment showing both the declaration and the
> data statement, maybe we can help out.
>
> Here is an example that I think shows your problem, but it works !!
>
> $ cat data.f
>
>       INTEGER T
>       DATA T      /'VHF     '/
>       PRINT*,T
>       END
> $ g77 data.f
> $ ./a.out
> 541476950
>
> also the output of "g77 --version" can be useful.
>
>
> --bud
>
>
>
>
>
>
>
>

Re: Ancient Fortran, help please

[Bud Davis]

On Sat, 2004-12-18 at 13:22, Benjamin Joseph wrote:
 
> 
> It looks like it's just defining a variable TYPE with a character array. 
> Anyway, as far as compilability is concerned, this works for Intel Fortran 
> Compiler 8.1.
> 

TYPE is declared by default to be of type REAL*8 by the IMPLICIT REAL
statement on line 2.

the Intel compiler is quite forgiving. to work with g77 you will have to
declare TYPE to be of an INTEGER or CHARACTER type.

It should be a very surgical and safe change, as it makes no sense
to either use or set TYPE(1) with a double precision real :)

       BLOCK DATA BNCSRC
       IMPLICIT REAL*8 (A-H,O-Z)
       INTEGER*8 TYPE


there is good information in the g77 info page concerning
running code from other fortran compilers. -finit-local-zero
and -fno-automatic are two options that are defaults for other
compilers.  you might want to think about these a bit before 
digging deep into the code if the runtime results are not as
expected.  nothing to do with the current issue, just something to keep
in mind.

don't let this little incompatibility dissuade you from using
g77. IMHO g77 is the most robust and flexible F77 compiler
available.  


HTH,
bud davis

Re: Ancient Fortran, help please

[Benjamin Joseph]

That worked!

Thank you,

-Ben


On Sat, 18 Dec 2004, Bud Davis wrote:

> On Sat, 2004-12-18 at 13:22, Benjamin Joseph wrote:
>
>>
>> It looks like it's just defining a variable TYPE with a character array.
>> Anyway, as far as compilability is concerned, this works for Intel Fortran
>> Compiler 8.1.
>>
>
> TYPE is declared by default to be of type REAL*8 by the IMPLICIT REAL
> statement on line 2.
>
> the Intel compiler is quite forgiving. to work with g77 you will have to
> declare TYPE to be of an INTEGER or CHARACTER type.
>
> It should be a very surgical and safe change, as it makes no sense
> to either use or set TYPE(1) with a double precision real :)
>
>       BLOCK DATA BNCSRC
>       IMPLICIT REAL*8 (A-H,O-Z)
>       INTEGER*8 TYPE
>
>
> there is good information in the g77 info page concerning
> running code from other fortran compilers. -finit-local-zero
> and -fno-automatic are two options that are defaults for other
> compilers.  you might want to think about these a bit before
> digging deep into the code if the runtime results are not as
> expected.  nothing to do with the current issue, just something to keep
> in mind.
>
> don't let this little incompatibility dissuade you from using
> g77. IMHO g77 is the most robust and flexible F77 compiler
> available.
>
>
> HTH,
> bud davis
>
>
>
>
>
>
>

custom CPU porting : guidance please

[sashti srinivasan]

Hello,
   I like to port complete gcc tool-chain including
gas,gasp,ld,binutils... to a custom CPU.  May I
request the mailing list the following:

  (1)  I intend doing it as a single man during
leisure time.  Please suggest me in approximately how
much time (in terms of hours) can I expect this port
to complete.

  (2)  Where can I find the documentation and other
resources regarding how to do the port.

  (3)  The goal is to port the tool-chain and build
operating systems like RTEMS, Linux etc. for this CPU.
 I will be very thankful to receive some broad
suggestions.

  Please guide me in carrying out the port.

With regards
Srinivasan


		
__________________________________ 
Do you Yahoo!? 
Dress up your holiday email, Hollywood style. Learn more. 
http://celebrity.mail.yahoo.com

Re: custom CPU porting : guidance please

[Sriharsha]

sashti srinivasan wrote:

>Hello,
>   I like to port complete gcc tool-chain including
>gas,gasp,ld,binutils... to a custom CPU.  May I
>request the mailing list the following:
>
>  (1)  I intend doing it as a single man during
>leisure time.  Please suggest me in approximately how
>much time (in terms of hours) can I expect this port
>to complete.
>  
>
Difficult to suggest how long it would take. It depends on a lot of 
things like your knowledge and experience with compilers, C language and 
computer architecture, the architecture of the Processor and the 
complexity involved. If it is similar to the standard processors, then, 
the port is a fairly simple one.

>  (2)  Where can I find the documentation and other
>resources regarding how to do the port.
>  
>
An excellant link is:
http://www.le-hacker.org/hacks/projects/microprocessor/compiler.html
And ofcourse, you always have the colossal documentation from gnu site.
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html or something similar
Finally, last but not the least..... try this:
http://gcc.gnu.org/readings.html where you find links to lots of stuff::::
Of special interest among them is:
Porting GCC for Dunces by Hans-Peter Nilsson.

>  (3)  The goal is to port the tool-chain and build
>operating systems like RTEMS, Linux etc. for this CPU.
>  
>
A good idea.

> I will be very thankful to receive some broad
>suggestions.
>  
>
You are always welcome.


Sriharsha

-- 
 *****************************
 * Sriharsha Vedurmudi			
 * Software Engineer		
 * 
 * Redpine Signals Inc.	
 * Gate #395, Plot 87,88			
 * Sagar Society, Road #2, 
 * Banjara Hills,		
 * Hyderabad - 500 034			
 * www.redpinesignals.com	
 *							
 * +91-40-23559911  (Office)
 * +91-98851-37338  (Mobile)
 *****************************

Re: custom CPU porting : guidance please

[sashti srinivasan]

Hello,
     Million thanks for your guidance.  I hope I'm
slowly understanding the big picture.  I got a few
other doubts, guidance will be very helpful.

  (1)  I suppose that 'gas' is much more machine
dependent than gcc.  Please guide me regarding where
can I find documents regarding how to port 'gas' to a
new CPU.

  (2)  Since rest of the utilities in binutils have
more to do with binary format than with architecture,
porting these(ld,nm,ar....) to a new CPU is going to
be farily simple.  Am I right?

  (3)  I like to port GDB also.  Please give me
pointers where I can find the corresponding
documentation.

  (4)  As a first step, I want to develop a gdb
simulator for the new CPU I have in mind.  Where can I
find the documentation describing how to write a
simulator.

  (5)  In porting GCC tool-chain to a new CPU
architecture, or in otherwords developing cross
tool-chain for a new CPU architecture, I assume that
following is the most appropriate sequence:
     (a)  Develop a simulator so that executables for
the new CPU can be run using GDB
     (b)  Port as so that programs can be written in
the assembly language of the CPU and assembled.
     (c)  Port gcc so that c programs can be written
to run on the target CPU
  Is this sequence correct?

Thanks in advance
Srinivasan
 --- Sriharsha <sriharsha.v@redpinesignals.com> wrote:

> 
> sashti srinivasan wrote:
> 
> >Hello,
> >   I like to port complete gcc tool-chain including
> >gas,gasp,ld,binutils... to a custom CPU.  May I
> >request the mailing list the following:
> >
> >  (1)  I intend doing it as a single man during
> >leisure time.  Please suggest me in approximately
> how
> >much time (in terms of hours) can I expect this
> port
> >to complete.
> >  
> >
> Difficult to suggest how long it would take. It
> depends on a lot of 
> things like your knowledge and experience with
> compilers, C language and 
> computer architecture, the architecture of the
> Processor and the 
> complexity involved. If it is similar to the
> standard processors, then, 
> the port is a fairly simple one.
> 
> >  (2)  Where can I find the documentation and other
> >resources regarding how to do the port.
> >  
> >
> An excellant link is:
>
http://www.le-hacker.org/hacks/projects/microprocessor/compiler.html
> And ofcourse, you always have the colossal
> documentation from gnu site.
> http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc.html or
> something similar
> Finally, last but not the least..... try this:
> http://gcc.gnu.org/readings.html where you find
> links to lots of stuff::::
> Of special interest among them is:
> Porting GCC for Dunces by Hans-Peter Nilsson.
> 
> >  (3)  The goal is to port the tool-chain and build
> >operating systems like RTEMS, Linux etc. for this
> CPU.
> >  
> >
> A good idea.
> 
> > I will be very thankful to receive some broad
> >suggestions.
> >  
> >
> You are always welcome.
> 
> 
> Sriharsha
> 
> -- 
>  *****************************
>  * Sriharsha Vedurmudi			
>  * Software Engineer		
>  * 
>  * Redpine Signals Inc.	
>  * Gate #395, Plot 87,88			
>  * Sagar Society, Road #2, 
>  * Banjara Hills,		
>  * Hyderabad - 500 034			
>  * www.redpinesignals.com	
>  *							
>  * +91-40-23559911  (Office)
>  * +91-98851-37338  (Mobile)
>  *****************************
> 
> 
>  

________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony

Re: custom CPU porting : guidance please

[Ian Lance Taylor]

sashti srinivasan <svasn_tcpip@yahoo.co.in> writes:

>   (1)  I suppose that 'gas' is much more machine
> dependent than gcc.  Please guide me regarding where
> can I find documents regarding how to port 'gas' to a
> new CPU.

gas is part of the GNU binutils.  binutils questions are best
addressed on the binutils mailing list.  For more information, see
http://sourceware.org/binutils/

The internal gas documentation can be found in gas/doc/internals.texi.

>   (2)  Since rest of the utilities in binutils have
> more to do with binary format than with architecture,
> porting these(ld,nm,ar....) to a new CPU is going to
> be farily simple.  Am I right?

Sort of.  You need to implement relocation handling appropriate for
your architecture, and that is trickier than it should be.

>   (3)  I like to port GDB also.  Please give me
> pointers where I can find the corresponding
> documentation.

See http://sourceware.org/gdb/

In particular, gdb/doc/gdbint.texinfo.

>   (4)  As a first step, I want to develop a gdb
> simulator for the new CPU I have in mind.  Where can I
> find the documentation describing how to write a
> simulator.

As far as I know, there isn't any.  Look at existing simulators.

>   (5)  In porting GCC tool-chain to a new CPU
> architecture, or in otherwords developing cross
> tool-chain for a new CPU architecture, I assume that
> following is the most appropriate sequence:
>      (a)  Develop a simulator so that executables for
> the new CPU can be run using GDB
>      (b)  Port as so that programs can be written in
> the assembly language of the CPU and assembled.
>      (c)  Port gcc so that c programs can be written
> to run on the target CPU
>   Is this sequence correct?

Pretty much.  You will want to write the disassembler when you write
the assembler.

Ian

Ancient Fortran, help please

[Benjamin Joseph]

Guys,

I have this horrible fortran problem.  I've got this ancient fortran code 
that refuses to compile any compiler except Intel Fortran Compiler--which 
is a problem because the computer we're running on is an Opteron, which is 
an AMD chipset.

If I try to compile it with g77 I get the following error:
------------
DATA TYPE      /'VHF     ','MINITRCK','C-BAND  ','S-BAND  ',
                          ^
Type disagreement between expressions at (?) and (^)
------------

I've searched the archives and have gotten some useful information, but it 
doesn't seem to solve the problem.  Here's the relevant post:

http://gcc.gnu.org/ml/gcc/1999-11n/msg00535.html

If anyone can point me in the right direction I would be eternally 
grateful.

-Ben