Skip to content

Commit

Permalink
json_value now has SEQUENCE attribute, in order to facilitate its use…
Browse files Browse the repository at this point in the history 
… as a dll subroutine argument. Some minor refactoring of internal routines to make this work.

removed some commented out code from earlier incarnations.
  • Loading branch information
@jacobwilliams
jacobwilliams committed Jan 7, 2015
1 parent 0002db7 commit 0066f7d
Showing 1 changed file with 307 additions and 336 deletions.

8 comments on commit 0066f7d

@jacobwilliams
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See: https://software.intel.com/en-us/forums/topic/538073

@zbeekman
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you see Steve’s latest comment about the compiler directives? (In response to IanH)

Also, I’m a little annoyed with git/diff/github that the commit diff doesn’t have a better representation of indentation/white space differences. It’s hard to see what actually changed vs what is an indentation change. That’s the reason why I left the indentation alone in 138636d because it can make diffs a bit less comprehensible.

@jacobwilliams
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, just saw that. I guess I can declare some additional kind variables like:

 integer,parameter :: WP = real64   !default real kind (double precision)
 integer,parameter :: IP = int32    !default integer kind
 integer,parameter :: LP = 4        !default logical kind [4 bytes for intel and gnu]
 integer,parameter :: CP = 1        !default character kind [1 byte for intel and gnu]

and use them to define all the variables. Maybe we can come up with some better names (I always use wp for working precision, but I admit I've never defined the logical or character kind, so don't know what to call these).

Yes, agree about the github whitespace issues... FYI: I use SourceTree with the "ignore whitespace" option enabled in the diff window, and it is a lot easier to tell what is going on.

@zbeekman
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it sounds like defining kind variables for at least the reals, integers and complex (if any) and pairing that with the !DEC ATTRIBUTES DEFAULT :: name directive might be advantageous.

I’m less convinced that this is needed for logical and character kinds. I think setting them to the actual values used by Intel and gfortran is dangerous, though. Fortran 2008 extends iso_fortran_env to include a character_kinds and logical_kinds array. For logical variables one could probably just choose the first element of the array. This could have performance implications (i.e., if 1 byte logicals are allowed, then it could mess with memory alignment etc and have an effect on SIMD/vectorization) but I doubt these will be of any practical importance. Perhaps you could test the size the different logical kinds, if more than one exist, but the limits on what is and isn’t allowed in initialization expressions gets confusing quickly. I’m sure the use of merge() and some black magic could ensure 4 byte logicals but I’m not the wizard you’re looking for. For characters, F2003 provides the intrinsic function selected_character_kind() which takes the arguments ’DEFAULT’ ’ASCII’ and ’ISO_10646’. Only the ’DEFAULT’ character kind is guaranteed to exist. One could simply just use the default, or again try to use ASCII or ISO_10646 (utf-8?)

As for the diffs: Ah yes, source tree, what a behemoth, but it admittedly does have some utility.

@jacobwilliams
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So...I don't know if there is a totally satisfactory way to deal with the logical variable. I don't want to use logical_kinds(1) since that is not the most commonly used default for either Intel or gfortran. The default 4-byte logical for both of them is logical_kinds(3). I'm leaning towards doing something like this:

 integer,parameter :: RK = real64  !  [8 bytes for intel and gnu]
 integer,parameter :: IK = int32  !  [4 bytes for intel and gnu]
 integer,parameter :: CK = character_kinds(1)  !  [1 byte for intel and gnu]
 integer,parameter :: LK = logical_kinds(min(3,size(logical_kinds)))  !  [4 bytes for intel and gnu]

@zbeekman
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me 👍

Regarding the character kind, does json say anything about encoding? If so would it be worthwhile to attempt to use ISO... ?

@jacobwilliams
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll look into it. I seem to remember looking into that before and only getting confused.

@zbeekman
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I have a hazy memory that at one point Intel supported it, then didn't, having something to do with F2008 or its implementation. At any rate, you can test the return of selected_character_kind('ISO...') and it will be -1, IIRC, if not supported. It may be worthwhile attempting to use ISO encoding if available, as compilers are upgraded and if/when someone ports this to Cray/PGI/NAG etc.

Please sign in to comment.