Re: MSIL or Bytecode taught instead of ASM
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- Date: Sat, 15 Dec 2007 11:36:31 +1000
<jehugaleahsa@xxxxxxxxx> wrote in message
news:1dcc1e9f-b26d-4593-8789-35846f575534@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Dec 12, 4:57 pm, Gene <gene.ress...@xxxxxxxxx> wrote:
On Dec 11, 6:08 pm, "jehugalea...@xxxxxxxxx" <jehugalea...@xxxxxxxxx>
wrote:
Hello:
What is going on in schools these days when it comes to teaching
assembly languages? I remember I learned Microsoft Assembler and went
on to learn GASM and NASM. However, is there any true benefit to
learning ASM anymore? Sure, it helps computer science students
understand the fundamentals of computer architecture and basic
language foundations, but is it applicable?
Well, you did a great job of saying why it's applicable. A body needs
to know something about machine-level code to understand how
compilers, processors, and OS abstractions work. Despite the best
efforts of the "high level language" communities, there are still
important cases where you need to understand compilers and processors
and OS abstractions to write good programs. Any decent school will
have some kind of introduction to machine-level programming for this
reason. After an introduction, anyone who has finished a decent
degree will be able to figure out the details should a future job
require it. That's called education! Conversely, there is little
room (as there once was) in a degree program for significant time
spent learning any given assembler or assembly language. Way too low
a roi. C is best thought of as very high level assembler. Therefore
learning a real asm is also a great introduction to C programming,
hence C++, hence Java, hence Lisp, Prolog, Haskell... There are good
arguments for learning languages by traversing up this tower of
language abstraction! Another argument says start at the top and go
down.
Agreed. It is no different from how I figured out MSIL from ASM. I
guess I am asking whether learning lower-level programming for
something more relevant to one's environment is appropriate.
note that, at present, .NET and MSIL is still a strong minority in the
developer community.
however, I do expect it will probably rise some in the future, that or be
displaced by the next thing comming along.
basically, for VMs and ILs, there is a lot less weight keeping one tied to
said IL (unlike the basic architecture).
as a result, I expect there will be, in time, increasing pressure for
architectural unification.
it is expensive to target a new arch, and very expensive to create a new
arch (or, for manufactures, to support an arch for which there is little
demand and poor OS/compiler support).
wheras creating a new IL is almost free (which is, pretty much, why damn
near every VM around has its own IL). so, the manufacturers face a strong
pressure to unify their basic instruction sets (even Intel could not break
free, we saw what happened to the Itanium...), but VM writers do not have
this pressure (thus the emergence, prevalence, acceptance, and decline of so
many VMs).
..NET and MSIL only really has as much weight as MS (and the .NET developer
community) can convince other people to use it, and if the underlying
problem goes away (the proliferation of different architectures and
associated porting difficulties), something like MSIL has lost nearly all of
its power.
VMs offer pretty much nothing that can't already be done with the basic
architecture:
GC, this is easy;
Dynamic Compilation, similarly, not too difficult;
....
IMO, it is very possible that x86-64 will become the dominant/sole
architecture for most computer-like systems (it has almost done this
already), and what is left is the console market (currently dominated by
PPC), and embedded (where, besides x86, ARM, m68k, and a few others still
hold some ground).
possibly, 32-bit x86 will become dominant in embedded systems as well
(however, there is much less pressure for standardization here, which is why
we still see ARM, m68k, ... floating around).
in such a world, things like JBC and MSIL hold a lot less sway (and have to
defend their position against nearly any other VM technology that could come
along).
more so, if the world near unifies on x86-64, they become, essentially,
mostly pointless...
even as such, the existence of VMs isn't terribly important anyways. to a
large degree, emulators and trans-compilers are often not too much worse in
terms of capability and performance, which have been used for a long time
with fairly good success by companies such as Apple and Amiga...
in this case, we use the machine code in place of the bytecode, and patch
over a few things, but the results are often similarly capable to a
traditional VM (the high or low-levelness between bytecode and machine code
is often not too major of a problem, since really the translation process is
much the same in either case, it is only really a difference in terms of
abstract model, say, a stack+register machine vs a pure stack machine, ...).
we can interpret both machine code and bytecode, and the result is similarly
slow.
and, we can JIT compile both bytecode and machine code, and the result of
often similarly fast.
thus I think is part of the problem:
Sun and MS are attacking a problem that, it would seem, exists primarily
within their own heads.
in a commercial kind of way, they want the one binary that runs everywhere.
to do what?... the same thing many opensource developers do with gcc and
good old C and C++.
to supposedly free commercial developers from needing to have a few major
builds of their software.
and, what is their solution to walking on the rocky terrain:
break legs and use an electric wheelchair.
feels nice and soft until one sees a few rocks or a patch of mud (and
realizes they can't just step over them with their now broken legs...).
right...
.
- References:
- MSIL or Bytecode taught instead of ASM
- From: jehugaleahsa@xxxxxxxxx
- Re: MSIL or Bytecode taught instead of ASM
- From: Gene
- Re: MSIL or Bytecode taught instead of ASM
- From: jehugaleahsa@xxxxxxxxx
- MSIL or Bytecode taught instead of ASM
- Prev by Date: Re: software jobs
- Next by Date: Re: MSIL or Bytecode taught instead of ASM
- Previous by thread: Re: MSIL or Bytecode taught instead of ASM
- Next by thread: Unix make on Windows and PATH variable length problem
- Index(es):
Relevant Pages
|
Loading
