This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Algol Front end

> I am working on a COBOL front end for GCC.
> Modern CPUs and GCC have some
> trouble with COBOLisms like packed decimal.

It may be true that GCC has trouble with packed decimal, but it is plain
wrong to say that modern CPUs have trouble with this. You can do packed
decimal addition very efficiently on any modern RISC machine (the algorithms
for doing multiple digits in parallel are non-trivial, the otherwise OT
topic on counting bits is relevant here :-), but well known. 

All you are saying is that modern RISC machines do not have built in 
microprograms for doing these operations like IBM mainframes. But that's
true of many complex operations, and to say that because a machine does
not have some silly complex CISC instruction that "it has trouble" is
essentially questioning what by now is generally accepted understanding
of RISC design principles.

Yes, a COBOL compile will require a very large library, including not
only packed decimal, but also, as you note a sort merge (a relatively
easy component), and a full indexed file system. Creating the required
runtime library for a COBOL compiler is indeed a huge project (I should
know since I wrote the run time for the Realia COBOL compiler, now sold
by Computer Associates), including the sort and the indexed file system,
and literally hundreds of format specific routines (e.g. packed decimal

In fact, going back to the original statement, it really is NOT true that
GCC has trouble with packed decimal. No more than it has toruble in Ada
with decimal fixed-point types. It is just that the generated code will
have to call appropriate run-time routines. Big deal, so what?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]