A big rewrite of the Domain Maps chapter - improved presentation,
covered more aspects, added examples.

Proposing a new format for the roadmap: bullets, to replace
the repetitious "is described in" and to separate the items visually,
which should improve readability.

This has not been reviewed by the team.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18315 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fix for regression in test/studies/amr/advection introduced by unaligned range bounds.
(Passed all regression tests.)

The fix was effected by replacing select calls to range.high in the amr/lib code
with calls to range.alignedHigh instead.  To do this, it was necessary to add
routines alignHigh and alignLow to the _domain record and implementations for
dsiAlignHigh and dsiAlignLow in DefaultArithmetic.

The way I located to calls that needed to be patched was to add an assertion to
range.high, and then replace calls to domain.high with calls to
domain.alignedHigh.

These are the files that were patched:
M      test/studies/amr/lib/amr/Partitioning.chpl
M      test/studies/amr/lib/level/Level_def.chpl
M      test/studies/amr/lib/misc/MultiDomain_def.chpl
M      test/studies/amr/lib/true_solutions/true_solution_defs.chpl

Details of module changes:
M      modules/internal/ChapelArray.chpl
Added alignedHigh and alignedLow to the _domain record.

M      modules/internal/DefaultArithmetic.chpl
Added dsiAlignedHigh and dsiAlignedLow, as mentioned above.

M      modules/internal/ChapelRange.chpl
Replaced calls to high, low and stride accessors with direct access to the
_high, _low and _stride fields.  I was getting too many hits on the high
accessor from within ChapelRange; this reduced the noise, and also reduces the
size of the generated code.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18316 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Some test cleanup.

I went through all futures to find any that my range work had improved.
There was one (sliceNegativeStride).

This also fixes the print-callstack regressions by filtering out the 
internal line number (in ChapelArray.chpl) in the resulting callstack dump.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18317 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
This is a batch of future tests for range and domain semantics

This is a batch of future tests that exercise issues with ranges and
domains that I think need addressing to get them up to snuff -- some
are long-standing issues that I'm just now getting around to
capturing, others new (or newly understood) as a result of Tom's
recent fixes/changes to the range code.  The .future files for each of
these are fairly extensive in terms of details, so I'll just summarize
the main point of each here (in somewhat of a priority/topological
order):

* rangeEquality: shows that range equality is currently in terms of
  the low/high/stride values, not the integers described by the range
  and argues that it should be the latter

* domainEquality: demonstrates a bug that domain equality is currently
  implemented via a promoted == application to all the domain indices
  which I don't believe is what we want.  It also raises a semantic
  question about how domain equality might be different than range
  equality.

* domainOrder: this could arguably be the least important, but relates
  to the previous test so I'll mention it here.  This is the semantic
  issue we raised a few weeks back (via conversation with John Lewis)
  about whether a domain's iteration order should reflect negative
  stride values or whether the interpretation of domain as "set"
  suggests we should use the lexicographic ordering rather than the
  ordering of the ranges that happened to be used in defining the
  domain.

* rangeNormalize: this is a feature request that there be a routine
  one can call on a range to convert it into some sort of
  "normal"/"normalized" format (such that any two ranges in their
  normalized format would have identical low, high, stride, alignment
  values.

* wantsAlignment: these are some examples of range operators
  (exterior, expand, e.g.) that I think do not generate the right
  answers today due to the lack of an alignment value in the range
  representation.  The proposal here is that ranges should be stored
  using the 4-tuple (low, high, stride, alignment) rather than the
  (low, high, stride) triples that we've been storing up to now (where
  low and high had been stored using normalized values prior to Tom's
  recent change and are now the raw, un-normalized values -- I think
  the tension here is that neither of these formats are sufficient to
  do everything we want to do).

* alignedOp: proposes that if we support an aligned value in a range,
  we also provide an operator that permits the user to modify it (set
  the alignment to some arbitrary value).

* alignedOp2: this variation proposes that if we support an alignment
  operator that the print format for a range would indicate its
  alignment if it isn't trivially described by its stride + bounds.




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18319 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Brought in the GNU C source for the PI digits spigot algorithm
and added timing to it.
Also added a makefile to show how to build and run it.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18320 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Redesign and reorganization of the communication layer

This commit implements the new comm layer interface, but also includes
other significant changes and improvements that were required/nice.

Part 1: Comm layer interface change

There are two significant changes to the comm layer interface.  First,
the get and put routines now have an length parameter, in preparation
for bulk communication (currently we pass in length=1 for all cases).
In addition, all routines that send or receive data (get, put, fork,
broadcast) now have a "type index" parameter that corresponds to the
type of the element (along with the element size).  This integer is
used to index into compiler generated arrays that describe the
format/size of data being sent.  This value is used primarily for
heterogeneous compilation.  As a result, the --heterogeneous compiler
flag will work when compiling with any comm layer (not just PVM); the
generated code is only increased by the size of the type tables.

The changes required are to both the compiler interface (comm macros)
as well as the comm layer routines.  Specifically, in the compiler,
code generation to the macros was changed; in the runtime, the macro
definitions as well as the routines themselves were changed (for all
comm layers).

Additional changes made:

- Remove special cases of codegen (i.e., directly printing a string
  rather than using the symbol).  Specifically, dtObject (object base
  type) and (newly added) dtLocale (locale class).  Made an attempt at
  removing chpl__class_id chpl_cid field in the object class, but
  there were too many assumptions made about the object class during
  compilation.  It's not clear to me that not-special-casing the
  chpl_cid field is the right answer either, because non-codegen
  passes may have to deal with special cases for the object class.

