Introdução ao Desenvolvimento de Compiladores - Revision history

Root: Redirected page to ist:Introdução ao Desenvolvimento de Compiladores

2018-12-05T22:07:22Z

Redirected page to ist:Introdução ao Desenvolvimento de Compiladores

← Older revision		Revision as of 22:07, 5 December 2018
Line 1:		Line 1:
	~~__NOTOC__~~		#REDIRECT [[ist:Introdução ao Desenvolvimento de Compiladores]]
	~~{{NAVCompiladores}}~~

	Our approach to compiler development follows the classical structure based on a workflow that starts with lexical analysis, followed by syntactic analysis, semantic analysis, and code generation. The mentioned steps are based on two code generators (one for creating the scanner and another for creating the syntactic parser) and on modules manually written by the programmer.

	Even though we use the classical versions of the scanner and parser generators (Flex and BYACC), we do not use the C language. Rather, we use C++. Furthermore, we do not limit ourselves to switching languages and programming a number of classes. We make full use of object-oriented programming and structures driven by design patterns to achieve a compiler that is simultaneously cleanly organized and easy to understand and change. These are crucial aspects, both in what concerns programming effort and didactic objectives.

	~~== Regarding C++ ==~~

	Using C++ is not only a way of ensuring a "better C", but also a way of being able to use OO architecture principles in a native environment (the same principles could have been applied to C development, at the cost of increased development difficulties). Thus, we are not interested only in taking a C++ compiler, our old C code, and "hope for the best". Rather, using C++ is intended to impact every step of compiler development, from the organization of the compiler as a whole to the makeup of each component.

	Using C++ is not only a decision of what language to use to write the code: it is also a matter of who or what writes the compiler code. If, for a human programmer, using C++ is just a matter of competence, tools that generate some of the compiler's code must be chosen carefully so that the code they generate works as expected.

	Some of the most common compiler development support tools already support C++ natively. This is the case of the Flex lexical analyser or the Bison parser generator. Other tools, such as Berkeley YACC (BYACC) support only C. In the former case, the generated code and the objects it supports have only to be integrated into the architecture; in the latter case, further adaptation may be needed, either by the programmer or through specialized wrappers. BYACC-generated parsers, in particular, as will be seen, although they are C code, are simple to adapt to C++.

	~~== Regarding Design Patterns ==~~

	Going beyond basic OO principles into the world of design patterns is just a small step, but one that contributes much of the overall gains in this change: indeed, effective use of a few choice design patterns -- especially, but not necessarily limited to, the ''composite'' and ''visitor'' design patterns -- contributes to a much more robust compiler and a much easier development process.

	[[~~category~~:Compiladores]]
	~~[[category:Ensino]]~~
	~~[[en:Introduction to Compiler Development~~]]

Root at 13:16, 13 April 2015

2015-04-13T13:16:41Z

← Older revision		Revision as of 13:16, 13 April 2015
Line 2:		Line 2:
	{{NAVCompiladores}}		{{NAVCompiladores}}

	Our approach to compiler development follows the classical structure based on a ~~airflow~~ that starts with lexical analysis, followed by syntactic analysis, semantic analysis and code generation. The mentioned steps are based on two code generators (one for creating the scanner and another ~~fire~~ creating the syntactic parser) and on modules manually written by the programmer.		Our approach to compiler development follows the classical structure based on a workflow that starts with lexical analysis, followed by syntactic analysis, semantic analysis, and code generation. The mentioned steps are based on two code generators (one for creating the scanner and another for creating the syntactic parser) and on modules manually written by the programmer.

	Even though we use the classical versions of the scanner and parser generators (Flex and BYACC), we do not use the C language. Rather, we use C++. Furthermore, we do limit ourselves to switching languages and programming a number of classes. We make full use of object-oriented programming and structures driven by design patterns to achieve a compiler that is simultaneously cleanly organized and easy to understand and change. These are crucial aspects, both in what concerns programming effort and ~~the~~ didactic objectives.		Even though we use the classical versions of the scanner and parser generators (Flex and BYACC), we do not use the C language. Rather, we use C++. Furthermore, we do not limit ourselves to switching languages and programming a number of classes. We make full use of object-oriented programming and structures driven by design patterns to achieve a compiler that is simultaneously cleanly organized and easy to understand and change. These are crucial aspects, both in what concerns programming effort and didactic objectives.

	== Regarding C++ ==		== Regarding C++ ==
