Rev 30 | Rev 32 | Go to most recent revision | Only display areas with differences | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 30 | Rev 31 | ||
---|---|---|---|
1 | \chapter{Software} |
1 | \chapter{Software} |
2 | \label{tools} |
2 | \label{tools} |
3 | 3 | ||
4 | During the development of the HelenOS operating system, we came across |
4 | During the development of the HelenOS operating system, we came across |
5 | several types of software tools, programs, utilities and libraries. |
5 | several types of software tools, programs, utilities and libraries. |
6 | Some of the tools were used to develop the system itself while other tools |
6 | Some of the tools were used to develop the system itself while other tools |
7 | were used to faciliate the development process. In some cases, we had a chance |
7 | were used to faciliate the development process. In some cases, we had a chance |
8 | to try out several versions of the same product. Sometimes the new versions |
8 | to try out several versions of the same product. Sometimes the new versions |
9 | contained fixes for bugs we had discovered in previous versions thereof. |
9 | contained fixes for bugs we had discovered in previous versions thereof. |
10 | 10 | ||
11 | Another group of software we have used has been integrated into HelenOS |
11 | Another group of software we have used has been integrated into HelenOS |
12 | to fill gaps after functionality that the genuine HelenOS code did |
12 | to fill gaps after functionality that the genuine HelenOS code did |
13 | not provide itself. |
13 | not provide itself. |
14 | 14 | ||
15 | There is simply too much third party software that is somehow related to |
15 | There is simply too much third party software that is somehow related to |
16 | HelenOS to be covered all. This chapter attempts to present our experience |
16 | HelenOS to be covered all. This chapter attempts to present our experience |
17 | with the key softare tools, programs and libraries. |
17 | with the key softare tools, programs and libraries. |
18 | 18 | ||
19 | \section{Communication tools} |
19 | \section{Communication tools} |
20 | Although the developers know each other in person, the development, with the |
20 | Although the developers know each other in person, the development, with the |
21 | exception of kernel camps, has been pretty much independent as far as locality |
21 | exception of kernel camps, has been pretty much independent as far as locality |
22 | and time goes. In order to work effectively, we have established several communication |
22 | and time goes. In order to work effectively, we have established several communication |
23 | channels: |
23 | channels: |
24 | 24 | ||
25 | \begin{description} |
25 | \begin{description} |
26 | \item [E-mail] --- We used this basic means of electronic communication for peer-to-peer |
26 | \item [E-mail] --- We used this basic means of electronic communication for peer-to-peer |
27 | discussion in cases when the other person could not have been reached on-line at |
27 | discussion in cases when the other person could not have been reached on-line at |
28 | the time his advice was needed or his attention was demanded. E-mail was also |
28 | the time his advice was needed or his attention was demanded. E-mail was also |
29 | used for contacting developers of third party software that we needed to talk to. |
29 | used for contacting developers of third party software that we needed to talk to. |
30 | 30 | ||
31 | \item [Mailing list] --- As almost every open source project before us, also we opened |
31 | \item [Mailing list] --- As almost every open source project before us, also we opened |
32 | mailing list for technical discussion. The advantage of having a mailing list is |
32 | mailing list for technical discussion. The advantage of having a mailing list is |
33 | the fact that it enables multilateral discussions on several topics contemporarily, |
33 | the fact that it enables multilateral discussions on several topics contemporarily, |
34 | without the need for all the participants be on-line or even at one place. We have kept |
34 | without the need for all the participants be on-line or even at one place. We have kept |
35 | our first development mailing list closed to public so that it seemed natural to us |
35 | our first development mailing list closed to public so that it seemed natural to us |
36 | to use Czech as our communication language on the list since Czech, with one exception, |
36 | to use Czech as our communication language on the list since Czech, with one exception, |
37 | is our native language and all of us speak it very well. Besides all the advantages, |
37 | is our native language and all of us speak it very well. Besides all the advantages, |
38 | there are also disadvantages. First, communication over mailing list tends to be rather |
38 | there are also disadvantages. First, communication over mailing list tends to be rather |
39 | slow, compared for instance to ICQ. Second, because of its implicit collective nature, |
39 | slow, compared for instance to ICQ. Second, because of its implicit collective nature, |
40 | it sometimes tends to be so slow that an answer for a given question never comes. |
40 | it sometimes tends to be so slow that an answer for a given question never comes. |
41 | 41 | ||
42 | Apart from the internal development mailing list, we have also used another mailing list |
42 | Apart from the internal development mailing list, we have also used another mailing list |
43 | for commit log messages which proved handy in keeping developers informed about all changes in |
43 | for commit log messages which proved handy in keeping developers informed about all changes in |
44 | the repository. |
44 | the repository. |
45 | 45 | ||
46 | Finally, we have also established a public mailing list for communication |
46 | Finally, we have also established a public mailing list for communication |
47 | about general HelenOS topics in English. |
47 | about general HelenOS topics in English. |
48 | 48 | ||
49 | \item [ICQ] --- Because we divided the whole project into smaller subprojects on which |
49 | \item [ICQ] --- Because we divided the whole project into smaller subprojects on which |
50 | only the maximum of two people out of six would work together, the need for communication |
50 | only the maximum of two people out of six would work together, the need for communication |
51 | among all six people was significantly smaller than the need to communicate between the two |
51 | among all six people was significantly smaller than the need to communicate between the two |
52 | developers who tightly cooperated on a specific task. For this reason, we made the biggest |
52 | developers who tightly cooperated on a specific task. For this reason, we made the biggest |
53 | use of ICQ. |
53 | use of ICQ. |
54 | \end{description} |
54 | \end{description} |
55 | 55 | ||
56 | \section{Concurrent versions systems} |
56 | \section{Concurrent versions systems} |
57 | At the very beginning, when the SPARTAN kernel was being developed solely |
57 | At the very beginning, when the SPARTAN kernel was being developed solely |
58 | by \JJ, there was not much sence in using any software for management of |
58 | by \JJ, there was not much sence in using any software for management of |
59 | concurrent versions. However, when the number of developers increased to six, |
59 | concurrent versions. However, when the number of developers increased to six, |
60 | we immediately started to think of available solutions. |
60 | we immediately started to think of available solutions. |
61 | 61 | ||
62 | We have begun with CVS because it is probably the best known file concurrent |
62 | We have begun with CVS because it is probably the best known file concurrent |
63 | versions system. We have even had repository of HelenOS using CVS for a short time, |
63 | versions system. We have even had repository of HelenOS using CVS for a short time, |
64 | but when we learned about its weaknesses we sought another solution. There are two |
64 | but when we learned about its weaknesses we sought another solution. There are two |
65 | weaknesses that have prevented us from using CVS: |
65 | weaknesses that have prevented us from using CVS: |
66 | 66 | ||
67 | \begin{itemize} |
67 | \begin{itemize} |
68 | \item it is merely a file concurrent versions system (i.e. CVS is |
68 | \item it is merely a file concurrent versions system (i.e. CVS is |
69 | good at managing versions of each separate file in the repository |
69 | good at managing versions of each separate file in the repository |
70 | but has no clue about the project's directory tree as a whole; |
70 | but has no clue about the project's directory tree as a whole; |
71 | specifically renaming of a file while preserving its revision history |
71 | specifically renaming of a file while preserving its revision history |
72 | is next to impossible), |
72 | is next to impossible), |
73 | 73 | ||
74 | \item it lacks atomic commits (i.e. should your commit conflict with |
74 | \item it lacks atomic commits (i.e. should your commit conflict with |
75 | another recent commit of another developer, CVS would not abort the whole operation |
75 | another recent commit of another developer, CVS would not abort the whole operation |
76 | but render the repository inconsistent instead). |
76 | but render the repository inconsistent instead). |
77 | \end{itemize} |
77 | \end{itemize} |
78 | 78 | ||
79 | Being aware of these limitations, we decided to go with Subversion. Subversion |
79 | Being aware of these limitations, we decided to go with Subversion. Subversion |
80 | is, simply put, a redesigned CVS with all the limitations fixed. We were |
80 | is, simply put, a redesigned CVS with all the limitations fixed. We were |
81 | already familiar with CVS so the switch to Subversion was pretty seamless. |
81 | already familiar with CVS so the switch to Subversion was pretty seamless. |
82 | 82 | ||
83 | As for Subversion itself, it has worked for us well and has met all our |
83 | As for Subversion itself, it has worked for us well and has met all our |
84 | expectations. Despite all its pros, there was a serious problem that |
84 | expectations. Despite all its pros, there was a serious problem that |
85 | occurred sometime in the middle of the development process. Because of some locking |
85 | occurred sometime in the middle of the development process. Because of some locking |
86 | issues related to the default database backend (i.e. {\tt Berkeley DB}), |
86 | issues related to the default database backend (i.e. {\tt Berkeley DB}), |
87 | our Subversion repository put itself in a peculiar state in which it became |
87 | our Subversion repository put itself in a peculiar state in which it became |
88 | effectivelly inaccessible by any means of standard usage or administration. |
88 | effectivelly inaccessible by any means of standard usage or administration. |
89 | To mitigate this problem, we had to manually delete orphaned file locks |
89 | To mitigate this problem, we had to manually delete orphaned file locks |
90 | and switch to backend called {\tt fsfs} which doesn't suffer this |
90 | and switch to backend called {\tt fsfs} which doesn't suffer this |
91 | problem. |
91 | problem. |
92 | 92 | ||
93 | Other than that, we are happy users of Subversion. The ability to switch |
93 | Other than that, we are happy users of Subversion. The ability to switch |
94 | the entire working copy to particular revision is a great feature |
94 | the entire working copy to particular revision is a great feature |
95 | for debugging. Once we tracked a bug three months into the past by |
95 | for debugging. Once we tracked a bug three months into the past by |
96 | moving through revisions until we found the change that caused the bug. |
96 | moving through revisions until we found the change that caused the bug. |
97 | 97 | ||
98 | \section{Web tools} |
98 | \section{Web tools} |
99 | On our project website\cite{helenos}, we provided links to different |
99 | On our project website\cite{helenos}, we provided links to different |
100 | web utilities that either functioned to access our Subversion repository |
100 | web utilities that either functioned to access our Subversion repository |
101 | or mailing list or provided another services: |
101 | or mailing list or provided another services: |
102 | 102 | ||
103 | \begin{description} |
103 | \begin{description} |
104 | \item [Chora] is a part of the Horde framework and can be used to comfortably |
104 | \item [Chora] is a part of the Horde framework and can be used to comfortably |
105 | browse Subversion repository from the web. We altered it a little bit to also |
105 | browse Subversion repository from the web. We altered it a little bit to also |
106 | show number of commits per developer on our homepage. |
106 | show number of commits per developer on our homepage. |
107 | 107 | ||
108 | \item [WHUPS] is another component of the Horde framework. It provides |
108 | \item [WHUPS] is another component of the Horde framework. It provides |
109 | feature request and bug tracking features. However, in the light of being rather |
109 | feature request and bug tracking features. However, in the light of being rather |
110 | closed group of people, we used this tool only seldomly. On the other hand, |
110 | closed group of people, we used this tool only seldomly. On the other hand, |
111 | any possible beta tester of our operating system has had a chance to |
111 | any possible beta tester of our operating system has had a chance to |
112 | submit bug reports. |
112 | submit bug reports. |
113 | 113 | ||
114 | \item [Mailman] is a web interface to the mailing list we utilized. It allows |
114 | \item [Mailman] is a web interface to the mailing list we utilized. It allows |
115 | to control subsriptions and search mailing list archives on-line. |
115 | to control subsriptions and search mailing list archives on-line. |
116 | \end{description} |
116 | \end{description} |
117 | 117 | ||
118 | \section{Third party components of HelenOS} |
118 | \section{Third party components of HelenOS} |
119 | HelenOS itself contains third party software. In the first place, amd64 and ia32 architectures |
119 | HelenOS itself contains third party software. In the first place, amd64 and ia32 architectures |
120 | make use of GNU Grub boot loader. This software replaced the original limited boot loader |
120 | make use of GNU Grub boot loader. This software replaced the original limited boot loader |
121 | after the Kernel Camp 2005 when {\MD} had made HelenOS Multiboot specification compliant. Because of |
121 | after the Kernel Camp 2005 when {\MD} had made HelenOS Multiboot specification compliant. Because of |
122 | Grub, HelenOS can be booted from several types of devices. More importantly, we use |
122 | Grub, HelenOS can be booted from several types of devices. More importantly, we use |
123 | Grub to load HelenOS userspace modules as well. |
123 | Grub to load HelenOS userspace modules as well. |
124 | 124 | ||
125 | Another third-party piece of the HelenOS operating system is the userspace {\tt malloc()}. |
125 | Another third-party piece of the HelenOS operating system is the userspace {\tt malloc()}. |
126 | Rather than porting our kernel slab allocator to userspace, we have chosen Doug Lea's public |
126 | Rather than porting our kernel slab allocator to userspace, we have chosen Doug Lea's public |
127 | domain {\tt dlmalloc} instead. This allocator could be easily integrated into our uspace tree |
127 | domain {\tt dlmalloc} instead. This allocator could be easily integrated into our uspace tree |
128 | and has proven itself in other projects as well. Its derivative, {\tt ptmalloc}, has been part of the |
128 | and has proven itself in other projects as well. Its derivative, {\tt ptmalloc}, has been part of the |
129 | GNU C library for some time. However, the version we are using is not optimized for SMP and multithreading. |
129 | GNU C library for some time. However, the version we are using is not optimized for SMP and multithreading. |
130 | We plan to eventually replace it with another allocator. |
130 | We plan to eventually replace it with another allocator. |
131 | 131 | ||
132 | \section{Build tools} |
132 | \section{Build tools} |
133 | Assembler, linker and compiler are by all means the very focal point of attention |
133 | Assembler, linker and compiler are by all means the very focal point of attention |
134 | of all operating system projects. Quality of these tools influences |
134 | of all operating system projects. Quality of these tools influences |
135 | operating system performance and, what is more important, stability. HelenOS has |
135 | operating system performance and, what is more important, stability. HelenOS has |
136 | been tailored to build with GNU {\tt binutils} (i.e. the assembler and linker) and GNU~{\tt gcc} |
136 | been tailored to build with GNU {\tt binutils} (i.e. the assembler and linker) and GNU~{\tt gcc} |
137 | (i.e. the compiler). There is only little chance that it could be compiled and |
137 | (i.e. the compiler). There is only little chance that it could be compiled and |
138 | linked using some other tools unless those tools are compatible with the GNU build tools. |
138 | linked using some other tools unless those tools are compatible with the GNU build tools. |
139 | 139 | ||
140 | As our project declares support for five different processor architectures, |
140 | As our project declares support for five different processor architectures, |
141 | we needed to have five different flavors of the build utilities installed. |
141 | we needed to have five different flavors of the build utilities installed. |
142 | Interestingly, flavors of {\tt binutils} and {\tt gcc} for particular architecture |
142 | Interestingly, flavors of {\tt binutils} and {\tt gcc} for particular architecture |
143 | are not equal from the point of view of cross-binutils and cross-compiler installation. |
143 | are not equal from the point of view of cross-binutils and cross-compiler installation. |
144 | All platforms except ia64 require only the {\tt binutils} package and the {\tt gcc} package |
144 | All platforms except ia64 require only the {\tt binutils} package and the {\tt gcc} package |
145 | for the cross-tool to be built. On the other hand, ia64 requires also some excerpts from |
145 | for the cross-tool to be built. On the other hand, ia64 requires also some excerpts from |
146 | the ia64-specific part of {\tt glibc}. |
146 | the ia64-specific part of {\tt glibc}. |
147 | 147 | ||
148 | Formerly, the project could be compiled with almost any version of {\tt binutils} starting with 2.15 |
148 | Formerly, the project could be compiled with almost any version of {\tt binutils} starting with 2.15 |
149 | and {\tt gcc} starting with 2.95, but especially after we added partial thread local storage |
149 | and {\tt gcc} starting with 2.95, but especially after we added partial thread local storage |
150 | support into our userspace layer, some architectures (e.g. mips32) will not compile even with {\tt gcc} 4.0.1 |
150 | support into our userspace layer, some architectures (e.g. mips32) will not compile even with {\tt gcc} 4.0.1 |
151 | and demand {\tt gcc} 4.1.0. Curiously, ia64 will not link when compiled with {\tt gcc} 4.1.0. |
151 | and demand {\tt gcc} 4.1.0. Curiously, ia64 will not link when compiled with {\tt gcc} 4.1.0. |
152 | 152 | ||
153 | As for the mips32 cross-compiler, {\OP} discovered a bug in {\tt gcc} (ticket \#23824) which caused {\tt gcc} to |
153 | As for the mips32 cross-compiler, {\OP} discovered a bug in {\tt gcc} (ticket \#23824) which caused {\tt gcc} to |
154 | incorrectly generate unaligned data access instructions (i.e. {\tt lwl}, {\tt lwr}, {\tt swl} and {\tt swr}). |
154 | incorrectly generate unaligned data access instructions (i.e. {\tt lwl}, {\tt lwr}, {\tt swl} and {\tt swr}). |
155 | 155 | ||
156 | As for the mips32 cross-binutils\footnote{It remains uninvestigated whether this problem also shows with other cross-tools.}, |
156 | As for the mips32 cross-binutils\footnote{It remains uninvestigated whether this problem also shows with other cross-tools.}, |
157 | we observed that undefined symbols are not reported when we don't link using the standard target. We are still not |
157 | we observed that undefined symbols are not reported when we don't link using the standard target. We are still not |
158 | sure whether this was a bug --- {\tt binutils} developers just told us to use the standard target and then use |
158 | sure whether this was a bug --- {\tt binutils} developers just told us to use the standard target and then use |
159 | {\tt objcopy} to convert the ELF binary into requested output format. |
159 | {\tt objcopy} to convert the ELF binary into requested output format. |
160 | 160 | ||
161 | \section{Virtual environments} |
161 | \section{Virtual environments} |
162 | After the build tools, simulators, emulators and virtualizers were the second focal point |
162 | After the build tools, simulators, emulators and virtualizers were the second focal point |
163 | in our project. These invaluable programs really sped the code-compile-test cycle. |
163 | in our project. These invaluable programs really sped the code-compile-test cycle. |
164 | In some cases, they were, and still are, the only option to actually run HelenOS on certain |
164 | In some cases, they were, and still are, the only option to actually run HelenOS on certain |
165 | processor architectures, because real hardware was not available to us. Using virtual environment |
165 | processor architectures, because real hardware was not available to us. Using virtual environment |
166 | for developing our system provided us with deterministic environment on wich it is much easier to do |
166 | for developing our system provided us with deterministic environment on wich it is much easier to do |
167 | troubleshooting. Moreover, part of the simulators featured integrated debugging facilities. |
167 | troubleshooting. Moreover, part of the simulators featured integrated debugging facilities. |
168 | Without them, a lot of bugs would remain unresolved or even go unnoticed. |
168 | Without them, a lot of bugs would remain unresolved or even go unnoticed. |
169 | 169 | ||
170 | From one point of view, we have tested our system on eight different virtual environments: |
170 | From one point of view, we have tested our system on eight different virtual environments: |
171 | 171 | ||
172 | \begin{itemize} |
172 | \begin{itemize} |
173 | \item Bochs, |
173 | \item Bochs, |
174 | \item GXemul, |
174 | \item GXemul, |
175 | \item msim, |
175 | \item msim, |
176 | \item PearPC, |
176 | \item PearPC, |
177 | \item QEMU, |
177 | \item QEMU, |
178 | \item Simics, |
178 | \item Simics, |
179 | \item Ski, |
179 | \item Ski, |
180 | \item VMware. |
180 | \item VMware. |
181 | \end{itemize} |
181 | \end{itemize} |
182 | 182 | ||
183 | From the second point of view, we have tested these programs by our operating system. |
183 | From the second point of view, we have tested these programs by our operating system. |
184 | Because of the scope and uniqueness of this testing and because we did find some issues, |
184 | Because of the scope and uniqueness of this testing and because we did find some issues, |
185 | we want to dedicate some more space to what we have found. |
185 | we want to dedicate some more space to what we have found. |
186 | 186 | ||
187 | \subsection{Bochs} |
187 | \subsection{Bochs} |
188 | Bochs has been used to develop the SPARTAN kernel since its beginning in 2001. |
188 | Bochs has been used to develop the SPARTAN kernel since its beginning in 2001. |
189 | It is capable of emulating ia32 machine and for some time also amd64. |
189 | It is capable of emulating ia32 machine and for some time also amd64. |
190 | Bochs is an emulator and thus the slowest from virtual environments capable |
190 | Bochs is an emulator and thus the slowest from virtual environments capable |
191 | of simulating the same cathegory of hardware. On the other hand, it is extremely |
191 | of simulating the same cathegory of hardware. On the other hand, it is extremely |
192 | portable, compared to much faster virtualizers and emulators using dynamic translation |
192 | portable, compared to much faster virtualizers and emulators using dynamic translation |
193 | of instructions. Lately, there have been some plans to develop or port dynamic translation |
193 | of instructions. Lately, there have been some plans to develop or port dynamic translation |
194 | to Bochs brewing in its developer community. |
194 | to Bochs brewing in its developer community. |
195 | 195 | ||
196 | The biggest virtue of Bochs is that it has traditionally supported SMP. For some time, Bochs |
196 | The biggest virtue of Bochs is that it has traditionally supported SMP. For some time, Bochs |
197 | has been our only environment on wich we could develop and test SMP code. Unfortunatelly, |
197 | has been our only environment on wich we could develop and test SMP code. Unfortunatelly, |
198 | the quality of SMP support in Bochs was different from version to version. Because of SMP |
198 | the quality of SMP support in Bochs was different from version to version. Because of SMP |
199 | breakage in Bochs, we had to avoid some versions thereof. So far, Bochs versions 2.2.1 and 2.2.6 |
199 | breakage in Bochs, we had to avoid some versions thereof. So far, Bochs versions 2.2.1 and 2.2.6 |
200 | have been best in this regard. |
200 | have been best in this regard. |
201 | 201 | ||
202 | Our project has not only used Bochs. We also helped to identify some SMP related problems |
202 | Our project has not only used Bochs. We also helped to identify some SMP related problems |
203 | and {\OP} from our team has discovered and also fixed a bug in FXSAVE and FXRSTOR emulation |
203 | and {\OP} from our team has discovered and also fixed a bug in FXSAVE and FXRSTOR emulation |
204 | (patch \#1282033). |
204 | (patch \#1282033). |
205 | 205 | ||
206 | Bochs has some debugging facilities but those have been very impractical and broken |
206 | Bochs has some debugging facilities but those have been very impractical and broken |
207 | in SMP mode. |
207 | in SMP mode. |
208 | 208 | ||
209 | \subsection{GXemul} |
209 | \subsection{GXemul} |
210 | GXemul is an emulator of several processor architectures. Nevertheless, we have |
210 | GXemul is an emulator of several processor architectures. Nevertheless, we have |
211 | used it only for mips32 emulation in both little-endian and big-endian modes. |
211 | used it only for mips32 emulation in both little-endian and big-endian modes. |
212 | It seems to be pretty featurefull and evolving but we don't use all its functionality. |
212 | It seems to be pretty featurefull and evolving but we don't use all its functionality. |
213 | GXemul is very user friendly and has debugging features. It is more realistic |
213 | GXemul is very user friendly and has debugging features. It is more realistic |
214 | than msim. However, our newly introduced TLS support triggered a bug in the {\tt rdhwr} |
214 | than msim. However, our newly introduced TLS support triggered a bug in the {\tt rdhwr} |
215 | instruction emulation while msim functioned as expected. Fortunatelly, the author |
215 | instruction emulation while msim functioned as expected. Fortunatelly, the author |
216 | of GXemul is very cooperative and has fixed the problem for future versions as well as |
216 | of GXemul is very cooperative and has fixed the problem for future versions as well as |
217 | provided a quick hack for the old version. |
217 | provided a quick hack for the old version. |
218 | 218 | ||
219 | \subsection{msim} |
219 | \subsection{msim} |
220 | msim has been our first mips32 simulator. It simulates 32-bit side of R4000 processor. |
220 | msim has been our first mips32 simulator. It simulates 32-bit side of R4000 processor. |
221 | Its simulated environment is not very realistic, but the processor simulation |
221 | Its simulated environment is not very realistic, but the processor simulation |
222 | is good enough for operating system development. In this regard, the simulator is |
222 | is good enough for operating system development. In this regard, the simulator is |
223 | comparable to HP's ia64 simulator Ski. Another similar aspect of these two is |
223 | comparable to HP's ia64 simulator Ski. Another similar aspect of these two is |
224 | relatively strong debugger. |
224 | relatively strong debugger. |
225 | 225 | ||
226 | Msim has been developed on the same alma mater as our own project. |
226 | Msim has been developed on the same alma mater as our own project. |
227 | All members of our team know this program from operating system courses. |
227 | All members of our team know this program from operating system courses. |
228 | Curiously, this simulator contained the biggest number of defects and inaccuracies |
228 | Curiously, this simulator contained the biggest number of defects and inaccuracies |
229 | that we have ever discovered in a simulator. Fortunately, all of them have been |
229 | that we have ever discovered in a simulator. Fortunately, all of them have been |
230 | eventually fixed. |
230 | eventually fixed. |
231 | 231 | ||
232 | \subsection{PearPC} |
232 | \subsection{PearPC} |
233 | PearPC is the only emulator on wich we have run ppc32 port of HelenOS. It has |
233 | PearPC is the only emulator on wich we have run ppc32 port of HelenOS. It has |
234 | no debugging features, but fortunatelly its sources are available under |
234 | no debugging features, but fortunatelly its sources are available under |
235 | an open source license. This enabled {\OP} and {\MD} to alter its sources |
235 | an open source license. This enabled {\OP} and {\MD} to alter its sources |
236 | in a way that this modified version allowed some basic debugging. |
236 | in a way that this modified version allowed some basic debugging. |
237 | 237 | ||
238 | \subsection{QEMU} |
238 | \subsection{QEMU} |
239 | QEMU emulates several processor architectures. We have used it to emulate |
239 | QEMU emulates several processor architectures. We have used it to emulate |
240 | ia32 and amd64. It can simulate SMP, but contrary to Bochs, it uses dynamic |
240 | ia32 and amd64. It can simulate SMP, but contrary to Bochs, it uses dynamic |
241 | translation of emulated instructions and performs much better because of |
241 | translation of emulated instructions and performs much better because of |
242 | that. |
242 | that. |
243 | 243 | ||
244 | \subsection{Simics} |
244 | \subsection{Simics} |
245 | \subsection{Ski} |
245 | \subsection{Ski} |
246 | \subsection{VMware} |
246 | \subsection{VMware} |
247 | 247 | ||
248 | \section{Authoring tools} |
248 | \section{Authoring tools} |
249 | 249 |