Re: Ann: Luxasm 00.01.00 (2004-04-08)

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 04/29/04 

Date: Thu, 29 Apr 2004 05:08:41 +0100

Herbert Kleebauer wrote:
> Beth wrote:
> > Now, you did mention something about 60 to 70 ns, Herbert...but,
yeah,
> > the BIOS set-up program just doesn't seem to have any such
> > option...just some "DRAM refresh" setting that is either "fast" or
> > "slow" (with no indication what "fast" or "slow" might mean in
> > numerical terms ;)...any suggestions about that?
>
> Maybe you can use an external setup program (search google
> with "bios setup program"), e.g.:
[ snip ]

Yes, thanks again...I _think_ it might be working now...well, I can't
be completely sure how stable it is just yet because I've kind of only
just done it (well, you never know...*touch wood*...might be a case of
"lucky so far" than actually stable but, as every second ticks by,
it's looking more promising that it's not going to randomly crash
;)...but it's all running smoothly far beyond where it normally
crashes...and, yup, that extra boost of memory is clearly making quite
a noticable difference to how the system is generally speeding
along...

[ Still think it's kind of a scandalous disgrace, mind you, for a text
editor, console window, "explorer" and some small system utilities
(clipboard, clock, etc. ;), combined with the GUI to be taking 200MB
or so...but that's modern bloatware programming for you, ain't
it...heck, Windows takes up 100MB to do absolutely nothing (labelled
as "system cache" but, ummm, still runs like a snail carrying a
tortoise carrying a snail that if this is operation _with_ "system
cache", we'd be in a whole heap of trouble if it wasn't there ;) so,
comparatively, this is angelically good use of memory... ]

Oh, the program says that it supports _both_ 3.3V and 5V...so, just a
case of that 60ns / 70ns access time? Or is it a problem to "mix and
match" that it's having the other 64MB memory module in there that's
causing the problem? Sorry for all the questions but, truth be told, I
have very little idea about the more "technical" bits of
hardware...you know, I see it all from a "software" perspective
mostly...programming hardware at the low-level, sure...making sure it
all works with respect to "voltage" and stuff? Nah, now you're
stepping into what I consider "systems support" rather than "systems
programming"...

[ snip ]
> > Linux working for a project to create a "Linux only"* assembler,
eh?
>
> I always thought, an assembler is CPU specific but not OS specific.

Well, yes...but that's kind of the point - the part we "loaned" off
Rene - with LuxAsm...it's to be a "specific assembler"...that is, all
our support and decisions are going to be about creating Linux
X-Windows applications...much like everything in RosAsm is "Win32
specific"...

Perhaps a better way to put it is that it's an assembler written for
Linux (so, like MASM can only run on DOS / Win32, for example, LuxAsm
only runs under Linux...or, at least, under "*NIX clones" because, as
I noted, we're keeping support open for BSD and others too...Linux is
the primary target but *NIX systems similar enough that it's only a
"tweak" to the system calls will probably get their own versions too
because, unlike Win32, UNIX and X-Windows are portable standards that
it can be moved around a bit more with minimum "porting" needed...the
x86 bias, though, remains...LuxAsm is an x86 assembler and will itself
be eventually written in LuxAsm...so perhaps we should say "XFree86"
rather than X-Windows and Linux / FreeBSD rather than "UNIX clones",
so to speak, because it'll be written in x86 ASM itself ;)...the
support provided will all be Linux / ELF / XFree86 specific too (how
exactly is "yet to be decided", mind you ;)...

> There are maybe different executable formats so the linker has to
> be OS specific, but the assembler only converts symbolic
representations of
> processor instructions into it's binary equivalent. If you write
> the assembler in standard C, it should compile on any system with
> a C compiler available (all you need is FILE, stdin, stdout,
fopen(),
> fopenb(), fclose(), getc(), putc(), exit() ).

Ah, yes; You are, of course, entirely right...if you write the
assembler in C then you can re-compile it to all manner of systems and
the only thing that needs to be "specific" is the linker (though, hey,
you _could_ write a "portable" linker too...that is, the linker itself
could be run on any system...just you can't necessarily run its output
on that system...e.g. a Win32 version of the linker could be used to
link an ELF file...you wouldn't be able to directly run that file on
Windows but, indeed, it's only a specific format of data put into a
file that there's nothing stopping Windows _creating_ the ELF, even if
it can't actually run the output :)...

But this is what is delibrately different about LuxAsm...it chooses
NOT to be so "portable" in order to deliver _specific_ support...like
SpAsm / RosAsm, it's delibrately decided to be a "specific
assembler"...

"What's the point in that?", you may ask...

Well, over here in the UK, there's a car insurance firm that only
accepts _female_ drivers...it's "woman specific" quite
delibrately...what's the benefit in this? Simple statistics: Most
people who make claims tend to be young, male drivers...hence, an
insurance scheme that delibrately kicks them out significantly reduces
the number of claims made and, thus, the insurance premiums are,
therefore, lower...so, by being "specific" (and, yeah, I suppose a
touch "sexist" but about time the shoe was put on the other foot for
once, that being a _man_ is the problem here, not being a
woman...indeed, if you feel offended by this kind of sexism, then now
you're starting to get the point loud and clear ;), you can get the
same insurance cover for less money...

Or, if you like, staying on a similar theme, there are gynecologists -
"woman specific doctors" - and midwives and maternity wards
("pregnancy specific", which due to human biology, just so happens to
be "woman specific" again ;) and so forth in your local
hospital...they "specialise" in a particular medical field so as to
deliver _specific_ medical care in that area...similarly, there's
"sperm banks" and doctors who specialise in male prostrate problems or
whatever too, I'm sure...while you might complain that the car
insurance thing is just "sexism" (but, then, it's young, male drivers
rushing about wrecklessly that _cause_ the bias in the statistics to
justify that scheme...if they didn't, it wouldn't save money and then
the scheme wouldn't have a leg to stand on...so the words "their own
dumb fault" springs to mind there ;), the medical aspects here are
"sensible sexism / justifiable sexism"...there are actual biological
differences between the genders so treatments will often have to
differ so the needed "specialists" in those fields of medicine will
differ too...

This doesn't invalidate a "general practitioner" in any way,
though...still need our "general doctors" to go to, so that they can
diagnose that some ache or pain in your back somewhere is something
for a "spine specialist" to see rather than just a case of "ah, you've
just overdone thing lifting heavy objects...just rest for a few days
and it'll clear up quite naturally"...

Okay, these analogies are really going off a wild tangent here that
everyone's thinking "what's this got to do with anything?"...but the
underlying basic point is just demonstrating cases where _specific_
makes a whole lot more sense than "generic"...

Of course, there are also cases where "generic" makes a whole lot more
sense than "specific"...such as the "general practitioner" - "general
doctor" - who makes that first diagnosis of the problem...for that
job, you _want_ an "all-rounder" who knows a little about everything
so they can work out the problem and send you to the right
"specialist"...you don't, for example, go to see a "spinal specialist"
when you've got a stomach ache...a man with a toothache has totally
gone to the wrong place if they go visit a gynecologist...

Hopefully, you get the basic point of these analogies,
anyway...neither "specific" nor "generic" is in any way "wrong"
inherently...despite the way people blow trumpets about "portability",
something that isn't "portable" things isn't necessarily "wrong" in
any way for being so...

And, for LuxAsm, the decision - the "trade-off" - has been selected on
the "specific" side of things...this assembly language package (it
will eventually be a whole set of tools with an IDE and all that
stuff, not only just the assembler ;) will be a "Linux
specialist"...that's the decision that's been made...and the idea of
making this decision is to _focus_ all the support on this chosen
target...

It's a "trade-off", basically...and the point here is that the
trade-off has been made in the _other direction_ to the usual
"portability" concepts...you may personally have no need of this or
"philosophically disagree" with such a choice, but no-one is
"wrong"...this is just a case of delibrately taking the _other path_
when coming up to the cross-roads...which, indeed, will take you along
a different journey to a potentially different destination...but, hey,
if that's _where you want to go_, then LuxAsm is the train upon which
you jump aboard...not every train in Britain ends at London, not every
train in America ends in Washington D.C., not every train in Germany
ends at Berlin...different journeys have different destinations...the
thing that would actually be "wrong" here is to insist that people can
only get aboard trains that take them only to capital cities and not
to run any trains that end up in any other destination...yeah, LuxAsm
is a "local service" very delibrately...perhaps entirely useless to
people in the big city, who are all using Windows, but these people
_aren't_ our target customers...we provide a "specialist" and "local"
service, targetted to local needs...as simple as that...

Beth :)

Quantcast