1[ If you are working on FIRE, please update this document accordingly. 2 The `I' in the text is mvo@zagadka.ping.de (Marius Vollmer). ] 3 4 5Differences between FIRE and AIRE 6********************************* 7 8The node type definition in fire-chunk.t are an attempt to get as 9close to AIRE as reasonable, but there are both large and small 10differences that are mostly motivated by my laziness. But many are 11also due to my unhappines with certain AIRE features. 12 13Being fully AIRE compliant is a worthy goal. But right now, I think 14it does not pay off to put much energy into this as there are more 15useful goals. 16 17Below is a (incomplete) account of the differences between FIRE and 18AIRE, with biased comments. 19 20 21Framework 22--------- 23 24With the term `framework', I'm referring to the general constructs 25with which FIRE and AIRE try to support their general goals. This 26includes things like the operations that are supported for every node 27type, memory management, the precise way how new types are defined, 28extensibility, modularity and more. 29 30The framework of FIRE is more advanced than the one of AIRE and I see 31no point in going with AIRE in this regard. There has been much 32discussion about this topic on the FreeHDL list, and improvements for 33the framework were the original motivation to start with FIRE. The 34advantages of FIRE include: 35 36 - Painless high level definitions 37 - Definitions are trivially and confidently machine-readable 38 - Run-time type information via the "is-a" predicate. 39 - Flexible run-time extensibility 40 - Extensibility includes new node types, new visitor functions and 41 new node attributes without recompiling. 42 - Semi-automatic memory management with a simple garbage collector 43 - Inspection facilities that can be used to implement persistence 44 45Please see the libfire sources for ultimate technical details. 46 47 48General Node Stuff 49------------------ 50 51The nodes of a abstract syntax `tree' form a graph. It is useful to 52find a definition what a node can be. It pays to find a simple but 53general definition because it makes graph algorithms easier to specify 54and implement. For example, memory management and persitent stores 55are much easier to implement when the nodes have been kept 56conceptually simple. 57 58FIRE views the syntax graph as a passive, mostly un-mutable data 59structure. It consists of nodes that contain typed pointers to other 60nodes, and additional payload. This simplistic definition is mapped 61to a similarily simplistic C++ implementation. Each node type is 62mapped to a C++ struct with the pointers and the payload implemented 63as public data members. 64 65In addition to the type id, there is also a predicate that can test 66whether a given node is derived from a given type. 67 68AIRE uses C++ syntax to describe the node type definitions. It does 69not seem to have restrictions on what features of C++ one might use in 70such a node type definition. The AIRE spec randomly uses both public 71data members and accessor functions. 72 73It is possible to add the accessor functions to FIRE to achieve AIRE 74source compatability. But the underlying simple view of a node as a 75passive data structure should remain. In fact, using *only* accessor 76functions would be an improvement for FIRE, but they should not 77destroy the fundamental `passiveness' of the graphs, and there should 78not be a random mixture between data members and accessor functions. 79 80AIRE often uses the effectively untyped IIR node type. This makes the 81specification less precise and less transparent. FIRE tries to avoid 82the use of IIR and prefers more specialized types instead. For 83example, a IIR_SignalAssignmentStatement in AIRE denotes the target by 84an IIR, while FIRE uses IIR_Expression. 85 86FIRE generally tries to put the burden on the frontend. It chooses a 87representation that is convenient for the clients of the frontend. 88For example, it requires that all names have been resolved. 89 90 91Basic Data Types 92---------------- 93 94FIRE mostly uses the types defined in AIRE. 95 96IR_Kind: this is not an enumeration member, but a pointer to an opaque 97information structure. This should be of no consequence, but IR_Kind 98is no longer an integral type that can be used to index arrays, say. 99 100IR_Direction: new type to denote the direction of ranges. 101 102IR_String: new type to hold a constant string and do memory management 103for it. 104 105 106IIR Base Class 107-------------- 108 109The get_kind and get_kind_text functions of AIRE are named kind and 110kind_name in FIRE, for no good reasons. 111 112No source location methods are implemented. Instead, a IIR node 113points to a IIR_PosInfo node. Predefined IIR_PosInfo types include 114IIR_PosInfo_TextFile and IIR_PosInfo_Sheet. It is possible to 115trivially implement new kinds of position information. 116 117IIR_Statement is not implemented. 118 119 120IIR_DesignFile & IIR_Comment Derived Classes 121-------------------------------------------- 122 123Unimplemented. Comments are ignored completely and DesignFiles are 124not mapped into the graph. The largest unit for a graph is a design 125unit. Design files are handled by the frontend. 126 127 128IIR_Literal Derived Classes 129--------------------------- 130 131IIR_TextLiteral has an IR_String attribute called `text' that holds 132the characters of the literal. IIR_Identifier, IIR_CharacterLiteral, 133and IIR_StringLiteral are derived from TextLiteral without adding any 134new features. There is no `get' method. 135 136There is no IIR_BitStringLiteral because the lexer converts bit string 137literals immediately into IIR_StringLiterals. It would be better to 138retain bit string literals unchanged to produce better error messages. 139 140IIR_IntegerLiteral just uses a IR_String for the value, without any 141support routines. When we want to have arbitrary integers, we should 142be using a bignum package (like GNU mp) and remove 143IIR_IntegerLiteral32, IIR_IntegerLiteral64 completely. The same 144applies to IIR_FloatingPointLiteral and derived types. 145 146There are additional types IIR_AbstractLiteral, 147IIR_AbstractIntegerLiteral, and IIR_AbstractFloatingPointLiteral to 148further structure the hierachy. 149 150 151IIR_Tuple Derived Classes 152------------------------- 153 154IIR_AssociationElement: Moved actual from AEByExpression to here. 155Added formal_conversion and actual_conversion. When actual is 156IIR_OpenExpression, then it's an AEOpen, else it's an AEByExpression. 157The types AEByExpression and AEOpen are there and correctly used, too. 158 159IIR_BreakElement: unused/unimplemented. 160 161IIR_CaseStatementAlternative: Moved ChoiceList from CSAByChoices to 162base class. CSAByExpression, CSAByChoices, CSAByOthers are not used. 163It's all in the ChoiceList. This could be done AIRE style. 164 165IIR_Choice: added CByExpression, CByRange, CByOthers. Choice is an 166abstract class. This could be done AIRE style. 167 168IIR_ConditionalWaveform: unused/unimplemented. A conditional signal 169assignemnt is expanded into its equivalent process. 170 171IIR_ConfigurationItem: derived from IIR_DeclarativeRegion for historic 172reasons. Needs to be cleaned up. 173 174IIR_ComponentConfiguration: has no `name' element. 175 176IIR_Designator*: unused/unimplemented. 177 178IIR_Elsif: unused/unimplemented. 179 180IIR_SelectedWaveform: unused/unimplemented. A selected signal 181assignemnt is expanded into its equivalent process. 182 183IIR_Simultanous*: unused/unimplemented. 184 185IIR_ElementAssociation, IIR_IndexedAssociation: new, used for 186aggregates. 187 188IIR_AttributeValue: new, used for user defined attributes. 189 190 191Lists 192----- 193 194Lists are currently a cheap cop out. They don't implement any of the 195baroque ADT stuff from AIRE, but are simply singly linked lists with a 196first and rest pointer. I think the AIRE interface could be provided 197but is not very useful. 198 199Not all lists have been implemented, only those that are actually 200used. Some new lists are also there. 201 202IIR_GenericList, IIR_PortList: not used because they are not derived 203from IIR_InterfaceList and I want to have `generic' functions that can 204work both on a GenericList and a PortList. This is no big loss. 205 206 207IIR_TypeDefinition and IIR_NatureDefinition Derived Classes 208----------------------------------------------------------- 209 210Here are many significant deviations from AIRE. I had especially 211little respect when I did this part of FIRE and it shows. 212 213All IIR_TypeDefinitions have lost their "Definition" suffix. Thus, 214IIR_TypeDefinition is now IIR_Type. This is easy to revert of course. 215 216Types have a pointer to their declaration. 217 218Scalar types have no range (it is contained in their primary 219subtype(?)). 220 221Subtypes are arranged differently. Subtypes form their own hierachy: 222 223 IIR_Type: Type base 224 IIR_Subtype: Type immediate_base, FunctionDeclaration res_func 225 IIR_ScalarSubtype: Range range 226 IIR_ArraySubtype: TypeList constraint 227 228This avoids gratitous duplication of code for the original multitude 229of similar Subtypes that weren't related hierachically. 230 231The range of a ScalarSubtype is denoted by the IIR_Range hierachy. 232This allows not only for explicit ranges but also for ranges denoted 233by attributes. 234 235There is no IIR_RangeTypeDefinition. 236 237Record and Array types are derived from the new IIR_CompositeType. 238 239ArrayTypes are not restricted to one dimension. This is important. 240We can either support it directly in the spec or everybody is forced 241to non-portably kluge around it. See SAVANT. 242 243IIR_Signature: unused/unimplemented. 244 245IIR_NatureDefinition: unused/unimplemented. 246 247 248IIR_Declaration Derived Classes 249------------------------------- 250 251In addition to the declarations, we also maintain the nested 252declarative regions in the graph, so that backends can walk them in a 253generic way. 254 255IIR_Declaration: moved attributes to here and use AttributeValue 256instead of AttributeSpecification. Has pointer to containing 257IIR_DeclarativeRegion. 258 259IIR_DeclarativeRegion: new. Chains declarative regions of one scope 260together with a `continued' pointer. Has list of contained 261IIR_Declarations. This means that declarations that have their own 262IIR_DeclarationList in AIRE are now derived from IIR_DeclarativeRegion 263and inherit the list. Makes much more sense. 264 265IIR_LoopDeclarativeRegion: new. 266 267IIR_FunctionDeclaration: pure is just a boolean. 268 269IIR_EnumerationLiteral: has no position info. 270 271IIR_NatureElementDeclaration: unused/unimplemented. 272 273IIR_SubtypeDeclaration: derived from TypeDeclaration. 274 275IIR_NatureDeclaration: unused/unimplemented. 276 277IIR_SubnatureDeclaration: unused/unimplemented. 278 279IIR_ObjectDeclaration: added initial_value. 280 281IIR_ConstantDeclaration, IIR_VariableDeclaration, 282IIR_SharedVariableDeclaration, IIR_SignalDeclaration: no value, use 283initial_value of ObjectDelcaration. The graph is not intented to be 284used at simulation-time. 285 286IIR_TerminalDeclaration, IIR_QuantityDeclaration: unused/unimplemented. 287 288IIR_InterfaceDeclaration: derived from IIR_ObjectDeclaration. Added 289`boolean buffer'. No value, see IIR_ConstantDeclaration, et al. 290 291IIR_TerminalInterfaceDeclaration, IIR_QuantityInterfaceDeclaration: 292unused/unimplemented. 293 294IIR_AliasDeclaration: derived from IIR_ObjectDeclaration. No name, 295initial_value refers to aliased object (via ObjectReference, 296presumably). 297 298IIR_ComponentDeclaration: derived from IIR_DeclarativeRegion. This 299probably can be fixed but it doesn't hurt either. 300 301IIR_Group*: unused/unimplemented. Needs fixing. 302 303IIR_LibraryUnit: added library_name to help identify units. 304 305IIR_EntityDeclaration: has no `architectures' pointer. The full list 306of architectures can not be determined when parsing the entity 307declaration and the graph should not be mutated later. Finding all 308architectures of an entity is a useful thing but I do not consider it 309to be the job of the frontend. More often than not, the architectures 310aren't needed anyway. 311 312IIR_PackageDeclaration: like architectures of entities, I consider it 313to be out of the scope of the frontend to find the package body for a 314package. 315 316IIR_PackageBodyDeclaration: rather, a package body points back to its 317package declaration. 318 319IIR_PhysicalUnit: added pointer to defining PhysicalType. 320 321IIR_AttributeSpecification: unused/unimplemented. Use AttributeValue 322instead, much simpler. 323 324IIR_ConfigurationSpecification: has no component_name, entity_aspect, 325and instantiation_list but simply a `LibraryUnit unit'. 326 327IIR_DisconnectSpecification: used for only one signal, which is 328denoted by `IIR_Expression guarded_signal'. 329 330IIR_LibraryClause: has no logical_name. 331 332IIR_UseClause: has no selected_name, but a direct pointer to the used 333unit. 334 335 336IIR_Name derived Classes 337------------------------ 338 339No Name class is used/implemented. All references are resolved. 340Attributes are implemented as Expressions. 341 342 343IIR_Expression Derived Classes 344------------------------------ 345 346No MonadicOperator or DyadicOperator is implemented. They are 347expressed by function calls that point to the declaration of the 348operator. 349 350We need a number of new node types to refer to objects and literals. 351AIRE seems to allow literals and objects directly in expressions, but 352FIRE doesn't. This and most of the other changes are done to make the 353life of the backend easier. By using these additional `indirect' 354classes, we can be more precise and explicit. 355 356IIR_AbstractLiteralExpression: new, used to refer to IIR_AbstractLiterals. 357 358IIR_PhysicalLiteral: derived from AbstractLiteralExpression. 359 360IIR_ArrayLiteralExpression: new, used to refer to IIR_StringLiterals. 361 362IIR_EnumLiteralReference: new, used to refer to 363IIR_EnumerationLiterals. 364 365IIR_NullExpression, IIR_OpenExpression: new, useful. 366 367IIR_Aggregate: split into RecordAggregate and ArrayAggregate with 368their own specialized Element/IndexedAssociations. 369 370IIR_OthersInitialization: unused/unimplemented. 371 372IIR_FunctionCall: `implementation' is called `function', for no good 373reason. 374 375IIR_ObjectReference: new, used to refer to objects. The hierarchy is 376 377 ObjectReference 378 SimpleReference: ObjectDeclaration object 379 AccessReference: Expression access 380 RecordReference: Expression record, ElementDeclaration element 381 GenericArrayReference: Expression array 382 ArrayReference: ExpressionList indices 383 SliceReference: Range range 384 385Builtin attributes are also derived from Expression. They are mostly 386copied verbatim from the old VAUL definitions. There is no similarity 387to the unimplemented AIRE Attribute classes. The similarity could be 388achieved, but they should remain Expressions. 389 390 391IIR_SequentialStatement Derived Classes 392--------------------------------------- 393 394IIR_SequentialStatement: moved label from unimplemented IIR_Statement 395to here. 396 397IIR_ProcedureCallStatement: has no procedure_name, points directly to 398ProcedureDeclaration. 399 400IIR_IfStatement: does not use ElsIf. Instead, if/elsif chains are 401rewritten into equivalent nested ifs. 402 403IIR_LoopStatement: new, used as common base of ForLoopStatement and 404WhileLoopStatement. Does not have declaration list, but points to 405LoopDeclarativeRegion. 406 407IIR_LoopControlStatement: new, used as common base of NextStatement, 408ExitStatement. 409 410 411IIR_ConcurrentStatement Derived Classes 412--------------------------------------- 413 414IIR_ConcurrentStatement: derived from DeclarativeRegion, for 415historical reasons. Needs to be fixed, maybe. 416 417IIR_ProcessStatement: added `boolean guarded'. 418 419IIR_ConcurrentProcedureCallStatement, ConcurrentAssertionStatement, 420ConcurrentConditionalSignalAssignment, 421ConcurrentSelectedSignalAssignment: unused/unimplemented. They are 422rewritten into their equivalent ProcessStatement. 423 424IIR_ComponentInstantiationStatement: added pointer to 425ConfigurationSpecification that configures this thing. 426 427IIR_ConcurrentGenerateStatement: new, used as common base class of 428ConcurrentGenerateForStatement and ConcurrentGenerateIfStatement. 429 430 431IIR_SimultanousStatement Derived Classes 432---------------------------------------- 433 434unused/unimplemented. 435