- Other codegen clean up (replace fprintf() with gen(), make gen()
  more flexible with more accepted format characters, etc.)

- Better documentation of the "special" types in the compiler such as
  dIteratorRecord (internal), dtArray (required to be defined by the
  modules), and dtObject.  Added error checking for those that are
  required to be defined by the modules.  Changed dtEnumerated to
  dtAnyEnumerated for consistency.

- Add *all* types to the type index description arrays for
  heterogeneous compilation.  Previously these were being added as
  needed, but that was messy and error-prone (there were at least a
  couple of places where we were not adding a particular type and
  getting lucky).

- Added a flag on PrimitiveType that indicated an internal type.
  These should not be codegen'ed.  This was a way to avoid putting
  internal types into the type tables, but also it seemed good to
  distinguish these from Chapel primitive types.

- Remove #define CHPL_HETEROGENEOUS in the generated code as well as
  the runtime (PVM comm layer).  Added a global var called
  chpl_heterogeneous in the generated code that controls the code
  path.  As a result make/comm/Makefile.pvm and the directory itself
  are removed.

- Added the rest of the Chapel primitive types to the chplType enum
  (in runtime/include/chpltypes.h).  These are not yet handled in the
  PVM comm layer.

- Add macros for non-blocking puts in the runtime


Part 2: Runtime file (and function) naming and documentation

Greg, Brad, and I agreed upon a new file and function naming scheme.
The convention is described in runtime/README.  In this commit, I am
trying it out for the communication routines.  Assuming all goes well,
we should employ this convention throughout the runtime.

In addition, I pulled out the compiler macros into a separate header
file (chpl-comm-compiler-macros.h) and documented the use of the comm
interface routines.

As part of this renaming, we should get rid of all "platform"
subdirectories in runtime/include as possible.  In this commit,
runtime/xt-cle is removed.


REMAINING QUESTIONS/TODOS:

- Should runtime routines be able to use the compiler macros?
  Currently, the only use is in chpl_wide_string_copy() in
  runtime/src/chpltypes.c which calls CHPL_COMM_WIDE_GET_STRING().

- How do we get the type index info (for primitive types) to runtime
  routines.  Currently, the routines in chplmemcheck.c will not work
  for PVM true heterogeneous (that was true before this commit).




git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18321 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Added a future requesting that predefined types not be keywords
(specifically, 'domain' and 'index').

This records a decision made by the Chapel group some time ago
(according to Brad).


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18322 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Forgot this move in r18321.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18323 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removing original C source.
Interested parties should refer to 
http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=gcc&id=4



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18324 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixing a typo pointed out by Mark Potts



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18325 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Small changes:

- Change the default y axis label to be blank
- remove unsed variable gif_file



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18326 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Add explicit y axis label (time) for the performance graphs.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18327 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Two new versions of pidigits for consideration

pidigits-blc.chpl was mostly me doing a review of Tom's version and
making edits as I went because that's the easiest way for me to review
code.  Some changes were an attempt to make it a purer use of Chapel
(e.g., no externs), others were to make it more elegant (by my
tastes).

Specific changes were:

* not using externs for I/O (which will cause a performance hit, but
  feels like it's keeping within the language better)
* attempted to make the looping structure more precise/less
  break-/return-oriented
* removing as many cases of specifying types/casts as often as
  possible (reducing the number from 12 to 5)
* lumped the next_term and extract_digit calls into a single function
  next_digit
* doing so permitted me to get rid of the sentinel value of -1 which
  in turn permitted me to get rid of some of the aforementioned casts
* moving variable declarations closer to their first defs/uses when
  possible
* moving the initialization of the GMP variables into the global code
  section
* adding a config const to specify whether or not to print timing and
  avoid the prediff
* adding parens to the no-arg procedures under the argument that they
  definitely seem like they compute something rather than being
  something that is subject to a space-time tradeoff
* comma-separating the standard modules used

One of the todos I noted in this version was to try and move the loop
generating the digits into an iterator to keep the top-level code as
clean as possible.  In mailing Tom I was thinking this was going to be
a bit tricky/convoluted, but it turned out to be fairly
straightforward.  The result is pidigits-iter.chpl which I think is
pretty nice.

Remaining TODOs: It would be nice to support overloaded assignment on
GMP types to avoid some of the fairly verbose initialization calls.
Related, it would be nice to support initialization functions for
external types; our qthreads work wanted this as well.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18328 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixed vim syntax to have proc/iter instead of def; also included syntax highlighters for GNU source-highlight and another highlight program

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18330 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Makefile targets for other compilers

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18331 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Cleaning up control flow in my pidigits code

Thanks to my sharp-witted colleagues who pointed out that a nested
loop would allow me to get rid of the ugly boolean that I wasn't
liking...



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18333 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fix for last night's gasnet and no-local regressions due to r18321 &
r18323.  Arguments for a couple of the case for the
CHPL_COMM_WIDE_[GET|SET]_FIELD* macros were not updated correctly.



git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18334 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Added readmes, working examples for highlighters

git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18335 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Added a note requesting to avoid wildcards in CLEANFILES.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18336 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Added a bug future for a case where a generic use of 'domain'
is not accepted by the parser.


git-svn-id: http://svn.code.sf.net/p/chapel/code/trunk@18337 3a8e244f-b0f2-452b-bcba-4c88e055c3ca