DOPPL
Data Oriented Parallel Programming Language

Development Diary
Iteration #9

Covered Concepts:
States in Detail, Sta...
Abstract
This paper stands for Doppl language development iteration #9. In this paper, the meaning
of "state" as a Doppl e...
process: {
#calculate some extra data for render
#wait until each task is ready to branch to render
}
render: {
#render on...
Having an infix form grants these operators the ability to be used with instruction bypassing. If
the expression on the le...
limitations. Observation of this claim is beyond these iterations and can be subject to a future research.

4. States With...
2. If an inner block wants to access a member outside of its declaration, it can only do so by
navigating outwards block b...
6. Conclusion
Iteration #9 explains states, a special entity type which can contain executed code as well as their
own dec...
Upcoming SlideShare
Loading in...5
×

Doppl development iteration #9

52

Published on

Doppl is a new programming language that aims providing a natural syntax for implementing parallel algorithms, designing data structures for shared memory applications and automated message passing among multiple tasks. The name is an abbreviation of `data oriented parallel programming language`.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
52
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Doppl development iteration #9"

  1. 1. DOPPL Data Oriented Parallel Programming Language Development Diary Iteration #9 Covered Concepts: States in Detail, State Transition Operators Diego PERINI Department of Computer Engineering Istanbul Technical University, Turkey 2013-09-15 1
  2. 2. Abstract This paper stands for Doppl language development iteration #9. In this paper, the meaning of "state" as a Doppl entity will be explained in detail. State transition operators and common usage scenarios of states will be introduced. Conditional, unconditional and synchronized branching will be demonstrated with examples. 1. Rationale Current status of Doppl lacks proper language constructs to achieve branching in a single task as well as declare synchronization points for a concurrently running task group. The way Doppl ecosystem handles looping, synchronization and branching gave birth the idea of states, a kind of pipeline system to create work breakdown structures. 2. States A state is a special marker in a task body which can be used to jump to another instruction. The word state in Doppl has nothing to do with application context as it can easily be seen that each instruction in a state body is able to change it freely. Doppl tasks which belong to same task group are able to wait each other using these markers. A state is declared by typing a name followed by a colon and curly braces block. init: This field is a language reserved state name and declares the initial state for its task. Any branching for a newly spawned task is decided in this state block. There is no way for a task to bypass this state. Initial state name must end with a colon ':' character like any other state declaration. (Iteration #1) Below is an example pseudo program which loads some data to memory. It then computes some calculations on the data to output some graphics to the screen. #States explained task(10) States { #some members here #Init task, must be declared in every task body init: { #init state used it to initialize tasks #branch to load } flush_and_load: { #load data to memory #branch to process } 2
  3. 3. process: { #calculate some extra data for render #wait until each task is ready to branch to render } render: { #render only once using previously calculated data #branch to process to create an infinite render loop } } Each state is obligated to provide at least one state transition expression or a finish clause at the last line of their block. States that lack such expressions imply a finish operation at the end of their state block. finish clause is a blocking synchronization expression that when each task of the same task group meet at finish, the whole group halts simultaneously. 3. State Transition Operators There are two operators to jump between states. They behave almost the same with the exception of one's implying a task barrier line. Non blocking transition: Operator keyword is '-->' without single quotes. Any task executing a non blocking transition directly jumps to the state specified without waiting other tasks in the task group it belongs. Blocking transition: Operator keyword is '->' without single quotes. Any task executing a blocking transition is obligated to wait other tasks in its task group to continue. In other words, tasks of the same task groups always jump simultaneously when this operator is used. State transition operators come with two forms, prefix and infix. Below is the syntax explanation of these usages. Prefix usage can be achieved by omitting the first parameter. any_valid_line_expression --> state_name #infix non blocking any_valid_line_expression -> state_name #infix blocking --> state_name #prefix non blocking -> state_name #prefix blocking 3
  4. 4. Having an infix form grants these operators the ability to be used with instruction bypassing. If the expression on the left hand side of the transition operator is discarded by a once member short circuit, branching is discarded as well. Instruction bypassing therefore becomes a way to conditionally branch in Doppl as well. Previously demonstrated pseudo program can now be implemented with only a few lines of code. #States explained task(10) States { once shared data output_data = string shared data temp_data = string data input_data = string init: { output = "I am ready!n" ->load #Everyone waits the load } flush_and_load: { input_data = 0 shared_data = "" output_data = Null input_data = input -->process #The one who loads may continue } process: { temp_data = temp_data ++ input_data #Calculation ->render #Everyone waits till completion } render: { output_data = temp_data output = output_data #only printed once -->flush_and_load } } This program highly resembles a double buffered rendering loop in graphic libraries such as OpenGL and DirectX. In fact the parallel nature of Doppl imitates GPU cores to achieve same effect by using task groups. The main design principle behind Doppl aims that such mechanisms should be easy to implement and should take fewer lines of code when compared to other general purpose programming languages. This ability also suggest that Doppl programs can become GPU friendly if they suffice some 4
  5. 5. limitations. Observation of this claim is beyond these iterations and can be subject to a future research. 4. States Within States It is possible to define new state blocks inside of states as long as the proper naming convention is used for branching. In order to branch to a new state within a state, the state name should be prefixed with parent state name followed by a period '.' character. There is no limit for nesting levels. Name collision for states will be explained in the next section. mystate: { #valid mystate.foo: { ->foo ->mystate.bar ->zip ->mystate.zip } #same as mystate.foo #same as bar #valid but discouraged #better than above #valid mystate.bar: { #some calculation } #valid but same as mystate.zip and discouraged zip: { #some calculation } } Since state block beginnings do not imply any state transition, it is possible to put a state block anywhere inside another block. Expressions skip state declarations during runtime as they have no significant meaning in terms of an operation, therefore it is considered good practice to isolate these declarations from other expressions of the same state during formatting. 5. Scope Scope rules in Doppl highly resembles scopes in common programming languages with a few additions to work with state transition properly. Any declared member in a block can always be accessed by inner blocks but the opposite is restricted. This rule does also apply to states. Name collisions are handled by latest overridden rule. Below are the results of these rules for each scenario. 1. Any block can access any member and state that it declared. 5
  6. 6. 2. If an inner block wants to access a member outside of its declaration, it can only do so by navigating outwards block by block until it meets the parent task. If the member found during the navigation, it can be accessed. 3. A state can jump to another state if and only if the jumped state can be accesses by the navigation method given above. 4. Name collisions during member accesses can be prevented by prefixing member names with parent states followed by a period character. If the collided member is a task member, task name followed by a period character can be used as a prefix. #Scope demonstration task Scopes(1) { data mybyte = byte #init is omitted for demonstration purposes mystate: { data mybyte = byte mystate.foo: { mybyte = 0xFF mystate.mybyte = 0xFF Scopes.mybyte = 0xFF otherstate.mybyte = 0xFF } mystate.bar: { ->mystate.foo ->mystate ->otherstate ->otherstate.foo } #means mystate.mybyte, valid #same as above, valid #not the same as above, valid #invalid #valid #valid #valid #invalid } otherstate: { data mybyte = byte otherstate.foo: { #some calculation } } } 6
  7. 7. 6. Conclusion Iteration #9 explains states, a special entity type which can contain executed code as well as their own declarations. Synchronization, branching and loops are implemented via transitions between states which has its own kind of operators. Blocking transitions act like barriers which synchronizes tasks of the same task group at a specific point. Non blocking transitions are used of branching within a single task. 7. Future Concepts Below are the concepts that are likely to be introduced in next iterations. ● ● ● ● ● ● ● ● ● ● ● ● ● ● Target language of Doppl compilation Parameterized branching, states as member type, anonymous states if conditional, trueness Booths (mutex markers) Primitive Collections and basic collection operators Provision operators Predefined task members Tasks as members Task and data traits Custom data types and defining traits Built-in traits for primitive data types Formatted input and output Message passing Exception states 8. License CC BY-SA 3.0 http://creativecommons.org/licenses/by-sa/3.0/ 7

×