Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
language:migrate [2020/08/12 05:55]
rajit [Canonical names] 		language:migrate [2022/05/13 11:23] (current)
rajit [Canonical names]
Line 15: Line 15:
 ==== Channel and data type bodies ==== ==== Channel and data type bodies ====
  
-The old ACT had channel and data type bodies for send/recv/put/get methods, but they were ignored. So if you have old ACT that has those, you can simply delete them. Otherwise you can use the new [[language:types|method syntax]].+The old ACT had channel and data type bodies for send/recv/put/get methods, but they were ignored. So if you have old ACT that has those, you can simply delete them. Otherwise you can use the new [[language:types2|method syntax]].
  
  
Line 21: Line 21:
  
 The old ACT only had single-assignment parameters. So  The old ACT only had single-assignment parameters. So 
-<code>+<code act>
 pint x; pint x;
  
Line 28: Line 28:
 </code> </code>
 would result in an error. This was sometimes used to implement assertions. For example, if a parameter ''x'' was supposed to be twice another parameter ''y'', then would result in an error. This was sometimes used to implement assertions. For example, if a parameter ''x'' was supposed to be twice another parameter ''y'', then
-<code>+<code act>
 x=2*y; x=2*y;
 </code> </code>
Line 34: Line 34:
  
 The new ACT supports [[language:connections|mutable parameter]] variables in restricted contexts. To support the assertion feature, the new ACT supports explicit assertions. We use Hoare's syntax, and so the assertion  specified earlier would be written The new ACT supports [[language:connections|mutable parameter]] variables in restricted contexts. To support the assertion feature, the new ACT supports explicit assertions. We use Hoare's syntax, and so the assertion  specified earlier would be written
-<code>+<code act>
 {x=2*y}; {x=2*y};
 </code> </code>
 If a more meaningful message is required, the following syntax is also supported: If a more meaningful message is required, the following syntax is also supported:
-<code>+<code act>
 {x=2*y : "This assertion failed"}; {x=2*y : "This assertion failed"};
 </code> </code>
Line 46: Line 46:
  
 In the previous version of ACT, one could do the following: In the previous version of ACT, one could do the following:
-<code>+<code act>
 bool x[2][2]; bool x[2][2];
 bool y[2]; bool y[2];
Line 59: Line 59:
 </code> </code>
 Instead, you can get the same effect by saying: Instead, you can get the same effect by saying:
-<code>+<code act>
 x[0][0..1] = y; x[0][0..1] = y;
 </code> </code>
Line 67: Line 67:
  
 When two signals are connected to each other, ACT picks one of them to be the canonical name for the signal and tracks the other names as aliases. In older versions, the canonical name was selected as the //outer most, shortest// name. Here, //outer most// means the name accessible with the fewest dots. So, for example, if you had an ''e1of2'' channel with fields ''t'', ''f'', and ''e'', and a definition like this: When two signals are connected to each other, ACT picks one of them to be the canonical name for the signal and tracks the other names as aliases. In older versions, the canonical name was selected as the //outer most, shortest// name. Here, //outer most// means the name accessible with the fewest dots. So, for example, if you had an ''e1of2'' channel with fields ''t'', ''f'', and ''e'', and a definition like this:
-<code>+<code act>
 defproc test (e1of2 x) defproc test (e1of2 x)
 { {
Line 78: Line 78:
 This could sometimes make port lists for processes hard to understand especially for tools that did not track all the aliases of a name. A much-requested feature was that names in the port list take precedence over internal signal names. In this particular example, that would mean that ''x.t'' would get used as the canonical name rather than ''y''.  This could sometimes make port lists for processes hard to understand especially for tools that did not track all the aliases of a name. A much-requested feature was that names in the port list take precedence over internal signal names. In this particular example, that would mean that ''x.t'' would get used as the canonical name rather than ''y''. 
  
-The new ACT library now implements a different way to select the canonical name for a signal. In a particular process, there are three signal categories: globals, ports, and local signals. These are given priority during canonical name selection: a global has the highest priority, followed by ports, followed by local signal names. Arrays have higher priority than non-arrays (in an attempt to keep array structures unfragmented), and if the global/port/local classification is the same, the outermost, shortest heuristic is used to break ties.+The new ACT library now implements a different way to select the canonical name for a signal. In a particular process, there are three signal categories: globals, ports, and local signals. These are given priority during canonical name selection: a global has the highest priority, followed by ports, followed by local signal names. Arrays have higher priority than non-arrays (in an attempt to keep array structures unfragmented), and if the global/port/local classification is the same, the outermost, shortest heuristic is still used to break ties.
  
  
language/migrate.1597226131.txt.gz · Last modified: 2020/12/02 01:00 (external edit)
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3


  • Show page
  • Old revisions
  • Backlinks
  • Recent Changes
  • Media Manager
  • Sitemap