 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trf de> wrote:
> This is only true for ISO C, not ISO C++. In C++ all C macros are
required
> to be functions; and when using "cname" instead of "name.h" headers they
are
> even placed in the std namespace. POV-Ray 3.5 is a C++ program.
Strictly speaking, that's so, but POV-Ray still uses <stdio.h>, and I see no
reasons not to just change fgetc() to getc() -- if that is indeed a
bottleneck, as you said.
> Apart from that the lastest revision of C, ISO C 99 explicitly notes that
> getc may be either a function or a macro. In reality, it is even so that
> some libraries implement it in terms of exactly the same code fgetc
uses...
IIRC, it (ISO C) did so for ages. And yet in reality all the compilers I'm
aware of always had a macro version of getc(). My current versions of VC and
GCC certainly do. ICC (Intel's Proton) that I used to run just used MS's
include files, so it also did. So if fgetc() is a bottleneck (as you said),
and you just change fgetc() to getc(), we would have free speed improvement.
It won't help my own version though, since I use multi-threading, and
getc/putc macros are, obviously, unusable in that mode. But as to the
official version... Or are use using MT library as well?
BTW, there are currently only 4 calls of fgetc() in POV-Ray sources (inline
function in file_pov.h, plus method of pov_istream_class in file_pov.cpp).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e1d5e30@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:
> IIRC, it (ISO C) did so for ages. And yet in reality all the compilers I'm
> aware of always had a macro version of getc(). My current versions of VC and
In C mode they indeed have. But having the macro usually causes problems in
C++ compilers, so watch carefully if the macro isn't an inline function when
compiling as C++ code.
> GCC certainly do. ICC (Intel's Proton) that I used to run just used MS's
> include files, so it also did. So if fgetc() is a bottleneck (as you said),
> and you just change fgetc() to getc(), we would have free speed improvement.
The Intel compiler usually uses the header files of its host, doesn't it?
> It won't help my own version though, since I use multi-threading, and
> getc/putc macros are, obviously, unusable in that mode. But as to the
> official version... Or are use using MT library as well?
I don't know if the current Windows version needs to or not, the Mac version
certainly does need multithreaded library versions.
> BTW, there are currently only 4 calls of fgetc() in POV-Ray sources (inline
> function in file_pov.h, plus method of pov_istream_class in file_pov.cpp).
Yes.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e1d1b30@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:
> I disagree. My point is that (i) POV-Ray's SDL structure is very linear, and
> (ii) the number of reserved words it currently has suggests that performance
> gain from using an FSM-based *scanner* would be even greater than the
> languages with far fewer nmbers of keywords enjoy (e.g. C/C++).
As we agreed on the scanner part already, here is another good point against
Yacc. Obviously its grammars are hard to maintain and there is hardly a
worthwhile speed gain, otherwise the December 27th announcement on
<http://gcc.gnu.org/> would not make sense!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote:
>
> As we agreed on the scanner part already, here is another good point
against
> Yacc. Obviously its grammars are hard to maintain and there is hardly a
> worthwhile speed gain, otherwise the December 27th announcement on
> <http://gcc.gnu.org/> would not make sense!
Well, interesting announcement, indeed.
The grammars are as hard to maintain as formal language definitions are. I
mean, the accurate description of language *semantics*, not just syntax.
This is a very complicated matter... I, personally, started my compiler
construction education with "The Disign and Construction of Compilers"
(Hunter, 1981), which was published just 4 years before the "Compilers:
Principles, Techniques, and Tools" (Aho, Sethi, Ullman; 1985). Just 4-year
span, and yet there were a fundamental difference: the first book's author
had no idea as to how to describe language semantics (vs syntax), at all.
There were some vague and virtually useless proposition of meta-grammars,
and that's all. While the second book introduced annotated grammars
(grammars with attributes). Here, I refer to the "Red Dragon" edition; I
have no idea whether earlier editions had that as well. What I am trying to
say is that, to the best of my knowledge, attributed grammars are the only
way (discovered to date) to accurately represent language *semantics*.
The annotated (attributed) grammars are essentially what Yacc/Bison and
similar systems implement. The "attributes" (from the compiler construction
theory) are those "rules" enclosed in curly braces that you put into the
Yacc rules. So, as to maintaining language *definition*, Yacc rules are
unbeatable -- respective implementations are as close to theory as possible.
Consequently, there is a possibility to automatically generate highly
efficient language parsers, far more efficient than a casual compiler writer
may produce. Or course, that may not be the case with those Los Alamos guys.
In this respects, to maintain POV-Ray grammar as a Yacc one still seems to
be highly desirable -- IMHO.
One thing that used to always bother me a lot was the extreme difficulty of
maintaining the "context" in bottom-up analysis, i.e. in Yacc/Bison
grammars... But as soon as I got accustomed to the use of fake non-terminals
to track context, life became significantly easier. To me, that is still the
only noticable weakness of real-life LR1/LALR1 grammars used in bottom-up
analysis. I bet those guys used *much* more hacks to make a working C++
LL1-based parser... Once you start to write recursive-descend parser for a
real-world application, you quickly notice that you are forced to patch it
more and more, pass more and more information to and from those recursive
calls (I suspect that that is what "hand-crafted" stands for in that
announcement :-) -- in strict accordance with the theory, that states that
LL1 grammars are suitable for a much smaller set of languages than LALR1
(let alone LR1). Fortunately, as I noted earlier, this does not have such a
strong impact on POV-Ray -- due to its more or less linear nature. BTW, how
do you think: to what extent the linear POV-Ray SDL structure is due to its
LL1-constrained parser? :-)
Well, back to practice... I sincerely think that a good profiling of
POV-Ray's *scanner* has to be done; I promise to do that (again) myself, one
day, as I have time. To date, speaking of parse time, the only thing that
*really* got in my way was parsing of really big meshes -- which obviously
cannot be due to parser's design, but just because of its implementation.
Maybe you're right with your getc()/ungetc() observation. If that is indeed
so, the radical solution might as well include the implementation of 3DS
mesh readers (why not? we do use binary images, and there seems to be no
fundamental differences). Other (non-mesh) things just parse much longer
that I would have liked; in acceptable time, but much longer than they ought
to. *This* might as well be due to scanner design; so some profiling is due,
definitely.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
/************************************************************************/
/* Code section */
/************************************************************************/
%{
/* Syntax highlite a POV-Ray 3.5 script using FLEX. Output is HTML.
* by Mike Lundy - May 10, 2003
*
* To complie:
* flex pov.yy
* gcc lex.yy.c -lfl -opov2html
*
* Usage: pov2html <filename.pov >filename.html
* or: pov2html filename.pov >filename.html
* or: pov2html filename.pov filename.html
*/
#define PAGE_COLOR "#FDF5E6"
#define TEXT_COLOR "#000000"
#define KEYWORD_COLOR "#0000BF"
#define DIRECTIVE_COLOR "#0000FF"
#define COMMENT_COLOR "#007F00"
#define STRING_COLOR "#BF0000"
#define INTEGER_COLOR "#800080"
#define FLOAT_COLOR "#800080"
#define OPERATOR_COLOR "#FF0000"
#define DELIMITER_COLOR "#008080"
#define FONT_TAG(tExT, cOlOr) fprintf(yyout, "<FONT COLOR=\"%s\">%s</FONT>",
(cOlOr), (tExT));
#define ECHO fprintf(yyout, "%s", yytext);
#define AUTHOR "mwl### [at] netscapenet"
/* tidy HTML source on '//' type comments */
char *kill_EOL (char* line)
{
char *p1 = line;
int len = 0;
while(*p1++) len++;
if( (line[--len]) == '\n') { line[len] = 0; }
return line;
}
%}
/************************************************************************/
/* Definition section */
/************************************************************************/
%option noyywrap
DIGIT [0-9]
INTEGER {DIGIT}+
FLOAT ({DIGIT}+"."{DIGIT}*)|("."{DIGIT}+)|({DIGIT}+".")
STRING \"[^"]*[\"]*\"
OPERATOR [+*/|!:?=]|"-"
DELIMITER [;{}]
DIRECTIVE
break|case|debug|declare|default|else|end|error|fclose|fopen|if|ifdef|ifndef|include|local|macro|range|read|render|statistics|switch|undef|version|warning|while|write
%x comment1
%x comment2
/************************************************************************/
/* Rules section */
/************************************************************************/
%%
"/*" { BEGIN(comment1); fprintf(yyout, "<FONT COLOR=\"%s\">%s",
COMMENT_COLOR, yytext); }
<comment1>[^*\n]* ECHO;
<comment1>[^*\n]*\n ECHO;
<comment1>"*"+[^*/\n]* ECHO;
<comment1>"*"+[^*/\n]*\n ECHO;
<comment1>"*"+"/" { fprintf(yyout, "%s%s", yytext, "</FONT>"); BEGIN(INITIAL);
}
"//" { BEGIN(comment2); fprintf(yyout, "<FONT COLOR=\"%s\">%s",
COMMENT_COLOR, yytext);; }
<comment2>\n+ { fprintf(yyout, "%s%s", kill_EOL(yytext), "</FONT>\n");
BEGIN(INITIAL); }
<comment1,comment2>< { fprintf(yyout, "%s", "<" ); }
<comment1,comment2>> { fprintf(yyout, "%s", ">" ); }
<comment1,comment2>& { fprintf(yyout, "%s", "&" ); }
<comment1,comment2>\" { fprintf(yyout, "%s", """); }
<INITIAL>< { FONT_TAG("<", OPERATOR_COLOR); }
<INITIAL>> { FONT_TAG(">", OPERATOR_COLOR); }
<INITIAL>& { FONT_TAG("&", OPERATOR_COLOR); }
<INITIAL>\" { FONT_TAG(""", STRING_COLOR); }
{STRING} { FONT_TAG(yytext, STRING_COLOR); }
{OPERATOR} { FONT_TAG(yytext, OPERATOR_COLOR); }
{INTEGER} { FONT_TAG(yytext, INTEGER_COLOR); }
{FLOAT} { FONT_TAG(yytext, FLOAT_COLOR); }
{DELIMITER} { FONT_TAG(yytext, DELIMITER_COLOR); }
#+[ \t]*{DIRECTIVE}+ { FONT_TAG(yytext, DIRECTIVE_COLOR); }
aa_level |
aa_threshold |
abs |
absorption |
accuracy |
acos |
acosh |
adaptive |
adc_bailout |
agate |
agate_turb |
all |
all_intersections |
alpha |
altitude |
always_sample |
ambient |
ambient_light |
angle |
aperture |
append |
arc_angle |
area_light |
array |
asc |
ascii |
asin |
asinh |
assumed_gamma |
atan |
atan2 |
atanh |
autostop |
average |
b_spline |
background |
bezier_spline |
bicubic_patch |
black_hole |
blob |
blue |
blur_samples |
bounded_by |
box |
boxed |
bozo |
break |
brick |
brick_size |
brightness |
brilliance |
bump_map |
bump_size |
bumps |
camera |
case |
caustics |
ceil |
cells |
charset |
checker |
chr |
circular |
clipped_by |
clock |
clock_delta |
clock_on |
collect |
color |
color_map |
colour |
colour_map |
component |
composite |
concat |
cone |
confidence |
conic_sweep |
conserve_energy |
contained_by |
control0 |
control1 |
coords |
cos |
cosh |
count |
crackle |
crand |
cube |
cubic |
cubic_spline |
cubic_wave |
cutaway_textures |
cylinder |
cylindrical |
debug |
declare |
default |
defined |
degrees |
density |
density_file |
density_map |
dents |
df3 |
difference |
diffuse |
dimension_size |
dimensions |
direction |
disc |
dispersion |
dispersion_samples |
dist_exp |
distance |
div |
double_illuminate |
eccentricity |
else |
emission |
end |
error |
error_bound |
evaluate |
exp |
expand_thresholds |
exponent |
exterior |
extinction |
face_indices |
facets |
fade_color |
fade_colour |
fade_distance |
fade_power |
falloff |
falloff_angle |
false |
fclose |
file_exists |
filter |
final_clock |
final_frame |
finish |
fisheye |
flatness |
flip |
floor |
focal_point |
fog |
fog_alt |
fog_offset |
fog_type |
fopen |
form |
frame_number |
frequency |
fresnel |
function |
gather |
gif |
global_lights |
global_settings |
gradient |
granite |
gray |
gray_threshold |
green |
height_field |
hexagon |
hf_gray_16 |
hierarchy |
hypercomplex |
hollow |
if |
ifdef |
iff |
ifndef |
image_height |
image_map |
image_pattern |
image_width |
include |
initial_clock |
initial_frame |
inside |
inside_vector |
int |
interior |
interior_texture |
internal |
interpolate |
intersection |
intervals |
inverse |
ior |
irid |
irid_wavelength |
isosurface |
jitter |
jpeg |
julia |
julia_fractal |
lambda |
lathe |
leopard |
light_group |
light_source |
linear_spline |
linear_sweep |
ln |
load_file |
local |
location |
log |
look_at |
looks_like |
low_error_factor |
macro |
magnet |
major_radius |
mandel |
map_type |
marble |
material |
material_map |
matrix |
max |
max_extent |
max_gradient |
max_intersections |
max_iteration |
max_sample |
max_trace |
max_trace_level |
media |
media_attenuation |
media_interaction |
merge |
mesh |
mesh2 |
metallic |
method |
metric |
min |
min_extent |
minimum_reuse |
mod |
mortar |
natural_spline |
nearest_count |
no |
no_bump_scale |
no_image |
no_reflection |
no_shadow |
noise_generator |
normal |
normal_indices |
normal_map |
normal_vectors |
number_of_waves |
object |
octaves |
off |
offset |
omega |
omnimax |
on |
once |
onion |
open |
orient |
orientation |
orthographic |
panoramic |
parallel |
parametric |
pass_through |
pattern |
perspective |
pgm |
phase |
phong |
phong_size |
photons |
pi |
pigment |
pigment_map |
pigment_pattern |
planar |
plane |
png |
point_at |
poly |
poly_wave |
polygon |
pot |
pow |
ppm |
precision |
precompute |
pretrace_end |
pretrace_start |
prism |
prod |
projected_through |
pwr |
quadratic_spline |
quadric |
quartic |
quaternion |
quick_color |
quick_colour |
quilted |
radial |
radians |
radiosity |
radius |
rainbow |
ramp_wave |
rand |
range |
ratio |
read |
reciprocal |
recursion_limit |
red |
reflection |
reflection_exponent |
refraction |
render |
repeat |
rgb |
rgbf |
rgbft |
rgbt |
right |
ripples |
rotate |
roughness |
samples |
save_file |
scale |
scallop_wave |
scattering |
seed |
select |
shadowless |
sin |
sine_wave |
sinh |
size |
sky |
sky_sphere |
slice |
slope |
slope_map |
smooth |
smooth_triangle |
solid |
sor |
spacing |
specular |
sphere |
sphere_sweep |
spherical |
spiral1 |
spiral2 |
spline |
split_union |
spotlight |
spotted |
sqr |
sqrt |
statistics |
str |
strcmp |
strength |
strlen |
strlwr |
strupr |
sturm |
substr |
sum |
superellipsoid |
switch |
sys |
t |
tan |
tanh |
target |
text |
texture |
texture_list |
texture_map |
tga |
thickness |
threshold |
tiff |
tightness |
tile2 |
tiles |
tolerance |
toroidal |
torus |
trace |
transform |
translate |
transmit |
triangle |
triangle_wave |
true |
ttf |
turb_depth |
turbulence |
type |
u |
u_steps |
ultra_wide_angle |
undef |
union |
up |
use_alpha |
use_color |
use_colour |
use_index |
utf8 |
uv_indices |
uv_mapping |
uv_vectors |
v |
v_steps |
val |
variance |
vaxis_rotate |
vcross |
vdot |
version |
vertex_vectors |
vlength |
vnormalize |
vrotate |
vstr |
vturbulence |
warning |
warp |
water_level |
waves |
while |
width |
wood |
wrinkles |
write |
x |
y |
yes |
z { FONT_TAG(yytext, KEYWORD_COLOR); }
[a-zA-Z0-9_#]+ |
<*>.|\n ECHO;
<<EOF>> yyterminate();
%%
/************************************************************************/
/* User code section */
/************************************************************************/
#include <time.h>
/* return current system date & time as char ptr */
char* get_time(void)
{
static char *the_time_str;
time_t the_time;
time(&the_time);
the_time_str = ctime(&the_time);
return(the_time_str);
}
int main(int argc, char **argv)
{
if (!yyin) yyin = stdin;
if (!yyout) yyout = stdout;
if(argc >= 2) {
if( (yyin = fopen (argv[1], "r")) == NULL) {
perror(argv[1]);
return(1);
}
if(argc == 3) {
if( (yyout = fopen (argv[2], "w")) == NULL) {
perror(argv[2]);
return(2);
}
}
}
fprintf(yyout, "<HTML>\n"
"<HEAD>\n"
" <META NAME=\"GENERATOR\" CONTENT=\"%s by %s %s\">\n"
" <TITLE>POV-Ray SDL: %s</TITLE>\n"
"</HEAD>\n"
"<BODY BGCOLOR=\"%s\" TEXT=\"%s\">\n\n"
"<PRE>\n",
argv[0], AUTHOR, __DATE__, get_time(), PAGE_COLOR, TEXT_COLOR );
yylex();
fprintf(yyout, "</PRE>\n"
"<BR>\n"
"</BODY>\n"
"</HTML>\n" );
return(0);
}
Andrew Wilcox wrote:
> Would anyone else find this useful? I started writing it, and I'm past the
> hardest part, and am left with just the tedious task of finding all the
> keywords defined in POV, and implementing the symantic control of which
> keywords are allowed in which objects.
>
> For the most part what I need works, but can anyone give me a good reason to
> go ahead and complete this 100%?
>
> Andrew Wilcox
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 13 May 2003 15:34:41 -0700, Mike Lundy <mwl### [at] netscapenet> wrote:
> /* Syntax highlite a POV-Ray 3.5 script using FLEX. Output is HTML.
> * by Mike Lundy - May 10, 2003
Your post does not asnwered to "implementing the symantic control of which
keywords are allowed in which objects" as it was asked in original post. Any
reason to such strange wasting of news server space ? Any comment why you second
time posted (still in wrong group IMO) the same code instead of referencing
previous ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
There's many replies and one cannot review them all completely... In any event, it's
trivial... and I'm sure we'll get along fine in another thread :-)
Cheers,
Mike
>
>
> Your post does not asnwered to "implementing the symantic control of which
> keywords are allowed in which objects" as it was asked in original post. Any
> reason to such strange wasting of news server space ? Any comment why you second
> time posted (still in wrong group IMO) the same code instead of referencing
> previous ?
>
> ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3EC### [at] netscapenet>,
Mike Lundy <mwl### [at] netscapenet> wrote:
> There's many replies and one cannot review them all completely... In any
> event, it's trivial... and I'm sure we'll get along fine in another thread
> :-)
It's trivial to follow the posting rules. Posts with attachments of any
kind should go in a binaries group, a pure code post should not go in a
discussion group (as mentioned, the utilities groups would have been
more appropriate for this), and there just isn't any reason to make
multiple copies of the same post in the same group. On top of this, your
post doesn't really fit the subject of the thread and you gave
practically no explanation. Please review the posting guidelines in the
povray.announce.frequently-asked-questions group, particularly these:
Welcome To The POV-Ray News Groups
Where can I post my binary or text file?
Cross-Posting Guidelines for news.povray.org
(Actually references multiposting, posting the same message in multiple
groups...nobody anticipated somebody doing it within one group.)
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
