Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| [4 earlier articles] |
| Parsing using a Graphics Processing Unit (GPU)? christopher.f.clark@compiler-resources.com (Christopher F Clark) (2020-09-02) |
| Re: Parsing using a Graphics Processing Unit (GPU)? elronnd@elronnd.net (Elijah Stone) (2020-09-01) |
| Re: Parsing using a Graphics Processing Unit (GPU)? arnold@skeeve.com (2020-09-02) |
| Re: Parsing using a Graphics Processing Unit (GPU)? 0xe2.0x9a.0x9b@gmail.com (Jan Ziak) (2020-09-02) |
| Re: Parsing using a Graphics Processing Unit (GPU)? costello@mitre.org (Roger L Costello) (2020-09-02) |
| Re: Parsing using a Graphics Processing Unit (GPU)? christopher.f.clark@compiler-resources.com (Christopher F Clark) (2020-09-02) |
| Re: Parsing using a Graphics Processing Unit (GPU)? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2020-09-02) |
| Re: Parsing using a Graphics Processing Unit (GPU)? christopher.f.clark@compiler-resources.com (Christopher F Clark) (2020-09-03) |
| Re: Parsing using a Graphics Processing Unit (GPU)? gah4@u.washington.edu (gah4) (2020-09-09) |
| Re: Parsing using a Graphics Processing Unit (GPU)? monnier@iro.umontreal.ca (Stefan Monnier) (2020-09-22) |
| From: | Hans-Peter Diettrich <DrDiettrich1@netscape.net> |
| Newsgroups: | comp.compilers |
| Date: | Wed, 2 Sep 2020 22:34:18 +0200 |
| Organization: | Compilers Central |
| References: | 20-09-001 20-09-002 20-09-008 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="2917"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | parallel, performance, comment |
| Posted-Date: | 02 Sep 2020 16:43:08 EDT |
Am 02.09.2020 um 11:13 schrieb Jan Ziak:
> On Tuesday, September 1, 2020 at 6:03:27 PM UTC+2, Christian Gollwitzer wrote:
>> The parser reads the input as a stream of
>> tokens; you can't split the C file at some arbitrary point in half and
>> parse both parts independently.
>
> Of course you can split asm/C/C++/Go/Python/Rust/etc file at arbitrary
> points:
Certainly not for C/C++. The preprocessor and included files modify the
original source. That's one of the reasons for the slow C/C++ compilation.
> when the state of the lexical analyzer collapses to a single
> state starting from a random file position with an arbitrary starting
> state.
If you mean the lexer by "lexical analysis", that's only a front end for
the parser. A compiler needs more state and context information like
symbol tables, which can not be built from arbitrary parts of a source file.
DoDi
[One can certainly pipeline the C preprocessor and later phases but I'm
guessing that's not what you're talking about here. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.