Subject: Re: problem in 1.23

From: Zheng Gengbing <[email-masked]>
Date: Fri, 5 Apr 1996 10:16:17 +0800 (EAT)

On Thu, 4 Apr 1996, Guansong Zhang wrote:

> Hi,
> 
> After I got 1.23, I am really glad that our work become converging!
> 
> I found only the following things be problem.
> 
> 1). tag.h
> 
> in src/include, Makefile can generate a tag.h. But when I grep tag.h in subdir,
> I don't find any file need it.
> 

	That's for Vdump . I will change that .

> 2). intrinsic.d
> 
> Another thing, could you implement intrinsic.dep in defferent way?
> 
> Though we have FixSourceFile to deal with it. I think it is not a good way to
> change source code when ever we do make.
>

	I found in many good programs , such as gcc , they also fix source 
codes during make time . I think it is not a problem . 

> intinsic.dep is used to record prototype of intrinsic functions. Why don't let
> hpfcc have the contents of it other than opening a file?
>

      Unlike error.file , we need both hpf2dep & hpfcc to compile the 
intrinsic.f . It's also very hard to let hpfcc to have the contents of the 
file just use #define . Another strategy is that  we can define an c 
form(structure) to store the prototypes of nearly 200 functions and write a 
converter to convert them to AST . I'v already tried before , but when 
encountered with the  interface definition of a function, I cannot write a c 
structure to describe the prototype . 
     Why so complex ? Why don't we  use the achivement we already have 
since we do have a HPF compiler ?

> 
> Of cause, putting an absolute path in source code, also can solve the problem.
> But I don't know which is better compared with using environment varibles to
> indicate a specific postion, you can compare them.
> 

     Such as cc , I cannot find any environment varibles set about C compiler. 
Set environment varibles also make users uncomfortable.

     Why not put intrinsic.dep in lib like cc ? CC use the standard C library
libc.sl file stored separately in /lib  from /bin/cc itself . 

     Using independent standard library have other advantage . This make 
the project flexible. It become easy for us and other users to add new standard 
library functions to the project ,only by writing the function prototype in HPF 
language. If we use c structure to descibe the prototype, how can other 
pepole understand and change the source codes of a compiler ?! 
	Using compiler to do this work also conform to the principle that using 
the language itself to expand it .

> 3. .lst file
> 
> During hpfcc, a .lst file will be generated (just the source file with line
> number). It must be for Vdump, right? HIT's dumpdep also generate side files
> for reveal. Since we won't keep this two part in our main project. Please drop
> it off. I will also inform HIT to do so in dumpdep.
> 

	Ok, I will delete that in next version .But I think it's impolitical to 
keep the graphic interface out of the project. How can pepole  understand 
so many bfnds , llnds and symbs in dep file without any graphic help ?

> 4. things under src/tool
> 
> In 1.22, I let the thing under src/tool are same in both PKU and HIT version. I
> noticed unparse.c was change, (with an empty function added) it must for gcc in
> your machine.

	That's right , since we have a low version of gcc .
 
> But why dumpnode.c was also changed?
> 
> On line 39, it was changed to
> 
> char   *tag[910];
> 
> from
> 
> char   *tag[610];
> 
> I don't find anything else different under src/tool.
> 

	This change is important , because the number of our macro definitions 
in tags.h have reached  857 . The array must have a larger size.

Zheng Gengbin

***************************************************************************
*     Zheng Gengbin                 *                                     *
*                                   *                                     *
*  Dept. of Computer Science        *  Phone:  86-10-2585088              *
*         & Technology              *  Email:                             *
*                                   *      [email-masked]   *
*  Peking University P.R.China      *  Mail:                              *
*                                   *      Room 1077 ,Building 47,        *
*                                   *      Peking University, P.R.China   *
***************************************************************************