Re: Lex surrogates

Ric Holt <holt@turing.toronto.edu>
Mon, 13 Feb 89 17:02:58 EST

          From comp.compilers
Related articles
[4 earlier articles]
Re: Lex surrogates wpl@PRC.Unisys.COM (1989-02-06)
Re: Lex surrogates ken@cs.rochester.edu (Ken Yap) (1989-02-09)
Re: Lex surrogates mike@arizona.edu (1989-02-09)
Re: Lex surrogates tower@bu-cs.BU.EDU (1989-02-10)
Re: Lex surrogates pardo@june.cs.washington.edu (1989-02-11)
Re: Lex surrogates henry@zoo.toronto.edu (Henry Spencer) (1989-02-11)
Re: Lex surrogates holt@turing.toronto.edu (Ric Holt) (1989-02-13)
Re: Lex surrogates henry@zoo.toronto.edu (1989-02-16)
Re: Lex surrogates gmdka!grosch@unido.irb.informatik.uni-dortmund.de (1989-02-17)
| List of all articles for this month |
From: Ric Holt <holt@turing.toronto.edu>
References: <3324@ima.ima.isc.com>
Organization: /usr/local/lib/organization
Date: Mon, 13 Feb 89 17:02:58 EST

In reply to Henry's comments ....


>The stuff lex puts in yytext[] also changes for each terminal, and hence
>also must be saved immediately if you want to use it. I don't understand
>why the lack of copying makes a practical difference.
>
> Henry Spencer at U of Toronto Zoology
> uunet!attcan!utzoo!henry henry@zoo.toronto.edu


In a FAST scanner, every machine instruction counts. I'd like to know how
fast, on an instruction basis, FLEX and LEX are. The scanner for the new
Turing compiler (written in Turing Plus) seems to execute about 129 machine
instructions per token, including hashing identifiers and entering them into
buckets (as well as skipping white space and comments). These are MC680x0
instructions. A token is something like a keyword, an operator, an identifier,
etc. In a scanner like this, copying extra bytes appreciably slows down
things.


Ric Holt
[From Ric Holt <holt@turing.toronto.edu>]
--

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.