From: "Vladimir Olensky" <vladimir_olensky@yahoo.com>
Subject: Re: Why should hackers love Ada. (Re: Ada 95 based RTOS)
Date: 2000/02/24
Date: 2000-02-24T00:00:00+00:00 [thread overview]
Message-ID: <sbaekgcfr2a64@corp.supernews.com> (raw)
In-Reply-To: Uw7t4.13$8K5.505@newsread1.prod.itd.earthlink.net
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 30439 bytes --]
David C. Hoos, Sr. wrote in message ...
>
>Vladimir Olensky <vladimir_olensky@yahoo.com> wrote in message
>news:sb8gj38sr2a132@corp.supernews.com...
>>
>> Marin D. Condic wrote in message <38B41432.88D7389F@quadruscorp.com>...
>>
>> >But I suppose those who would hang the moniker "hacker" upon themselves
>> >really want assembly language - only without the inconvenience of having
>> >to learn a new one every time new hardware comes out. Hence the
>> >popularity of things like C with hackers.
>> >
>>
>>
>> There even exists HLA (High Level Assembler) project which is nothing
>> more than new variation of C.
>> Intention is to use it instead of different assemblers.
>>
>Are you confusing the term HLA with that of High-Level Architecture,
>described in the following paragraphs from the project website?
>http://www.sisostds.org/stdsdev/hla/
Not at all.
But I should admit that I was wrong that HLA is another
version of C :-(.
Something wrong switched on in my mind.
HLA is some mix of different syntax features but it
looks more like Ada than C.
See below some notes where author explains why HLA
looks more like Ada than C.
Ada people would be pleased with that words.
And that is just about "Why should hackers love Ada" :-)
>If not, where can one get information about High Level Assembler?
Pas de probleme.
Below is what I've extracted from my archive.
=================================================
From: Randall Hyde <rhyde@shoe-size.com>
Subject: High Level Assembly FAQ
Date: 9 ������ 1999 �. 6:58
=============================================================
The High Level Assembly Frequently Asked Questions (FAQ) List
=============================================================
This document describes the HLA (High Level Assembly)
language. Many of these questions were asked in newsgroups
or email, some questions are simply "anticipated" questions
injected to help describe the HLA system.
-------- Purpose and General Questions ----------------------
1: q. Where do you get a copy of HLA
a. http://webster.cs.ucr.edu
Following the High Level Assembly links.
2: q. What is HLA?
a. HLA is a high level assembly language. It uses
a high level language like syntax (similar to
Pascal, C/C++, and other HLLs) for variable
declarations, procedure declarations, and
procedure calls. It uses a modified assembly
language syntax for the standard machine
instructions. It also provides several high
level language style control structures (if,
while, repeat..until, etc.) that help you
write much more readable code.
3: q. Doesn't the presence of HLL control structures
technically make HLA a high level language?
a. These control structures are similiar to those
provide by MASM and TASM (indeed, HLA's are
weaker in some respects). So unless you're
willing to call MASM and TASM high level
languages, it doesn't make sense to call HLA a
high level language. Definitely, though, HLA
provides a syntax that is usually "higher level"
that that provided by MASM or TASM (even in
TASM's IDEAL mode).
4: q. HLA programs look like Pascal. Why didn't you
make them look more like C/C++?
a. Actually, they look more like Ada or Modula-2
than Pascal, but to answer the real question,
Pascal is a much cleaner, easier to read language
that C/C++. The intent was to create an
assembly language that allows the creation of
readable programs. The Pascal/Modula-2/Ada
branch of the programming languages tree is
generally acknowledged as producing more readable
programs than the C/C++ branch.
5: q. But there are more C/C++ programmers today than
Pascal programmers. Don't you think that using
a C/C++ based syntax would have made HLA easier
to learn by most people?
a. No.
HLA is only superficially related to Pascal.
While Pascal programmers might have a tiny
advantage when learning HLA, the majority of
the learning effort is in other areas (like
learning machine language) rather than
learning Pascal's procedure declaration syntax
vs. C/C++'s (about the only area where Pascal
programmers have a real advantage).
6: q. Why is HLA necessary? What's wrong with MASM,
TASM, GAS, or NASM? Do we really need another
incompatible assembler out there?
a. HLA was written with two purposes in mind: The
first was to provide a tool that makes it very
easy (or, at least, easier) to teach assembly
language programming to University students.
Experiences at UCR bear out the success of
HLA's design (even with prototype/alpha code
with tons of bugs and little documentation,
students are producing better projects than
past courses that used MASM). The second
purpose was to provide a tool for very
serious, code-quality-conscious programmers
who want to write very powerful applications
in assembly language (as opposed to the
"DOS Hackers" who are still worrying about the
fastest "sieve" program or the fastest integer
to ASCII translation routine that can be
written.
What's wrong with MASM, TASM, GAS, and NASM?
(a) Their very syntax encourages people to
write unreadable programs (if you don't believe
me, look at the code being posted to the net).
(b) Their macro facilities are non-existent
to moderate. They don't, for example support
the creation of DSELs (domain specific embedded
languages) very well.
As to whether another incompatible assembler
is good or bad, well, that toothpaste is
already out of the tube and there is no
putting it back. If you've got two incompatible
assemblers, you may as well have three or four.
Certainly, there was no good reason to attempt
to make HLA compatible with an existing product.
The whole point of HLA was to start fresh, not
carry around a lot of old baggage from the
late '70s (when Microsoft's first assemblers
started appearing).
7: q. Is HLA intended for high level language programmers?
a. Only in the sense that a HLL programmer who
doesn't know assembly language will probably
have an easier time learning HLA rather than, say,
MASM.
Otherwise, HLA is not intended for HLLs at all.
While you can certainly write assembly language
modules in HLA that link to other HLLs, HLA was
specifically designed to let you write stand-alone
application in assembly language under Win32.
8: q. HLA looks like BASM in Delph. What relationship
does it have to BASM?
a. None whatsoever at all. Indeed, HLA only superficially
looks like BASM. Most likely, this confusion exists
because HLA looks like Pascal.
9: q. HLA looks like it will save your students a lot of
effort learning. Since the amount of information
learned is usually directly proportional to the
effort extended in learning the subject, don't you
feel you are shortchanging your students by letting
them use an assembler that requires less effort to
learn?
a. If I had a fixed amount of material to teach and I
stopped once the material was covered, this observation
would be correct. However, in the University I have
a fixed amount of time for teaching, not a fixed
amount of material to cover. By making the learning
process more efficient, I can cover more material
and get farther along in the same amount of time.
10: q. Students writing code with IF, WHILE, and FOR statements
aren't writing true assembly language code. They
are missing much of what assembly is about at that
point. This isn't teaching assembly, this is teaching
another mid-level language like C.
a. This is true. A good instructor will not allow students
to continue using HLA's high level language control
structures throughout the term. However, they come in
very handy at the beginning of the term because they
allow students to write meaningful programs using a
programming paradigm they already understand before
they've had time to assimilate the entire instruction
set.
11: q. Does HLA run under DOS?
a. No. It only runs under Win32.
12: q. Does HLA run under Win 3.11?
a. No. It only runs under Win32. That would be Windows 95, 98,
NT, and 2000 (and probably later versions as well).
13: q. Why didn't you write it so that it runs under DOS?
a. DOS is truly dead at this point. Most die-hard assembly
language programmers still work in DOS because DOS is easy
to program in assembly language and there is a large
amount of programming information associated with DOS.
A major point of HLA is that it is intended to make
Windows programming as easy as DOS in assembly language.
Currently, HLA does a good job of this with console apps.
14: q. Does HLA support console application programming?
a. Yes. Very well. The console module in the HLA Standard
Library is especially powerful.
15: q. Does HLA support graphics/GUI Windows application
programming?
a. There is nothing in the language that prevents you from
writing graphical applications. At the current time,
however, the HLA Standard Library doesn't provide much
support for GUI apps. This will change with time.
16: q. Do you provide an application framework like OWL, MFC,
or VCL for use with HLA?
a. See the above answer.
17: q. Is HLA Shareware?
a. No. HLA is free.
18: q. Is HLA GPL'd?
a. No. You are free to do whatever you want with it.
GPL puts a lot of restrictions on the code that
I don't particularly agree with.
19: q. Is HLA public domain?
a. No. I (Randall Hyde) retain the copyright.
However, I allow you to distribute the release
package with no restrictions whatsoever.
20: q. Is the source code available?
a. Not yet. I am currently putting together a formal
test suite for HLA and I don't want to release
the source code until I get the product tested
better.
21: q. Why not use the services of all the programmers
on the net to test and debug your program, as has
happened for Linux, NASM, and other Open Source
projects?
a. The HLA system is currently in excess of 100,000
lines of code. Part of this is due to inappropriate
choice of programming language (FLEX/Bison), part
of the size is due to sloppy coding, part of the
size is due to the fact that HLA is a big language.
I had to pull a lot of tricks with Flex and Bison
in order to implement the language. The code is
not easy to follow and easy to mess up if one isn't
careful. It took me over three years to create this
mess and I suspect it would take someone at least
a year to figure out what I've done (never mind
why I did it). By the time someone could really be
providing useful help, I'll have the testing finished
on my own. Then I'll release the sources.
22: q. Earlier you talked about writing readable code. Why
didn't you follow your own advice on the HLA source?
a. HLA is currently a prototype. A prototype is a
program you write in order to test ideas out. I've
been testing lots of ideas for over three years now.
Many ideas have worked, many have failed, some have
succeeded only through the application of brute force.
However, the end result of all this experimentation
is a grand kludge. The saying "always prepare to
write your program twice, because you will..."
certainly applies here. My prototype is the first
version of the program. Version 2.0 will have to
be a complete rewrite, applying what I've learned.
23: q. What are the other implications of a "prototype"
piece of software?
a. I don't have any problems changing the syntax of
the language in such a way that it renders existing
code uncompilable. I've done this on several
occasions already, it will likely happen in the
future.
24: q. What is the current version?
a. The current version changes so often that any
attempt to specify it here would produce something
that is completely out of date. Go to Webster
and you can find the latest version there.
25: q. You keep calling HLA a compiler. Aren't translators
for assembly language called assemblers?
a. In general, yes; HLA should be called an assembler.
However, the internal design is that of a compiler
rather than an assembler. Combined with the fact that
HLA produces assembly code, not object code, the label
"compiler" just seems to be a better fit.
26: q. What do you need in order to use HLA?
a. You need to be running a Win32 OS. You need the HLA
distribution package. You need MASM and a 32-bit
version of MS-link. You also need some Windows
DLL libraries like Kernel32.lib. All of these files
are available free on the Internet.
27: q. Does HLA work with TASM?
a. Kind of. The "m2t" (MASM to TASM) post-processor
program converts the HLA MASM output to a form that
will compile under TASM 4.0 (and later, hopefully).
However, since MASM is freely available from Microsoft
on the Internet, bother to use TASM seems hardly worthwhile.
28: q. Does HLA work with NASM?
a. No. Feel free to modify "m2t" to produce "m2n", though.
However, since MASM is *still* free, this doesn't seem
worth the effort.
29: q. MASM is a disgusting assembler. Why do you force us to
use it?
a. MASM, NASM, GAS, or TASM. The choice is irrelevant since
HLA automatically emits the MASM code, runs MASM, and
links the code to produce an executable. You don't write
MASM code and you don't run MASM. So unless you simply
hate Microsoft and don't want to run the software they
are giving you for free "just because," you don't have
to worry about what assembler you're using.
30: q. Microsoft software is big and slow. Why force us to use
it in order to use HLA? We'd prefer to use more
efficient code.
a. If you don't like MASM and LINK, you'll really hate
HLA. MASM and LINK are faster than HLA. Remember, HLA
is a prototype. No effort was made to make it efficient.
--------- Language Specific Questions -----------------------------
1: q. Could you give an example of a simple HLA program?
a. Here's the HelloWorld program:
program helloWorld;
#include( "stdlib.hhf" );
begin helloWorld;
stdout.put( "Hello World" nl );
end helloWorld;
2: q. Wait a second! There aren't any real machine instructions here!
This isn't assembly language.
a. Okay, here's the version in "real" machine code, still using
HLA:
program helloWorld;
#include( "stdlib.hhf" );
static
hw: string := "Hello World" nl;
begin helloWorld;
push( hw );
call stdout.puts;
end helloWorld;
Feel better? HLA lets you specify HLL-like procedure calls
and it will automatically push the parameters on the stack
for you. This is very similiar to the "invoke" statement
MASM and TASM (although I personally feel that HLA's syntax
is cleaner, clearer, and easier to read). If you really like,
you can always explicitly write the assembly instructions
yourself. However, there is little benefit to doing so.
3: q. Isn't it inefficient to pass parameters on the stack?
a. In some cases yes. But if the procedure you're calling
expects parameters on the stack, whether the compiler pushes
them or you push them, there is hardly any difference.
4: q. The statement <<hw:string:="Hello World" nl;>> hardly looks
like machine code, explain this.
a. Note that <<hw byte "Hello World",13,10,0>> is no more a
machine instruction than is the HLA declaration. Semantically,
the two are equivalent and they generate nearly the same
machine code (actually, HLA strings aren't simply zero-
terminated arrays of characters; but ignoring that...).
Syntactically, however, HLA turns out to be much easier
to read.
5: q. Initialized data in the static section appears to be typed.
What if I want to go wild and put untype, unstructured
data into my program?
a. Initialized data in the static section is indeed typed.
You cannot initialize a string variable with a floating
point numeric value (for example). However, HLA provides
a second type of data initialization section, the "data"
section, that allows the creation of unstructured
initialized data. Since most data is structured, you
will rarely use this feature in the language.
6: q. Why the parentheses around the push operand?
a. HLA instructions are "composable". This means that
you can often supply one instruction as the
operand of another instruction. For example, consider
the following statements:
mov( 0, eax );
mov( eax, ebx );
These could be rewritten as:
mov( mov( 0, eax ), ebx );
The interior mov instruction returns its destination
operand for use as the operand the instruction represents.
That is, HLA substitutes "eax" for "mov( 0, eax )" in the
statement above. This funny looking statement generates
exactly the same two instructions as the two separate
mov instructions above it.
7: q. This doesn't look very readable.
a. No, it is not. This feature needs to be used with extreme
care or you can quickly produce an unreadable mess.
However, composition of instructions is *very* useful
in certain special cases.
8: q. The operands are backwards in your examples.
a. No they are not. You're simply used to Intel syntax
whose operands are generally orderd "instr dest, src".
HLA reverses this order to obtain "instr( src, dest )"
which is a little more intuitive for most instructions.
9: q. What happens with those instructions where the src,dest
ordering is not intuitive?
a. HLA uses dest, src ordering. The two primary examples
are "cmp( dest, src )" and "lea( dest, src )".
10: q. Wait, this is horrible! You're saying that you're
inconsistent with the order of the operands?
a. No. Intel was inconsistent with the operands. They
got lea and cmp right, almost everything else was wrong;
at least if you consider the English pronouciation of
the instruction to provide the "inituitive" ordering.
We generally say "move source to dest", not "move dest
from source". Likewise, we normally say "compare dest
to source" (I can't even rephrase this with the operands
reversed, forgive me). I usually say "load a register
with an effective address." Hence the HLA syntax.
11: q. Your choice of the lea operand order is really bad.
What if we say "load effective address into register."
a. Fine, you can say that. I don't and I wrote the assembler
so I got to choose.
12: q. That makes your assembler harder to learn.
a. I disagree, but if you're really hung up on this *one*
instruction (to date, no one has complained about cmp),
you can easily write a macro to fix this problem.
Consider the following macro for "sea" (store effective
address):
macro sea( source, dest );
lea( dest, source )
endmacro;
Now your problems are solved. If you feel you must use the
lea mnemonic, you've got two choices: (1) write a preprocessor
to fix the syntax (very easy using HLA's pattern matching code)
or (2) wait until the sources are available and change the
source code.
13: q. Why didn't you use "sea" to begin with.
a. For pedagogical reasons, I wanted to stick with instruction
mnemonics that were upwards compatible with Intel's. As
a new version of "Art of Assembly" using HLA is still quite
a ways off, using Intel mnemonics allows students to look
up an instruction by name and read about its semantics.
True, the syntax is different, but providing a handout with
HLA syntax is a much smaller task than providing a handout
explaining what each instruction does.
14: q. Doesn't this (lack of good book explaining HLA syntax and
semantics) make life hard on your students?
a. Number one complaint. With time, this will go away (i.e., as
I bring various chapters of AoA/HLA on-line.
15: q. Looking though the HLA documentation suggests that HLA
supports instructions like "mov(mem, mem);", "pea( mem );",
"mul( 10, ax );" These machine instructions do not exist
on the 80x86. What's going on here.
a. Although I made sure I supported almost all of the Intel
instructions by name, by no means did I limit myself to
only using Intel mnemonics. Once I covered the basic
Intel instruction set, I took some liberties and added
a few new instructions.
mov( mem1, mem2 ), for example, compiles to
push( mem1 );
pop( mem2 );
(this only supports 16- and 32-bit operands.)
pea( mem ) compiles to
push( eax );
lea( mem );
xchg( eax, [esp] );
and finally, "mul( 10, eax );" compiles to
static tempName:dword := 10; endstatic;
mul( tempName, eax );
16: q. Isn't compiling code like this inefficient?
a. If you abuse it, yes, there can be some slight inefficiencies.
No one is putting a gun to your head and forcing you to use
these new instructions or syntaxes, however.
17: q. MASM has a nasty habit of changing instructions behind your
back. HLA also seems to have this same problem.
a. Yes and no. Once again, if you stick to straight Intel
instructions, HLA emits exactly what you specify. However,
HLA emits MASM assembly code, so MASM may do a number on
your code afterwards.
In general, I have plans of adding a data flow analyzer
and an optimizer around version three of HLA. While I
certainly intend to provide source level control of the
optimizer, if you are offended by an assembler that
plays with your source code, then HLA is not for you.
On the other hand, if you would like to be able to write
readable code and leave it up to the compiler to deal
with instruction scheduling and peep-hole optimizations,
HLA will be a big win.
18: q. Does HLA support decent macro facilities?
a. Yes. HLA supports the best macro facilities of any
programming language I have personally seen. The
macro facilities are so powerful, you can easily
extend the language with it. For example, the HLA
Standard Library includes a macro that provides
a C/C++ style switch statement. Try doing that
(easily and effectively) in MASM.
19: q. What high level language statements does HLA support?
a. if..then..elseif..else..endif, while..endwhile, for..endfor,
forever..endfor, foreach..endfor, repeat..until, break,
breakif, continue, continueif, context..exit/exitif..endcontext,
and try..exception..endtry.
20: q. What about statements like
stdout.put("hello world" nl );
a. These aren't actually statements in the HLA language. Instead,
these types of statements are either procedure calls or
macros provided by the HLA Standard Library. The HLA
Standard Library, and the way it extends the HLA language,
provides a good example of the power of HLA's macros and
HLL syntax.
21: q. Why doesn't the statement
if( ax == bx && cx < dx ) then ... endif;
work properly?
a. HLA does not allow complex expressions like this. In particular,
the conjunction operator ("&&") is not allowed here.
22: q. MASM allows this in it's .if statement.
a. Yes it does. I chose not to implement this because HLA's
HLL statements are intended as a crutch for students who
are just learning assembly. However, I don't want the
students writing arbitrary C/C++ programs in HLA. I want
to force them to think in assembly rather than in C/C++.
HLA's boolean expressions limit you to the types of operands
that are legal in a compare instruction. This better prepares
the students for when they have to use compares and conditional
jumps in place of the HLL statements.
23: q. For those of us that are advanced and understand this conversion,
this seems somewhat limiting. What if we want to use HLA's
HLL control structures to write more readable code?
a. HLA provides another syntax that lets you implement arbitrary
expressions by combining HLL syntax with low level syntax. The
previous example could be written as:
if
{
cmp( ax, bx );
jne false;
cmp( cx, dx );
jnb false;
}
.
.
.
endif;
The false label corresponds to the code after the "then"
section of the if statement (though not present, the "true"
label would transfer control directly to the "then" portion
of the if statement).
24: q. Does HLA support classes and object oriented programming?
a. Yes. It provides a very powerful class mechanism along with
static class procedures, dynamic methods, and dynamic iterators.
HLA support inheritence and many other features found in C++
and Delphi.
25: q. Do HLA procedure allow overloading?
a. Not directly. However, you can easily use macros to provide
any procedure overloading that you need?
26: q. Does HLA support operator overloading?
a. Uh, no. Assembly language in general does not support
run-time arithmetic expressions (which is where operator
overloading makes sense). Hence the notion of operator
overloading is foreign to HLA.
27: q. Doesn't HLA's HLL statements make the language inefficient?
a. Not really. First of all, keep in mind that you don't have
to use them. If you don't use them, they certainly won't
affect the efficiency of your program Second, keep in mind
that most HLL control structures compile to a cmp, a
conditional jump, and, perhaps, a jmp instruction. Since
this is exactly the type of code you'd probably write
yourself, there is very little efficiency loss.
Having said this, I should point out that anyone who
approaches assembly language programming with a HLL mindset
cannot expect to write super efficient programs. In order
to obtain the benefits of assembly language, you need to
think in assembly language. Using the HLL control structures
relieves you of the need to think in assembly language.
---------------- HLA Standard Library Questions ---------------------
1: q. How to I write a procedure that converts a number to
an ASCII string for output?
a. You don't. Instead you should call one of the many
Standard Library routines that will solve this problem
for you.
2: q. What is the HLA Standard Library?
a. It is a set of procedures you can call in your HLA
programs. There are literally hundreds of routines
you can call to accomplish many common tasks (for
example, printing a number).
3: q. What library routines are available?
a. The list appears at the end of this document (it's long!).
4: q. What are the categories these routines fall into?
a. There are several categories, here's the current list
(growing each week, so this is probably out of date):
args- Command line argument parsing.
console- Console window/smart terminal support routines.
conv- Numeric/string and other conversions.
cset- Character set functions.
excepts- Exception handling.
hla- Various constants, etc., for HLA compile-time
language support (e.g., DSELs).
hll- Macros to implement additional HLL statements.
math- Transcendental and logarithmic functions.
memory- Memory allocation and deallocation.
misctypes- Various miscellaneous data type declarations.
patterns- Pattern matching library (sorta like Snobol4/Icon).
rand- Random number generators and support routines.
stdio- Console and file I/O routines.
strings- String library.
Tables- Tables (associative array) library.
win32- Win32 API constants and declarations.
x86- Constants associated with Intel chips.
WIP (work in progress, more to come later, including the full routine
listing).
next prev parent reply other threads:[~2000-02-24 0:00 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-18 0:00 Ada 95 based RTOS xaplos
2000-02-18 0:00 ` Tucker Taft
2000-02-21 0:00 ` xaplos
2000-02-22 0:00 ` Matthew Majka
2000-02-22 0:00 ` xaplos
2000-02-22 0:00 ` Stanley R. Allen
2000-02-22 0:00 ` Marin D. Condic
2000-02-22 0:00 ` Ted Dennison
2000-02-22 0:00 ` xaplos
2000-02-23 0:00 ` Roger Racine
2000-02-24 0:00 ` Simon Wright
2000-02-24 0:00 ` Robert Dewar
2000-02-25 0:00 ` Mike Silva
2000-02-26 0:00 ` xaplos
2000-02-23 0:00 ` Tarjei T. Jensen
2000-02-23 0:00 ` Gautier
2000-02-23 0:00 ` Ehud Lamm
2000-02-23 0:00 ` Why should hackers love Ada. (Re: Ada 95 based RTOS) Marin D. Condic
2000-02-23 0:00 ` Vladimir Olensky
2000-02-23 0:00 ` Gautier
2000-02-24 0:00 ` Ehud Lamm
2000-02-24 0:00 ` David C. Hoos, Sr.
2000-02-24 0:00 ` Vladimir Olensky [this message]
2000-02-23 0:00 ` Gary
2000-02-24 0:00 ` Marin D. Condic
2000-02-24 0:00 ` Larry Kilgallen
2000-02-25 0:00 ` Gary Scott
2000-02-25 0:00 ` Mike Silva
2000-02-26 0:00 ` Gary Scott
2000-02-25 0:00 ` Marin D. Condic
2000-02-25 0:00 ` Gary
2000-02-26 0:00 ` Robert Dewar
2000-02-26 0:00 ` Gary Scott
2000-03-07 0:00 ` Mike Dimmick
2000-03-10 0:00 ` Wil
2000-03-10 0:00 ` Ada OS again " David Starner
2000-03-11 0:00 ` David Botton
2000-02-24 0:00 ` Gisle S�lensminde
2000-02-24 0:00 ` Ehud Lamm
2000-02-24 0:00 ` Ted Dennison
2000-02-23 0:00 ` Ada 95 based RTOS Ted Dennison
2000-02-25 0:00 ` Scott Ingram
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox