Do a grep of your source files to locate which file eBEGINi is located in. It
does not appear in any of the
files included in you e-mail.
----- Original Message -----
From: Mark Hounschell <address@hidden>
To: address@hidden; address@hidden
Cc:
Sent: Friday, November 1, 2013 6:36 AM
Subject: [Flex-help] lex/yacc/gcc help
I am trying to port some code from an old unix box to Linux. It is a
microcode compiler for an old CPU board. This code uses lex/yacc/cc.
Obviously all works on this old unix box. I am completely lex/yacc
ignorant but am not gcc ignorant. I am hoping someone can give me some
advise as to what I need to do.
I've subscribed and sent this email to both the flex-help and the
help-bison mailing lists because I really have no idea what the problem
really is. I hope that is appropiate.
The Linux distribution OS is OpenSuSE-12.3 and the software versions in
use are:
gcc-4.7-7.1.1.i586
glibc-2.17-4.7.1.i586
flex-2.5.37-2.1.1.i586
bison-2.6.5-2.1.1.i586
The actual error I get from gcc when compiling this stuff on Linux is:
# make
./translate5 cpu.def
cat yacc1.yinit yacctoks yacc2.yinit yaccrules yacc3.yinit > yacc.in
yacc -d yacc.in
cat lex1.linit lextext lexfield lex2.linit > lex.in
flex -l lex.in
gcc -ansi -w y.tab.c -o cpu.asm -lgcc
yacc.in: In function ÎyyparseÌ:
yacc.in:2322:3: error: unknown type name ÎBEGINÌ
make: *** [cpu.asm] Error 1
This is the output from the legacy "unix" machine:
# make
translate5 cpu.def
cat yacc1.yinit yacctoks yacc2.yinit yaccrules yacc3.yinit > yacc.in
/usr/bin/yacc -d yacc.in
cat lex1.linit lextext lexfield lex2.linit > lex.in
/usr/bin/lex lex.in
2277/3600 nodes(%e), 10911/17500 positions(%p), 1561/1900 (%n), 89797
transitions
, 136/170 packed char classes(%k), 3614/5000 packed transitions(%a),
2433/4000 output slots(%o)
/bin/cc -z -B/lib/ -t0 y.tab.c -ly -ll -v -w -o cpu.asm
/lib/cpp y.tab.c /tmp/ctm030464 -DON_SEL -Dselport -DGOULD_PN -DCOFF
/lib/ccom /tmp/ctm030464 /tmp/ctm030463 -Xll -w
/bin/as -o y.tab.o /tmp/ctm030463
/bin/ld -X /lib/crt0.o -e start -o cpu.asm -z y.tab.o -ly -ll -lc
Now from my limited mis/understanding the ÎBEGINÌ in the compile failure
above seems to be a "lex thing"? Yet it seems to appear in a yacc file?
If I look at what ends up being in the y.tab.c file on both machines I see:
Legacy unix box:
case 207:
# line 2305 "yacc.in"
{ if (yychar != -1) {
yyclearin;
while (yyleng > 0) {
unput(yytext[--yyleng]); }}
BEGIN ctxn;} break;
}
goto yystack; /* stack new state and value */
}
The Linux box:
case 208:
/* Line 1778 of yacc.c */
#line 2318 "yacc.in"
{ if (yychar != -1) {
yyclearin;
while (yyleng > 0) {
unput(yytext[--yyleng]); }}
BEGIN ctxn;}
break;
Both the above come from the yacc3.yinit file.
cnum : /*empty*/
{ if (yychar != -1) {
yyclearin;
while (yyleng > 0) {
unput(yytext[--yyleng]); }}
BEGIN ctxn;}
;
The only references to "ctxn" I find are from a lex1.linit and
lex2.linit files.
lex1.linit:
%C
%e 3600
%p 17500
%a 5000
%o 4000
%n 1900
%k 170
int statnum=0;
int externum=0;
int passc=0;
int linec=1;
int errc=0;
int eolflag = 0;
int codeflag = 0;
int lque = 0;
int plinec = 0;
int spacec = 1;
int pagesize = 55;
int skippage = 0;
int skipline = 0;
int pagecnt = 1;
int type1, type2, type3, type4, type5, type6, type7, type8;
int type9, typeA, typeB, typeC, typeD, typeE, typeF;
%S ex co pb lc rz bd al eq va code
%S rz2 bd2 sp hd hd2 hd3 hd4 dir ctxn
.
.
.
.
lex2.linit:
<code,ctxn>("#"[0-9a-fA-F]+|[0-9]+) {
if (yytext[0] == '#') {
yylval.nvaltype.nval=htoi(yytext);
if (yyleng > 9)
fprintf(stderr, "Literal value '%s' out of
range at line %d\n",
yytext, linec);
} else
yylval.nvaltype.nval=atoi(yytext);
yylval.nvaltype.ntype=2;
BEGIN code;
return(NUM);
}
<code>[ \t] {}
^[ \t]+ {BEGIN code;}
<ctxn,code>[A-Za-z][\$\.A-Za-z0-9]* {BEGIN code; return(p_symbol(yytext));}
<code>\n {p_eol(); ++linec;}
[ ,\t] {}
\n {p_eol(); ++linec;BEGIN 0;}
. {return(YYERRCODE);}
%%
#include "process.c"
Again, I am completely ignorant of lex and yac. Very strange and cryptic
looking code. I would greatly appreciate any pointers from anyone.
Thanks in advance
Regards
Mark
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Flex-help mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/flex-help
-------------------------------------------------------------
This email was processed through Xeams to filter junk messages.
If you feel this message has been tagged incorrectly, you can
change its category by clicking the link below.
Click here
http://12.186.155.30:5272/FrontController?operation=mbeu&f=00001_-930_20131101_419812.eml&chkBayesian=1&pr=1&mt=1&ma=s
to mark email as junk.
-------------------------------------------------------------
.