Am 01.02.2012 um 13:36 schrieb Erik Christiansen:
> On 01.02.12 11:48, Michael Haberler wrote: >> Am 01.02.2012 um 09:23 schrieb Erik Christiansen: >>> The grammar specifies expression and control flow constructs, but seems >>> 100% devoid of any explicit gcode grammar. I've scrolled up and down >>> twice now, but still can't see any rapids, moves, feedrates, or >>> toolchanges. Nuffin! >> >> Yes, and that is a feature. > > At some point, LinuxCNC needs to interpret the gcode. The "parser" > you've put up does not do that. Probably folks use the term 'parser' to mean different things, which might be part of the confusion. I use in the Dragonbook/Compilers 101 sense - a program which recognizes certain syntactic constructs and nothing else. For me the term 'parser' does NOT include static semantic checks, or executable semantics. The term 'interpreter' for me denotes executable semantics, which is different from 'parser', which is a context-free affair so to speak. > Does it have any purpose, if it does not > do that? A better definition of the language than we currently have it, executable or in the manual? For instance, we dont have anything like a railroad diagram or a current BNF. And it would be great to have that in particular for beginners. Also an executable version at least as point of reference, and as a vehicle for other software. Some examples: 1. Expression syntax my parser actually found an error, or rather my misunderstanding of the current language, in one of the files in emc2-dev/nc_files see line 30 of http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=nc_files/m6demo.ngc;h=85a3c0f7f031a7735e1660403f22beee90302b4e;hb=50d82f006b489a0e2795e60bd617759c902fdafd#l30 : O<m6demo_spindle_off> if [#<tool_change_with_spindle_on>] EQ 0 now if you read http://www.linuxcnc.org/docs/devel/html/gcode/o-code.html, the 'if' examples have bracketed expressions. So I though, gee, must be in the language. Well guess what, it isnt - the current interpreter (at least at that point) accepts the above line just fine, and I think it skips from the closing bracket to end-of-line - one would have to read the source code to determine acceptable language. Incidentally the interpretation of 'if [#<tool_change_with_spindle_on>]' and 'if [[#<tool_change_with_spindle_on>] EQ 0]' happen to be the same, but one can do better. 2. Is a (comment) whitespace? Whitespace is squashed, we hear. Comments are removed, so I assumed they are gone at the language execution level, and are de-facto whitespace. Really? let's see: $ rs274 -g ... READ => s100m3 17 N..... SET_SPINDLE_SPEED(100.0000) 18 N..... START_SPINDLE_CLOCKWISE() READ => s 100 m 3 19 N..... SET_SPINDLE_SPEED(100.0000) 20 N..... START_SPINDLE_CLOCKWISE() READ => s 100 (on) m 3 21 N..... COMMENT("on") 22 N..... SET_SPINDLE_SPEED(100.0000) 23 N..... START_SPINDLE_CLOCKWISE() READ => s(hundred) m 3 bad number format (conversion failed) parsing '' s(hundred) m 3 That kind of 'language spec' can stand improvement.. so my parser doubles as a reverse-engineering tool;) 3. backplot for CAM programs HeeksCad sports some minimalistic understanding of the Gcode it generates, for backplotting the generated tool path. Guess what it uses: a regexp-based 'parser'. Sure. > A user need which has been expressed in this thread is for a documented > gcode grammar. We'd like to know what is legal gcode, and what is not. > If no grammar policing exists in the so-called parser, then either > almost any input is accepted, or the real parser is elsewhere. You'd be suprised on what incredible junk gcc accepts as 'legit grammar' once you amputate the backend ;) Currently I dont see a formal way to describe the interdependencies of several words on a block. You can do the optional parameter words in the language but you cant recogize the conflicts and multiple uses within a block that way. It would be nice to have. >> b) the language we have *is already runtime extensible* at the word level > > According to the documentation here: > http://www.linuxcnc.org/docview/devel/html/remap/structure.html#_introduction_extending_the_rs274ngc_interpreter_by_remapping_codes > > you're almost wholly correct in saying: > >> and your idea kills this property by downgrading it to a compile-time affair. > > because having a documented grammar in the parser would only allow > run-time _extending_the_rs274ngc_interpreter_by_remapping_codes. It > would only permit remapping of standard gcodes by changing the grammar. > But the need to remap gcodes half way through a swarf-making job, > without allowing a compile, is probably a rare requirement. Good to see somebody is reading this after all.. But 'remapping' is a bit of a misnomer: while a few codes can be 'remapped' (aka changed), practically unlimited new M- and G-codes can be introduced, with new optional and required word parameters. All this happens at the block/word level of the current parser. I never thought of runtime extensions - this is a configuration time thing. > my interest lies at the > other end of LinuxCNC and the use-case spectrum: Re-using the standard > gcode grammar, but cleaning up its appearance. we violently agree > At this stage, I only have a few questions: > > Do we implement a "default grammar", which we could document in BNF? > > Is it sufficiently static to warrant the effort of documenting it? I'd like to see an unambiguous grammar reference. So that parser is a start in that direction. Eventually the real thing should actually execute that grammar, there's no point in having an executable doing one thing and the LinuxCNC interpreter something slightly different. That's not urgent though. In any cleanup/extension effort an executable grammar will help, in particular wrt avoiding backwards compatibility issues. -m ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
