If you're up for a real challenge
Dan Sugalski
http://tiny-cobol.sourceforge.net/ If anyone wants to take a shot at
giving it a PIR back end... (And yes, this would actually be very
useful. Imagine using Parrot as a way to migrate legacy COBOL apps
to, well, almost anything else. This would be a Good Thing for an
awful lot of folks)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Tim Howell
module. A smaller section (with my first pass modifications for PASM)
is pasted below. Modifications are on lines prefixed with ###.
A quick glance over the code suggests that only this module would need
to be updated to generate PASM or PIR instead of x86 assembly. The
compiler also includes a runtime library--maybe this would be a good
candidate for the native call interface initially? Any calls to the
runtime library could be handled with NCI so that converting the library
could be put off.
One other thought: I don't have a great understanding of PMCs, but I
think they're intelligent registers. Why not create PMCs that simulate
the standard x86 registers? My idea isn't to coerce people to use an
inefficient system, but it seems like a lot of compilers might be more
easily modified to generate PASM if compiler updaters didn't need to
consider why a given x86 register was being used in the generator
function. That is, in my example, I don't know exactly why eax is used,
so I just substituted an integer register for eax, but if I could have
loaded an eax simulating PMC into P0 then I could have used set P0 with
more assurance that the code would do what I wanted.
if (sy == NULL) {
fprintf(o_src,"\txorl\t%%eax,%%eax\n");
### fprintf(o_src,"\tset\t%%I0,%%0\n");
return;
}
if (sy->litflag) {
int i, bSign=0;
char cDigit;
/* if it's an integer, compute it now, not at runtime!
*/
value = 0;
/* integer's name is just it's value in ascii */
for (i=0; (cDigit = sy->name[i]); i++) {
if (cDigit=='}') {
cDigit = 0;
} else if (cDigit=='{') {
cDigit = 0;
bSign = 1;
} else if ((cDigit >= 'A') && (cDigit <= 'I')) {
cDigit -= 'A'-1;
} else if ((cDigit >= 'J') && (cDigit <= 'R')) {
cDigit -= 'J'-1;
bSign = 1;
} else {
cDigit -= '0';
}
value = value * 10 + cDigit;
}
if (bSign)
value = -value;
fprintf(o_src,"\tmovl\t$%d,%%eax\n",(int)value);
### fprintf(o_src,"\tset\t$%d,%%I0\n",(int)value);
void value_to_eax ( struct sym *sy ) {
long long value;
long value2;
int stack_save;
#ifdef DEBUG_COMPILER
if (sy) fprintf(o_src,"# value_to_eax %s\n",sy->name);
#endif
if (sy == NULL) {
fprintf(o_src,"\txorl\t%%eax,%%eax\n");
return;
}
if (sy->litflag) {
int i, bSign=0;
char cDigit;
/* if it's an integer, compute it now, not at runtime!
*/
value = 0;
/* integer's name is just it's value in ascii */
for (i=0; (cDigit = sy->name[i]); i++) {
if (cDigit=='}') {
cDigit = 0;
} else if (cDigit=='{') {
cDigit = 0;
bSign = 1;
} else if ((cDigit >= 'A') && (cDigit <= 'I')) {
cDigit -= 'A'-1;
} else if ((cDigit >= 'J') && (cDigit <= 'R')) {
cDigit -= 'J'-1;
bSign = 1;
} else {
cDigit -= '0';
}
value = value * 10 + cDigit;
}
if (bSign)
value = -value;
fprintf(o_src,"\tmovl\t$%d,%%eax\n",(int)value);
value2 = value >> 32;
if ((value2!=0) && (value2!=-1))
fprintf(o_src,"\tmovl\t$%d,%%edx\n",(int)value2);
} else if (sy->type == DTYPE_BININT || sy->type == DTYPE_FLOAT)
{
/* load binary (comp) value directly */
/* %eax doesn't hold greater than 4 bytes binary types
so we use %edx to get the most significant part
*/
if (symlen(sy) > 4) {
fprintf(o_src,"\tleal\t%s,
%%eax\n",memrefat(sy));
fprintf(o_src,"\tmovl\t4(%%eax), %%edx\n");
fprintf(o_src,"\tmovl\t0(%%eax), %%eax\n");
} else {
if (symlen(sy)>=4) {
switch (sy->sec_no) {
case SEC_CONST:
fprintf(o_src,"\tmovl\tc_base%d+%d, %%eax\n",
pgm_segment,sy->location);
break;
case SEC_DATA:
fprintf(o_src,"\tmovl\tw_base%d+%d, %%eax\n",
pgm_segment,sy->location);
break;
case SEC_STACK:
fprintf(o_src,"\tmovl\t-%d(%%ebp), %%eax\n",sy->location);
break;
break;
}
} else {
switch (sy->sec_no) {
case SEC_CONST:
fprintf(o_src,"\tmovs%cl\tc_base%d+%d, %%eax\n",
varsize_ch(sy),pgm_segment,sy->location);
break;
case SEC_DATA:
fprintf(o_src,"\tmovs%cl\tw_base%d+%d, %%eax\n",
varsize_ch(sy),pgm_segment,sy->location);
break;
case SEC_STACK:
fprintf(o_src,"\tmovs%cl\t-%d(%%ebp), %%eax\n",
varsize_ch(sy),sy->location);
break;
}
}
}
} else {
fprintf(o_src,"#val to eax complex $c_base+%u, %%eax\n",
sy->descriptor);
stack_save=stackframe_cnt;
stackframe_cnt = 0;
gen_loadvar( sy );
fprintf(o_src,"#\tmovl\t$c_base+%u, %%eax\n",
sy->descriptor);
asm_call("tcob_get_index");
stackframe_cnt=stack_save;
Nicholas Clark
> There's a GPL COBOL compiler, TinyCOBOL.
> http://tiny-cobol.sourceforge.net/ If anyone wants to take a shot at
> giving it a PIR back end... (And yes, this would actually be very
I was going to say that I thought that "cruel and unusual punishment"
was unconstitutional in the US. But then I remember that there was a
supreme court judgement that something had to be both cruel and unusual
to count. Sadly COBOL is still too common. Then again, because of this
I agree with Dan that having COBOL would be damn useful.
Yesterday DecisionPlus. (Well, actually Friday week)
Today COBOL
Tomorrow the world.
Nicholas Clark
PS We still don't have INTERCAL, do we?
Leopold Toetsch
> One other thought: I don't have a great understanding of PMCs, but I
> think they're intelligent registers. Why not create PMCs that simulate
> the standard x86 registers?
You don't gain anything, when you use PMCs for native processor
registers. As this compiler already generates machine code, you could
just map %eax, %ebx ... to e.g. I16, I17 ...
leo
David Essex
> There's a GPL COBOL compiler, TinyCOBOL (1).
>
> If anyone wants to take a shot at giving it a
> PIR back end... (And yes, this would actually be
> very useful. Imagine using Parrot as a way to migrate
> legacy COBOL apps to, well, almost anything else.
> This would be a Good Thing for an awful lot of folks)
Actually there are several GPL COBOL compilers.
OpenCOBOL (2) is a compiler which generates C code. It's grammar is
almost fully COBOL 85 and partially COBOL 200x compliant.
There is also 'GCC COBOL' (3), which uses the GCC back end to create a
binary.
1) TinyCOBOL
http://tiny-cobol.sf.net/
2) OpenCOBOL
http://open-cobol.sf.net/
3) GCC COBOL
http://open-cobol.sf.net/gcc.html
Uri Guttman
DE> Dan Sugalski wrote:
>> There's a GPL COBOL compiler, TinyCOBOL (1).
>>
>> If anyone wants to take a shot at giving it a
>> PIR back end... (And yes, this would actually be
>> very useful. Imagine using Parrot as a way to migrate
>> legacy COBOL apps to, well, almost anything else.
>> This would be a Good Thing for an awful lot of folks)
DE> Actually there are several GPL COBOL compilers.
DE> OpenCOBOL (2) is a compiler which generates C code. It's grammar is
DE> almost fully COBOL 85 and partially COBOL 200x compliant.
DE> There is also 'GCC COBOL' (3), which uses the GCC back end to create a
DE> binary.
what about the runtime libraries for those cobols? i worked on PL/I
libraries and they have many similar features to cobol (as pl/i was a
genetic monster of cobol/algol/fortran). stuff such as isam record i/o,
picture variables, decimal math, etc are needed for a full cobol. do
those compiler provide that or are there libs provided for it? some of
the fancier compilers of that generation actually generated inline code
instead of many calls to runtime libs.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Uri Guttman
DE> Uri Guttman wrote:
>> ...
>> what about the runtime libraries for those cobols? i worked on PL/I
>> libraries and they have many similar features to cobol (as pl/i was a
>> genetic monster of cobol/algol/fortran). stuff such as isam record i/o,
>> picture variables, decimal math, etc are needed for a full cobol. do
>> those compiler provide that or are there libs provided for it? some of
>> the fancier compilers of that generation actually generated inline code
>> instead of many calls to runtime libs.
DE> Yes, run-time libraries are included. They are written in C.
DE> Generally, both OC and TC generate inline code for program flow
DE> control. The RTL are used mostly for type conversions, system calls
DE> and such.
then the question is how hard would it be to retarget from c to parrot?
the code generation will be very different (c is relatively easy to
generate especially for rtl calls).
DE> The COBOL standard requires 18 digits for declared and 31 digits for
DE> intermediate variables (33 for COBOL 200x) of precision. On 32 bit
DE> architectures this is generally emulated in software.
ooof.
DE> For ISAM support both TC and OC use Berkeley's DB (now
DE> Sleepyc*t). While functional, ISAM support has not been fully
DE> tested. Nor does it meet the ISAM standard.
we wrote our own b-tree for isam as well as all the rest of the
voluminous rtl for pl1. c-isam would be a commercial possibility (are
they still around?). i thought sleepycat did hash indexes only and
btrees are really what is needed for isam.
DE> Finally, while TC has a primitive transaction processor,
DE> concurrency issues have not been addressed.
hmm, pl1 didn't have transactions IIRC. i forgot (never did learn real
cobol) that cobol did. that would be hard to support without major help
in the isam lib. if you really want to support real cobol in parrot to
handle all that legacy code, this will need to be addressed. but there
is a good commercial market for this (there is so much legacy cobol out
there and it can't be ported to other cpus) so maybe someone can make a
biz out of this.