Re: TASM revisited
- From: rhyde@xxxxxxxxxx
- Date: 15 Dec 2006 15:43:27 -0800
ernobe wrote:
On Dec 13, 8:42 pm, "randyh...@xxxxxxxxxxxxx" <randyh...@xxxxxxxxxxxxx>
wrote:
By "stack
overhead" do you mean the overhead of the associated system calls that
slows down execution?
No. System calls have nothing to do with this.
But aren't Windows and Unix designed to be portable to architectures
other than a Von Neumann architecture?
I can't vouch for Unix, but to my knowledge Windows has never been
ported to a non-Von Neumann machine. In theory, the a.out, PE, and ELF
formats could just as easily run on a Havard machine as well as a VN
machine, but again, system calls have nothing to do with this.
In a system specific to a Von
Neumann architecture, system calls could be coded in assembly language
rather than C,
I fail to see what the machine architecture has to do with this.
Assuming the OS on the targer architecture reasonably supports C and
assembly, I cannot see why system calls could not be made in either
language.
and could be efficiently integrated into assembly
programs, because the overhead of an artificially imposed operating
system could be avoided.
Again, I'm just not following where you're headed here.
I suppose that developing such an operating
system could help your HLA students learn assembly even better, because
they would have a better understanding of how to use existing operating
system resources to their advantage.
I'm sure you could make a claim that *any* amount of programming work
would help "HLA students", but the truth is, anything that does not
directly correspond to learning how to use machine instructions to
solve problems, especially at the beginning level, is a distraction in
my opinion. Given the limited amount of time students have in a
classroom, the only time you want to deviate from teaching them about
machine instructions is when you can show that either:
1) the deviation actually increases the efficiency of the educational
process (e.g., using high-level like control structures early on in the
course), or
2) the deviation increases the average students' interest in the course
so they'll work harder at it.
At best, your suggestion would fall under (2), but I doubt it would be
sufficient motivation for the average student. Therefore, I'd consider
such a plan to be dangerous as it distracts the students away from
learning assembly language in the course. To be fair, of course, I must
admit that I've not tried such an approach (largely because I think it
would be too much of a distraction), so there is always the chance that
I'm wrong about it's impact on a course. However, having tried lots of
other little side trips along the way, I suspect that my opinion is, at
least, an educated one.
If the items to be processed are
put in a list and are processed using a loop, isn't it like
implementing Forth?
Or any other imperative language?
Is HLA in fact a disguise for ( yet another )
implementation of Forth?
Boy, that came out of left field. If your claiming that HLA is a
disguise for a language that processes lists using iteration, then we
could say that HLA is a disguise for just about every imperative
language out there.
Cheers,
Randy Hyde
.
- Follow-Ups:
- Re: TASM revisited
- From: ernobe
- Re: TASM revisited
- References:
- Re: TASM revisited
- From: ernobe
- Re: TASM revisited
- From: rhyde
- Re: TASM revisited
- From: ernobe
- Re: TASM revisited
- From: rhyde
- Re: TASM revisited
- From: ernobe
- Re: TASM revisited
- From: randyhyde@xxxxxxxxxxxxx
- Re: TASM revisited
- From: ernobe
- Re: TASM revisited
- From: randyhyde@xxxxxxxxxxxxx
- Re: TASM revisited
- From: ernobe
- Re: TASM revisited
- From: randyhyde@xxxxxxxxxxxxx
- Re: TASM revisited
- From: ernobe
- Re: TASM revisited
- Prev by Date: Re: Some advice from the people who know please.
- Next by Date: BIOS disk read operations
- Previous by thread: Re: TASM revisited
- Next by thread: Re: TASM revisited
- Index(es):
Relevant Pages
|
Loading