Line 10:		Line 10:
	Using C++ is not only a way of ensuring a "better C", but also a way of being able to use OO architecture principles in a native environment (the same principles could have been applied to C development, at the cost of increased development difficulties). Thus, we are not interested only in taking a C++ compiler, our old C code, and "hope for the best". Rather, using C++ is intended to impact every step of compiler development, from the organization of the compiler as a whole to the makeup of each component.		Using C++ is not only a way of ensuring a "better C", but also a way of being able to use OO architecture principles in a native environment (the same principles could have been applied to C development, at the cost of increased development difficulties). Thus, we are not interested only in taking a C++ compiler, our old C code, and "hope for the best". Rather, using C++ is intended to impact every step of compiler development, from the organization of the compiler as a whole to the makeup of each component.

	Using C++ is not only a decision of what language to use to write the code: it is also a matter of who or what writes the compiler code. If for a human programmer using C++ is just a matter of competence, tools that generate some of the compiler's code must be chosen carefully so that the code they generate works as expected.		Using C++ is not only a decision of what language to use to write the code: it is also a matter of who or what writes the compiler code. If, for a human programmer, using C++ is just a matter of competence, tools that generate some of the compiler's code must be chosen carefully so that the code they generate works as expected.
	Some of the most common compiler development support tools already support C++ natively. This is the case of the ~~GNU~~ Flex lexical analyser or the ~~GNU~~ Bison parser generator. Other tools, such as Berkeley YACC (BYACC) support only C. In the former case, the generated code and the objects it supports have only to be integrated into the architecture; in the latter case, further adaptation may be needed, either by the programmer or through specialized wrappers. BYACC-generated parsers, in particular, as will be seen, although they are C code, are simple to adapt to C++.
			Some of the most common compiler development support tools already support C++ natively. This is the case of the Flex lexical analyser or the Bison parser generator. Other tools, such as Berkeley YACC (BYACC) support only C. In the former case, the generated code and the objects it supports have only to be integrated into the architecture; in the latter case, further adaptation may be needed, either by the programmer or through specialized wrappers. BYACC-generated parsers, in particular, as will be seen, although they are C code, are simple to adapt to C++.

	== Regarding Design Patterns ==		== Regarding Design Patterns ==

Root: /* Regarding C++ */

2012-03-16T00:06:16Z

Regarding C++

← Older revision		Revision as of 00:06, 16 March 2012
Line 8:		Line 8:
	== Regarding C++ ==		== Regarding C++ ==

	Using C++ is not only a way of ensuring a "better C", but also a way of being able to use OO architecture principles in a native environment (the same principles could have been applied to C development, at the cost of increased development difficulties). Thus, we are not interested only in taking a C++ compiler, our old C code and "hope for the best". Rather, using C++ is intended to impact every step of compiler development, from the organization of the compiler as a whole to the makeup of each component.		Using C++ is not only a way of ensuring a "better C", but also a way of being able to use OO architecture principles in a native environment (the same principles could have been applied to C development, at the cost of increased development difficulties). Thus, we are not interested only in taking a C++ compiler, our old C code, and "hope for the best". Rather, using C++ is intended to impact every step of compiler development, from the organization of the compiler as a whole to the makeup of each component.

	Using C++ is not only a decision of what language to use to write the code: it is also a matter of who or what writes the compiler code. If for a human programmer using C++ is just a matter of competence, tools that generate some of the compiler's code must be chosen carefully so that the code they generate works as expected.		Using C++ is not only a decision of what language to use to write the code: it is also a matter of who or what writes the compiler code. If for a human programmer using C++ is just a matter of competence, tools that generate some of the compiler's code must be chosen carefully so that the code they generate works as expected.

Root at 00:01, 16 March 2012

2012-03-16T00:01:14Z

← Older revision		Revision as of 00:01, 16 March 2012
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	{{NAVCompiladores}}		{{NAVCompiladores}}
	== Regarding C++ ~~and Pattern-Oriented Programming~~ ==
			Our approach to compiler development follows the classical structure based on a airflow that starts with lexical analysis, followed by syntactic analysis, semantic analysis and code generation. The mentioned steps are based on two code generators (one for creating the scanner and another fire creating the syntactic parser) and on modules manually written by the programmer.

			Even though we use the classical versions of the scanner and parser generators (Flex and BYACC), we do not use the C language. Rather, we use C++. Furthermore, we do limit ourselves to switching languages and programming a number of classes. We make full use of object-oriented programming and structures driven by design patterns to achieve a compiler that is simultaneously cleanly organized and easy to understand and change. These are crucial aspects, both in what concerns programming effort and the didactic objectives.

			== Regarding C++ ==

	Using C++ is not only a way of ensuring a "better C", but also a way of being able to use OO architecture principles in a native environment (the same principles could have been applied to C development, at the cost of increased development difficulties). Thus, we are not interested only in taking a C++ compiler, our old C code and "hope for the best". Rather, using C++ is intended to impact every step of compiler development, from the organization of the compiler as a whole to the makeup of each component.		Using C++ is not only a way of ensuring a "better C", but also a way of being able to use OO architecture principles in a native environment (the same principles could have been applied to C development, at the cost of increased development difficulties). Thus, we are not interested only in taking a C++ compiler, our old C code and "hope for the best". Rather, using C++ is intended to impact every step of compiler development, from the organization of the compiler as a whole to the makeup of each component.
Line 7:		Line 12:
	Using C++ is not only a decision of what language to use to write the code: it is also a matter of who or what writes the compiler code. If for a human programmer using C++ is just a matter of competence, tools that generate some of the compiler's code must be chosen carefully so that the code they generate works as expected.		Using C++ is not only a decision of what language to use to write the code: it is also a matter of who or what writes the compiler code. If for a human programmer using C++ is just a matter of competence, tools that generate some of the compiler's code must be chosen carefully so that the code they generate works as expected.
	Some of the most common compiler development support tools already support C++ natively. This is the case of the GNU Flex lexical analyser or the GNU Bison parser generator. Other tools, such as Berkeley YACC (BYACC) support only C. In the former case, the generated code and the objects it supports have only to be integrated into the architecture; in the latter case, further adaptation may be needed, either by the programmer or through specialized wrappers. BYACC-generated parsers, in particular, as will be seen, although they are C code, are simple to adapt to C++.		Some of the most common compiler development support tools already support C++ natively. This is the case of the GNU Flex lexical analyser or the GNU Bison parser generator. Other tools, such as Berkeley YACC (BYACC) support only C. In the former case, the generated code and the objects it supports have only to be integrated into the architecture; in the latter case, further adaptation may be needed, either by the programmer or through specialized wrappers. BYACC-generated parsers, in particular, as will be seen, although they are C code, are simple to adapt to C++.

			== Regarding Design Patterns ==

	Going beyond basic OO principles into the world of design patterns is just a small step, but one that contributes much of the overall gains in this change: indeed, effective use of a few choice design patterns -- especially, but not necessarily limited to, the ''composite'' and ''visitor'' design patterns -- contributes to a much more robust compiler and a much easier development process.		Going beyond basic OO principles into the world of design patterns is just a small step, but one that contributes much of the overall gains in this change: indeed, effective use of a few choice design patterns -- especially, but not necessarily limited to, the ''composite'' and ''visitor'' design patterns -- contributes to a much more robust compiler and a much easier development process.

Root at 18:06, 26 June 2010

2010-06-26T18:06:35Z

← Older revision		Revision as of 18:06, 26 June 2010
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
			{{NAVCompiladores}}
	== Regarding C++ and Pattern-Oriented Programming ==		== Regarding C++ and Pattern-Oriented Programming ==

Root at 18:29, 15 November 2008

2008-11-15T18:29:45Z

← Older revision		Revision as of 18:29, 15 November 2008
Line 9:		Line 9:
	Going beyond basic OO principles into the world of design patterns is just a small step, but one that contributes much of the overall gains in this change: indeed, effective use of a few choice design patterns -- especially, but not necessarily limited to, the ''composite'' and ''visitor'' design patterns -- contributes to a much more robust compiler and a much easier development process.		Going beyond basic OO principles into the world of design patterns is just a small step, but one that contributes much of the overall gains in this change: indeed, effective use of a few choice design patterns -- especially, but not necessarily limited to, the ''composite'' and ''visitor'' design patterns -- contributes to a much more robust compiler and a much easier development process.

	[[category:~~Compilers~~]]		[[category:Compiladores]]
	[[category:~~Teaching~~]]		[[category:Ensino]]
	[[en:Introduction to Compiler Development]]		[[en:Introduction to Compiler Development]]

Root: Introduction to Compiler Development moved to Introdução ao Desenvolvimento de Compiladores

2008-11-15T17:00:58Z

Introduction to Compiler Development moved to Introdução ao Desenvolvimento de Compiladores

← Older revision	Revision as of 17:00, 15 November 2008
(No difference)

Root at 17:00, 15 November 2008

2008-11-15T17:00:27Z

← Older revision		Revision as of 17:00, 15 November 2008
Line 11:		Line 11:
	[[category:Compilers]]		[[category:Compilers]]
	[[category:Teaching]]		[[category:Teaching]]
	[[pt:~~Introdução ao Desenvolvimento de Compiladores~~]]		[[en:Introduction to Compiler Development]]

Root at 17:00, 15 November 2008

2008-11-15T17:00:04Z

← Older revision		Revision as of 17:00, 15 November 2008
Line 11:		Line 11:
	[[category:Compilers]]		[[category:Compilers]]
	[[category:Teaching]]		[[category:Teaching]]
			[[pt:Introdução ao Desenvolvimento de Compiladores]]

Root at 14:58, 16 March 2008

2008-03-16T14:58:06Z

← Older revision		Revision as of 14:58, 16 March 2008
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
	~~{{TOCright}}~~
	== Regarding C++ and Pattern-Oriented Programming ==		== Regarding C++ and Pattern-Oriented Programming ==