A regular expression engine for asm?
Al Leitch
more about regular expressions, I wondered if somebody tried to make an
RE library for assembly language people. The most likely person I could
think of is Randall Hyde with his HLA and standard library. Just curious
people.
The Mosquito ScriptKiddiot
funny, i was thinking the *exact* same thing just a couple days ago, but this
thread will prove that altho it mite be a good exercise (regular expressions
can get complicated), free RE libraries are already available that provide APIs
u can actually use from masm32, for instance...but i dont think they were
written in pure asm
http://board.win32asmcommunity.net/showthread.php?s=&threadid=13260&highli
ght=regular+expressions
hth
--The Mosquito Scriptkiddiot.
"I wish I was a glow worm
A glow worm's never glum
'Cos how can you be grumpy
When the sun shines out your bum!"
Hein Hobma
opcodeac@3*&hotmail.com says...
I made a complete ANSI c Re project manager, engine included, see my
site (non optimized). An RE engine is to vast and complicated to write
sec in asm. More practical is write it in c and optimize parts in asm,
that I did. The result is dramatic, it decreased my book (html) project
(two languages 120 files, 4 meg) from a few minutes to under 25 seconds
(10-15 is my goal!). I am in the last opti round, the result will be
upped to my site in a few months. It is hoped for, to be the fastest
around, and the easiest to work with (RE-engin).
--
m. v. g,
with kind regards,
Hein Hobma
Reisverslag:
http://home.hccnet.nl/hth.hobma/
Circumnavigation:
http://home.hccnet.nl/hth.hobma/English/
Randall Hyde
"Al Leitch" <opcodeac@3*&hotmail.com> wrote in message news:9VY0b.1617$Ej6...@newsread4.news.pas.earthlink.net...
Well, HLA's Standard Library does include a vast set of "pattern matching
functions". BTW, they support context free languages, not just regular languages.
If HLA's not your style, the UCR Standard Library (16-bit, for MASM/TASM)
supports many of the same features, though the HLA pattern matching routines
work much better.
I've attached a conversion of the "regular expression" example from 'The Great
Computer Language Shoot-out" web page. This example is quite interesting as
it demonstrates that you can write some code in assembly that is *much* smaller
than the equivalent code in C. Of course, "The_Sage" had better not see this
because he'll accuse me of lying about this :-)
Cheers,
Randy Hyde
// regexpGCLS
//
// This program demonstrates processing of regular expressions in
// assembly language. This is based on the "regexp.gcc"
// program that is part of "The Great Computer
// Language Shoot-out" found at
//
// http://www.bagley.org/~doug/shootout/
//
// The purpose of that web page is to demonstrate several
// applications written in various languages. Although one
// of the primary purposes of that web site is to demonstrate
// the different run-time efficiencies of various languages,
// this HLA implementation was not created to demonstrate
// that assembly code is faster or smaller (everyone pretty
// much accepts the fact that the fastest and/or smallest
// example of a program will be written in assembly language).
// Instead, this example demonstrates that with the use of
// a high level assembler (e.g., HLA), it's also possible to
// write code almost as easily as in a high level language
// like C. As such, this example freely sacrifices efficiency
// for readability.
#if( false )
/* -*- mode: c -*-
* $Id: regexmatch.gcc,v 1.4 2000/12/24 05:43:53 doug Exp $
* http://www.bagley.org/~doug/shootout/
*/
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <pcre.h>
#include <string.h>
#define MAXLINES 100
#define MAXLINELEN 132
char *pattern =
"(?:^|[^\\d\\(])" /* must be preceeded by non-digit */
"(\\()?" /* match 1: possible initial left paren */
"(\\d\\d\\d)" /* match 2: area code is 3 digits */
"(?(1)\\))" /* if match1 then match right paren */
"[ ]" /* area code followed by one space */
"(\\d\\d\\d)" /* match 3: prefix of 3 digits */
"[ -]" /* separator is either space or dash */
"(\\d\\d\\d\\d)" /* match 4: last 4 digits */
"\\D" /* must be followed by a non-digit */
;
int
main(int argc, char *argv[]) {
int NUM = ((argc == 2) ? atoi(argv[1]) : 1);
int count;
char *cptr = "";
char **phones;
pcre *re;
int erroffset;
const char *errptr;
int n, lines = 0;
char num[256];
int i, j, k, matchlen;
char *matchoffset;
int nmatches;
int *ovec, ovecsize;
pcre_extra *study;
phones = (char **)malloc(MAXLINES * sizeof(char *));
if (!phones) {
fprintf(stderr, "malloc for phones array failed\n");
exit(1);
}
lines = 0;
while (cptr) {
phones[lines] = (char *)malloc(MAXLINELEN);
if (!phones[lines]) {
fprintf(stderr, "malloc to hold line #%d failed\n", lines);
exit(1);
}
cptr = fgets(phones[lines], MAXLINELEN, stdin);
lines++;
if (lines > MAXLINES) {
fprintf(stderr, "MAXLINES is too small\n");
exit(1);
}
}
re = pcre_compile(pattern, 0, &errptr, &erroffset, NULL);
if (!re) {
fprintf(stderr, "can't open compile regexp\n");
exit(1);
}
study = pcre_study(re, 0, &errptr);
if (pcre_fullinfo(re, NULL, PCRE_INFO_CAPTURECOUNT, &nmatches) != 0) {
fprintf(stderr, "pcre_fullinfo failed\n");
exit(1);
}
nmatches++; /* add match of entire pattern */
ovecsize = sizeof(int) * nmatches * 3;
ovec = (int *)malloc(ovecsize);
if (!ovec) {
fprintf(stderr, "malloc for ovec array failed\n");
exit(1);
}
count = 0;
while (NUM--) {
for (i=0; i<lines; i++) {
n = pcre_exec(re, study,
phones[i], strlen(phones[i]), 0,
0, ovec, ovecsize);
if (n == nmatches) {
/* stuff the match into the buffer "num" */
k = 2*2; /* initial offset into ovec */
/* areacode */
j = 0;
num[j++] = '(';
matchoffset = phones[i] + ovec[k];
matchlen = ovec[k+1] - ovec[k];
strncpy(num+j, matchoffset, matchlen);
j += matchlen; k += 2;
num[j++] = ')';
/* space separator */
num[j++] = ' ';
/* exchange */
matchoffset = phones[i] + ovec[k];
matchlen = ovec[k+1] - ovec[k];
strncpy(num+j, matchoffset, matchlen);
j += matchlen; k += 2;
/* dash */
num[j++] = '-';
/* last 4 digits */
matchoffset = phones[i] + ovec[k];
matchlen = ovec[k+1] - ovec[k];
strncpy(num+j, matchoffset, matchlen);
j += matchlen; k += 2;
/* with a cherry on top */
num[j] = 0;
if (0 == NUM) {
count++;
printf("%d: %s\n", count, num);
}
}
}
}
for (i=0; i<MAXLINES; i++) {
free(phones[i]);
}
free(phones);
free(ovec);
return(0);
}
#endif
program regexp;
#include( "stdlib.hhf" )
const
MaxLines := 100;
static
f :dword;
i :uns32;
filename :string;
lineCnt :uns32;
areaCode :str.strvar(16);
prefix :str.strvar(16);
suffix :str.strvar(16);
lines :string[ MaxLines ];
begin regexp;
if( arg.c() != 2 ) then
stdout.put( "Usage: regexp <filename>" nl );
exit regexp;
endif;
mov( fileio.open( arg.v( 1 ), fileio.r ), f );
mov( 0, ebx );
while( !fileio.eof( f )) do
fileio.a_gets( f );
mov( eax, lines[ ebx*4 ] );
inc( ebx );
endwhile;
mov( ebx, lineCnt );
fileio.close( f );
for( mov( 0, i ); mov( i, edx ) < lineCnt; inc( i )) do
pat.match( lines[ edx*4 ] );
pat.zeroOrMoreCset( -{ '(','0'..'9' } );
pat.zeroOrOneChar( '(' );
pat.exactlyNCset( {'0'..'9'}, 3 );
pat.extract( areaCode );
pat.zeroOrOneChar( ')' );
pat.zeroOrMoreWS();
pat.exactlyNCset( {'0'..'9'}, 3 );
pat.extract( prefix );
pat.oneOrMoreCset( {'-', ' '} );
pat.exactlyNCset( {'0'..'9'}, 4 );
pat.extract( suffix );
stdout.put( i:2,": (", areaCode, ") ", prefix, '-', suffix, nl );
pat.if_failure;
pat.endmatch;
endfor;
end regexp;
The_Sage
>Date written: Fri, 22 Aug 2003 04:35:25 GMT
>MsgID:<h4h1b.3021$lw4....@newsread3.news.pas.earthlink.net>
Too bad it isn't in the "more effiecient" ASM code as the requestor asked for.
The Sage
=============================================================
My Home Page : http://members.cox.net/the.sage
A mind is a terrible thing to waste...especially on creationists.
Just say no to organized superstitions, blind faith beliefs, and
ancient books with inaccurate science, blatant contradictions,
and false prophecies
=============================================================
Al Leitch
Well, that'd be k-rad, but what I really should've said is that is
there some RE engine library that we coders could tap into.
BTW, pursued any interesting projects lately? You seem to be rather
knowledgable about things :-)
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:rnttkvct63jai1uem...@4ax.com...
> >Reply to article by: "Randall Hyde" <rand...@earthlink.net>
> >Date written: Fri, 22 Aug 2003 04:35:25 GMT
> >MsgID:<h4h1b.3021$lw4....@newsread3.news.pas.earthlink.net>
>
> Too bad it isn't in the "more effiecient" ASM code as the requestor asked for.
>
Too bad you don't know what you're talking about.
Cheers,
Randy Hyde
The_Sage
>Date written: Fri, 29 Aug 2003 06:52:56 GMT
>MsgID:<cLC3b.7996$Jh2....@newsread4.news.pas.earthlink.net>
>I didn't necessarily mean that the engine had to be WRITTEN in assembly.
> Well, that'd be k-rad, but what I really should've said is that is
>there some RE engine library that we coders could tap into.
Yeah, I know, I was just ribbing Randall.
>BTW, pursued any interesting projects lately? You seem to be rather
>knowledgable about things :-)
My latest project is a 180W/Channel tri-amp with a MP3 player for my car. The
MP3 decoder requires some programming (Horror of horrors -- I'll probably do the
whole thing in ASM).
The_Sage
>MsgID:<HgS3b.1150$tw6...@newsread4.news.pas.earthlink.net>
>>Too bad it isn't in the "more effiecient" ASM code as the requestor asked for.
>Too bad you don't know what you're talking about.
Too bad you are wrong again. The subject line is "A regular expression engine
for ASM" and not your "A regular expression engine for C". Get a clue please.
The Mosquito ScriptKiddiot
sinewave
> My latest project is a 180W/Channel tri-amp with a MP3 player for my car.
cool project! you may enjoy this page at a site i frequent:
http://www.fixup.net/tips/xinmp3/index.htm
regards,
phil
Al Leitch
chip? You rock dude!
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:qj90lvsp664799rph...@4ax.com...
> >>Too bad it isn't in the "more effiecient" ASM code as the requestor asked for.
>
> >Too bad you don't know what you're talking about.
>
> Too bad you are wrong again. The subject line is "A regular expression engine
> for ASM" and not your "A regular expression engine for C". Get a clue please.
>
See what I mean?
Obviously, you didn't even look past the *comments* in the assembly
file to see the assembly code before.
Cheers,
Randy Hyde
The_Sage
>Date written: Sat, 30 Aug 2003 01:33:59 -0400
>MsgID:<oprupdqx...@10.0.0.1>
>>My latest project is a 180W/Channel tri-amp with a MP3 player for my car.
>cool project! you may enjoy this page at a site i frequent:
>http://www.fixup.net/tips/xinmp3/index.htm
Thanks for the link.
I don't care much for the MP3 projects I've seen, since none of them were
applicable to anything I wanted. I have an S2000 and the CD player it has now
skips whenever I go over certain bumps. There is nothing I can buy that will fit
the car like stock, so I decided to do it myself.
For one thing, there is no room in an S2000, so I had to find a way to install a
six speaker system without mangling the car or giving up the trunk. The radio
replacement consists of an ALPINE 1341 Digital FM/AM Tuner (obsolete) mated to a
Class-D tri-amp. The reason for the Class-D amplifiers is so that little or no
heatsinking would be required (remember the limited space thing?).
The amp also is a preamp and it will have an ordinary rotary switch to select
whatever other devices I choose, such as the built-in MP3 player. I could have
used something fancy using a PIC and some analog switches, but the PIC I have
only has two spare lines, therefore it would require yet another PIC, which I
didn't feel was worth the time or trouble.
The player is programmed with a PIC that in turn gets its data from a Compact
Flash. The Compact Flash will have no problem with harsh jolts, such as the
S2000 can give, and it is easily removable. The amp itself fits on a PCB that is
6x4 inches.
I thought about making it "open source" but I doubt anyone would want to
construct an amp, no matter how hi-performance, that costs $110 in parts,
another $110 for the PCB, yet another $100 for the speakers, requires
programming a PIC, and requires very skilled soldering skills since it uses
surface mount technology throughout. Constructing the speaker housing alone is
nothing trivial (creating the molds and then applying a kevlar/epoxy layer to
the molds). The kevlar/epoxy cost $200 (although it was one of those minimum
order things so there is way more kevlar/epoxy than what was needed for this
application).
The_Sage
>MsgID:<fX44b.2176$Lk5....@newsread3.news.pas.earthlink.net>
>>>>Too bad it isn't in the "more effiecient" ASM code as the requestor asked for.
>>>Too bad you don't know what you're talking about.
>>Too bad you are wrong again. The subject line is "A regular expression engine
>>for ASM" and not your "A regular expression engine for C". Get a clue please.
>See what I mean?
>Obviously, you didn't even look past the *comments* in the assembly
>file to see the assembly code before.
Obviously, if you can't tell the difference between C and ASM, you are in the
wrong business.
sinewave
compact flash sounds ideal, i imagine the S2000 has a stiff suspension.
does the CD player have any RAM buffer to prevent skipping? your project is
very interesting... consider a page or site when you're done. i wrote a PDF
on soldering to surface-mount to help people do shortwave receiver mods i
created.
regards,
phil
The_Sage
>MsgID:<opruqudm...@10.0.0.1>
>compact flash sounds ideal, i imagine the S2000 has a stiff suspension.
>does the CD player have any RAM buffer to prevent skipping?
Apparently not. My Toyota has a better sound system than my S2000!
>your project is
>very interesting... consider a page or site when you're done. i wrote a PDF
>on soldering to surface-mount to help people do shortwave receiver mods i
>created.
I have a quite a few SOT devices so this project requires at least a 5X
magnifying glass to assemble. I didn't figure on this simple of a project being
so expensive and complicated.
The Sage
=============================================================
My Home Page : http://members.cox.net/the.sage
"The men that American people admire most extravagantly are
most daring liars; the men they detest the most violently are
those who try to tell them the truth" -- H. L. Mencken
=============================================================
sinewave
>> compact flash sounds ideal, i imagine the S2000 has a stiff suspension.
>> does the CD player have any RAM buffer to prevent skipping?
>
> Apparently not. My Toyota has a better sound system than my S2000!
damn. i bought a portable philips CD player years ago with a RAM buffer
(there is a several second delay after you press play) and it would not
skip in my truck. it was replaced with an in-dash alpine.
> I have a quite a few SOT devices so this project requires at least a 5X
> magnifying glass to assemble. I didn't figure on this simple of a project
> being so expensive and complicated.
what you're doing is not considered simple! although, i too am guilty of
altering my toys.
regards,
phil
Beth
> oh god not again
ROTFLMAO!
*falls to knees in the sand*
"Oh my god! What have they done?!"
Beth ;)
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:g2d2lvgtvfdiv60s9...@4ax.com...
> >Reply to article by: "Randall Hyde" <rand...@earthlink.net>
> >Date written: Sat, 30 Aug 2003 17:13:47 GMT
> >MsgID:<fX44b.2176$Lk5....@newsread3.news.pas.earthlink.net>
>
>
> Obviously, if you can't tell the difference between C and ASM, you are in the
> wrong business.
So then, why are you hanging around here :-)
Cheers,
Randy Hyde
Beth
> Sage wrote:
> > Obviously, if you can't tell the difference between C and ASM, you
are in the
> > wrong business.
>
> So then, why are you hanging around here :-)
He accidentally pressed the "subscribe to this newsgroup" button and
can't work out how to unsubscribe or subscribe to some other group
instead...after months of trying to work it out, he gave up and
resigned himself to the fact that he's just stuck here, whether he
likes it or not :)
Beth :)
The_Sage
>MsgID:<SKT5b.10104$Lk5....@newsread3.news.pas.earthlink.net>
>>Obviously, if you can't tell the difference between C and ASM, you are in the
>>wrong business.
>So then, why are you hanging around here :-)
For entertainment...remember? Thanks for the entertainment :^)
The Sage
=============================================================
My Home Page : http://members.cox.net/the.sage
"The men that American people admire most extravagantly are
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:dlgilv42rtm7vk7pq...@4ax.com...
> >Reply to article by: "Randall Hyde" <rand...@earthlink.net>
> >Date written: Fri, 05 Sep 2003 03:51:14 GMT
> >MsgID:<SKT5b.10104$Lk5....@newsread3.news.pas.earthlink.net>
>
> >>Obviously, if you can't tell the difference between C and ASM, you are in the
> >>wrong business.
>
> >So then, why are you hanging around here :-)
>
> For entertainment...remember? Thanks for the entertainment :^)
Perhaps, but you've long since ceased to be entertaining.
Now you just go on and on like a broken record.
Perhaps *you* find this entertaining, but few of the rest of us do.
We can only laugh at you making a fool out of yourself for so long.
Then it just starts to get pathetic after a while.
Cheers,
Randy Hyde
The_Sage
>MsgID:<4ld6b.789$PE6...@newsread3.news.pas.earthlink.net>
>>>>Obviously, if you can't tell the difference between C and ASM, you are in the
>>>>wrong business.
>>>So then, why are you hanging around here :-)
>>For entertainment...remember? Thanks for the entertainment :^)
>Perhaps, but you've long since ceased to be entertaining.
You aren't paying attention as usual. It is *YOU* that is entertaining *ME*. You
haven't ceasted to be entertaining, so again, thanks.
>Now you just go on and on like a broken record.
You are just plain stupid when it comes to knowing computer languages at a
software engineering level.
>Perhaps *you* find this entertaining, but few of the rest of us do.
>We can only laugh at you making a fool out of yourself for so long.
>Then it just starts to get pathetic after a while.
One of the lastest entertaining thing you did was when asked for a regular
expression engine in ASM, but you couldn't follow simple directions and provided
a regular expression engine in C instead -- apparently because C is a more
efficient language to post a regular expression engine for than ASM. We are
still waiting for your more efficient regular expression engine in ASM...like
that is ever going to happen! Haha!
But the most entertaining thing you have done to date, is your ludicrous claim
and completely unsubstantiated claim that ASM is more efficient and more
versatile, but have yet to provide any example of that as well. For pretending
to be so informed, you sure don't act or talk like it. A typical software
engineering course (your's excluded) will teach you, that in regards to the
criteria for a good language...
Its definition should be independent of any particular hardware or operating
system. ASM is specific to a particular computer hardware
architecture, therefore ASM fails this criteria for a good language.
Its definition should be standardized, and compiler implementations should
comply with this standard. Assembly languages cannot be standardized due to
variations in processor architecture, therefore ASM fails this criteria for a
good language.
It should support software engineering technology, ie -- for those of you
who don't know what that is yet, by discouraging or prohibiting poor
practices, and promoting or supporting maintenance activities. ASM provides no
support for software engineering technology. ASM does not work with
abstractions, just machine-level specifics, therefore ASM fails this criteria
for a good language.
It should effectively support the application domain(s) of interest. ASM only
supports a particular hardware architecture, and, in general, it has no
inherent relationship with any particular application domains, therefore ASM
fails this criteria for a good language.
It should support the required level of system reliability and safety.
ASM provides no support for reliability or safety. ASM will not object to any
form of programming, good or bad, therefore ASM fails this criteria for a good
language.
Its compiler implementations should be commensurate with the current state of
technology. In the sense that an assembler, the "compiler" for an assembly
language, is created for each new assembly language as it is introduced,
language implementations keep up with computer technology. However, in the
sense of supporting the current level of software technology, ASM does not,
therefore ASM fails this criteria for a good language.
Appropriate software engineering-based supporting tools and environments
should be available. The tools available for working with ASM are typically
other very low-level tools, and they do not provide software engineering
support, therefore ASM fails this criteria for a good language.
Clarity of source code – the extent to which inherent language features
support source code that is readable and understandable and that clearly
reflects the underlying logical structure of the program. The source code for
an ASM application is cryptic and in a very low machine-specific form.
Hence, it is error-prone, and the structure of the program is not evident,
therefore ASM fails this criteria for a good language.
Complexity management (architecture support) – the extent to which inherent
language features support the management of system complexity, in terms of
addressing issues of data, algorithm, interface, and architectural complexity.
ASM has some algorithmic complexity management and limited structuring, but
ASM provides minimal support for complexity management, therefore ASM fails
this criteria for a good language.
Concurrency support – the extent to which inherent language features support
the construction of code with multiple threads of control (also known as
parallel processing). ASM will often provide instructions for accomplishing
multiple threads of control. However, such support is neither straightforward
nor easy to use, therefore ASM fails this criteria for a good language.
Distributed system support – the extent to which inherent language features
support the construction of code to be distributed across multiple platforms
on a network. ASM provides no specific support for distributed systems,
therefore ASM fails this criteria for a good language.
Maintainability – the extent to which inherent language features support the
construction of code that can be readily modified to satisfy new requirements
or to correct deficiencies. ASM provides no inherent support for
maintainability, therefore ASM fails this criteria for a good language.
Mixed language support – the extent to which inherent language features
support interfacing to other languages. ASM provides no capability to
interface to a higher level language (however, some high level languages
provide a capability to interface with an assembly language), therefore ASM
fails this criteria for a good language.
Object-oriented programming support – the extent to which inherent language
features support the construction of object-oriented code. ASM provides no
object-oriented programming support, therefore ASM fails this criteria for a
good language.
Portability – the extent to which inherent language features support the
transfer of a program from one hardware and/or software platform to another.
ASM is not portable from one type of computer to another. At best, it can be
portable to another computer within the same family of computers built by the
same manufacturer, therefore ASM fails this criteria for a good language.
Real-time support – the extent to which inherent language features support the
construction of real-time systems. ASM inherently supports a streamlined
version of code because it does not contain the inefficiencies of expression
found in HLLs. This is often assumed to mean that an assembly language
produces the best possible performance, but this is not the case. Today’s
compiler technology benefits both from current technology improvements as well
as from the experience of hundreds of language performance experts. Hence,
compiler optimizers can often do a better job of streamlining code than a
programmer can do using an assembly language [Lawlis 92]. ASM also is
inherently more difficult to use to accomplish streamlining, therefore ASM
fails this criteria for a good language.
Reliability – the extent to which inherent language features support the
construction of components that can be expected to perform their intended
functions in a satisfactory manner throughout the expected lifetime of the
product. ASM provides no inherent support for reliability, therefore ASM fails
this criteria for a good language.
Reusability – the extent to which inherent language features support the
adaptation of code for use in another application. ASM provides very little
opportunity for reuse, therefore ASM fails this criteria for a good language.
Safety – the extent to which inherent language features support the
construction of safety-critical systems, yielding systems that are
fault-tolerant, fail-safe, or robust in the face of systemic failures. ASM
provides no inherent support for safety-critical systems, although they are
often used in this domain, therefore ASM fails this criteria for a good
language.
Standardization – the extent to which the language definition has been
formally standardized (by recognized bodies such as ANSI and ISO) and the
extent to which it can be reasonably expected that this standard will be
followed in a language translator. ASM is not standardized, therefore ASM
fails this criteria for a good language.
Support for modern engineering methods – the extent to which inherent language
features support the expression of source code that enforces good software
engineering principles. ASM provides no inherent support for software
engineering principles, therefore ASM fails this criteria for a good language.
(Paraphrased from http://archive.adaic.com/docs/reports/lawlis/r.htm)
Now please continue to entertain me by telling us, in light of the above, what
is so good about ASM that everyone should abandon their good languages and go to
ASM? Haha! Please teach us how to use logical fallacies by telling us that all
the above is completely wrong, just because you say so. Haha!
wolfgang kern
I interrupt your little fight just for a moment ...
All your statements about the advantage of HLL sound
reasonable for all application-programmers who usually
don't need to know much about hardware-details and like
to have their source-code 'compile-able' on almost every
hardware and almost all Os.
But some people are needed to create the fast, short,
easy usable tools like hardware-links, drivers, libraries, etc.
And in this (smaller) programming area only a hardware-near
language will perform best, and this is direct coded ASM.
Just think of real-time video-acquisition or similar
'speed on limit' external-device handling.
You may point to the increasing speed of CPUs and you
may find a 'small' save on clock-cycles and memory irrelevant,
but demands increase faster and are always beyond the possible.
I think Randy's HLA is already more HLL than ASM,
even it can be used to create true, but restricted ASM-code.
(I haven't heard about a boot-able stand-alone HLA-Os yet.)
Ok then, the better shall win :)
__
wolfgang
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:5c2klv0msgbcgboaa...@4ax.com...
>
> >Perhaps, but you've long since ceased to be entertaining.
>
> You aren't paying attention as usual. It is *YOU* that is entertaining *ME*. You
> haven't ceasted to be entertaining, so again, thanks.
Well, I guess your sense of humor matches your knowledge of assembly language.
Not much there...
> >Now you just go on and on like a broken record.
>
> You are just plain stupid when it comes to knowing computer languages at a
> software engineering level.
There's the broken record part again.
At least I can make the *factual* claim that *I've* taught both
software engineering and computer language design. What was
it *you've* done, again?
>
> >Perhaps *you* find this entertaining, but few of the rest of us do.
> >We can only laugh at you making a fool out of yourself for so long.
> >Then it just starts to get pathetic after a while.
>
> One of the lastest entertaining thing you did was when asked for a regular
> expression engine in ASM, but you couldn't follow simple directions and provided
> a regular expression engine in C instead -- apparently because C is a more
> efficient language to post a regular expression engine for than ASM. We are
> still waiting for your more efficient regular expression engine in ASM...like
> that is ever going to happen! Haha!
Well, either you're incredibly stupid and didn't bother reading past the comments
in the code I posted or this is just a total troll trying to incite me. Either way, you
come off looking like a total fool and, as history indicates, any attempt to have
a meaningful discussion with you about the assembly code that *is* there is
worthless. You just want to argue and there is no point it in.
>
> But the most entertaining thing you have done to date, is your ludicrous claim
> and completely unsubstantiated claim that ASM is more efficient and more
> versatile, but have yet to provide any example of that as well. For pretending
> to be so informed, you sure don't act or talk like it. A typical software
> engineering course (your's excluded) will teach you, that in regards to the
> criteria for a good language...
>
Sorry, this is the wrong thread for that argument. We're talking about regular
expressions, remember?
> Its definition should be independent of any particular hardware or operating
> system. ASM is specific to a particular computer hardware
> architecture, therefore ASM fails this criteria for a good language.
As the assembly language code was roughly half the size of the C code,
why would you think that ASM fails as a criterion for being a good language
for implementing regular expressions? In other threads you argued that LOC
were a good indication of the applicability of the language. By your own
critierion, ASM is a better language than C for doing regular expression
work. I posted both C code and assembly code and the assembly code
was much smaller. Are you changing the criterion now?
>
> Its definition should be standardized, and compiler implementations should
> comply with this standard. Assembly languages cannot be standardized due to
> variations in processor architecture, therefore ASM fails this criteria for a
> good language.
What does that have to do with regular expressions, again?
Changing the subject line in the middle of the thread doesn't get you off the
hook. We're talking about regular expressions, right? If you want to play
the broken record argument some more, go back to the ASM vs. HLLs thread
and amuse yourself there.
>
> It should support software engineering technology, ie -- for those of you
> who don't know what that is yet, by discouraging or prohibiting poor
> practices, and promoting or supporting maintenance activities. ASM provides no
> support for software engineering technology. ASM does not work with
> abstractions, just machine-level specifics, therefore ASM fails this criteria
> for a good language.
I'm real tempted to expose your ignorance of assembly language,
but this is a regular expression thread, remember?
Troll, troll, troll...
[lots of B.S. having nothing to do with regular expressions snipped]
>
> Now please continue to entertain me by telling us, in light of the above, what
> is so good about ASM that everyone should abandon their good languages and go to
> ASM? Haha! Please teach us how to use logical fallacies by telling us that all
> the above is completely wrong, just because you say so. Haha!
>
Just going by your rules, son.
Of course, once it's demonstrated that ASM can play by those rules too
(e.g., writing regular expression parsers in assembly is easier than in C)
you want to change the rules. How many times have we seen that before?
Why waste time showing assembly can compete by your set of rules (or
show that other language can't compete either) when one knows the rules
will just change again. You aren't worth the effort.
Hmmm....
Cheers,
Randy Hyde
The_Sage
>Date written: Sat, 6 Sep 2003 23:31:32 +0200
>MsgID:<bjdmrn$6gs$1...@newsreader1.netway.at>
>Hi Sage!
>I interrupt your little fight just for a moment ...
Huh...wha?
>All your statements about the advantage of HLL sound
>reasonable for all application-programmers who usually
>don't need to know much about hardware-details and like
>to have their source-code 'compile-able' on almost every
>hardware and almost all Os.
>But some people are needed to create the fast, short,
>easy usable tools like hardware-links, drivers, libraries, etc.
What people would that be, besides amatuer hackers?
>And in this (smaller) programming area only a hardware-near
>language will perform best, and this is direct coded ASM.
A program written in C++ performs just as well as one in ASM, in fact, it is
more likely for a program written in C++ to perform better than one written in
ASM, since C++ supports proper programming technique, due to it's structure.
>Just think of real-time video-acquisition or similar
>'speed on limit' external-device handling.
And just how many applications in the world need that? One? Two? The reality is,
professional organizations write real-time video-acquisition in an HLL like C++,
and use the ASM keyword for the few critical sections where it is needed.
>You may point to the increasing speed of CPUs and you
>may find a 'small' save on clock-cycles and memory irrelevant,
>but demands increase faster and are always beyond the possible.
So you say without evidence.
>I think Randy's HLA is already more HLL than ASM,
>even it can be used to create true, but restricted ASM-code.
>(I haven't heard about a boot-able stand-alone HLA-Os yet.)
No it isn't, it is just another MASM.
>Ok then, the better shall win :)
The Sage
The_Sage
>MsgID:<Qmv6b.1473$PE6...@newsread3.news.pas.earthlink.net>
>>>Perhaps, but you've long since ceased to be entertaining.
>>You aren't paying attention as usual. It is *YOU* that is entertaining *ME*. You
>>haven't ceasted to be entertaining, so again, thanks.
>Well, I guess your sense of humor matches your knowledge of assembly language.
>Not much there...
Too bad you wouldn't know, and to prove that, just read on...
>>>Now you just go on and on like a broken record.
>>You are just plain stupid when it comes to knowing computer languages at a
>>software engineering level.
>There's the broken record part again.
Since that is the first time I ever said that, you are wrong (again).
>At least I can make the *factual* claim that *I've* taught both
>software engineering and computer language design. What was
>it *you've* done, again?
Proved you don't know what you are talking about, as I am about to do again...
>>But the most entertaining thing you have done to date, is your ludicrous claim
>>and completely unsubstantiated claim that ASM is more efficient and more
>>versatile, but have yet to provide any example of that as well. For pretending
>>to be so informed, you sure don't act or talk like it. A typical software
>>engineering course (your's excluded) will teach you, that in regards to the
>>criteria for a good language...
>Sorry, this is the wrong thread for that argument. We're talking about regular
>expressions, remember?
So I'm changing the subject to match your subject. You brought it up, idiot.
>> Its definition should be independent of any particular hardware or operating
>> system. ASM is specific to a particular computer hardware
>> architecture, therefore ASM fails this criteria for a good language.
>As the assembly language code was roughly half the size of the C code,
>why would you think that ASM fails as a criterion for being a good language
>for implementing regular expressions?
Here is a "hello world" program written in ASM:
.model small
.stack 100h
.data
hello_message db 'Hello, World!',0dh,0ah,'$'
.code
main proc
mov ax,@data
mov ds,ax
mov ah,9
mov dx,offset hello_message
int 21h
mov ax,4C00h
int 21h
main endp
end main
Now let's compare that to one written in C:
#include <iostream.h>
void main() {
cout << "Hello, World!" }
That is a typical example. Of course, it gets worse for more sophisticated
programs, especially for MZ and PE formats.
I proved you completely wrong again. If you were my teacher, I would have
flunked you.
>> Its definition should be standardized, and compiler implementations should
>> comply with this standard. Assembly languages cannot be standardized due to
>> variations in processor architecture, therefore ASM fails this criteria for a
>> good language.
>What does that have to do with regular expressions, again?
Having a little trouble keeping track of the subject after you've changed it
again? Guess you have no intelligent reply, so you dodge and evade, dodge and
evade.
>> It should support software engineering technology, ie -- for those of you
>> who don't know what that is yet, by discouraging or prohibiting poor
>> practices, and promoting or supporting maintenance activities. ASM provides no
>> support for software engineering technology. ASM does not work with
>> abstractions, just machine-level specifics, therefore ASM fails this criteria
>> for a good language.
>I'm real tempted to expose your ignorance of assembly language,
Oh I'm so scared of your stupid ass. Please don't embarass me with more of your
non-existnent self-proclaimed incredible knowledge.
>>Now please continue to entertain me by telling us, in light of the above, what
>>is so good about ASM that everyone should abandon their good languages and go to
>>ASM? Haha! Please teach us how to use logical fallacies by telling us that all
>>the above is completely wrong, just because you say so. Haha!
>Just going by your rules, son.
You are just going by your own rules, which is called "the coward's way out".
<Snipped rest of thread that nothing to do with regular expression engine in
ASM>
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:g5bllv8a418lp32e6...@4ax.com...
>
> No it isn't, it is just another MASM.
>
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:bebllv8dmrn1h8drm...@4ax.com...
> >Just going by your rules, son.
>
> You are just going by your own rules, which is called "the coward's way out".
>
> <Snipped rest of thread that nothing to do with regular expression engine in
> ASM>
>
Well, I tell you what.
I'll call your bluff.
Take each and every one of those points you made in your post,
turn them into separate posts (one post per point), and show (i.e., *prove*)
that C/C++ supports that feature of a programming language and *also* prove
that assembly language fails to meet that feature.
You're the one that brought all those points up, so it's up to you to prove
that C/C++ fulfills those points while assembly fails.
And I *only* want to see one point per thread. You have a long history
of changing subjects when it's clear you've painted yourself into a corner.
By sticking to one subject per thread, we'll disallow such a cop-out.
So if you're so sure you can defend yourself, have at it :-)
What? You're not willing to put your research where your mouth is?
Oh well.
Cheers,
Randy Hyde
P.S.
BTW, the "hello world" program in assembly:
program HelloWorld;
#include( "stdlib.hhf" )
begin HelloWorld;
stdout.put( "Hello World" nl );
end HelloWorld;
Doesn't look too different from that C example you gave.
Betov
news:5c2klv0msgbcgboaa...@4ax.com:
>>Reply to article by: "Randall Hyde" <rand...@earthlink.net>
>>Date written: Sat, 06 Sep 2003 04:25:36 GMT
>>MsgID:<4ld6b.789$PE6...@newsread3.news.pas.earthlink.net>
> [...]
(Master Pdf does not need of your help for falling flat on his face.
He does this pretty well by himself, every day, with HLA).
> [...]
> A typical software engineering course [...] will teach you
> [...]
> Its definition should be independent of any particular hardware or
> operating system [...]
>
> Its definition should be standardized [...]
>
> It should support software engineering technology [...]
>
> It should effectively support the application domain(s) of interest.
> [...]
>
> It should support the required level of system reliability and
> safety. [...]
>
> Its compiler implementations should be commensurate with the current
> state of technology [...]
>
> Appropriate software engineering-based supporting tools and
> environments should be available. [...]
>
> Clarity of source code [...]
>
> Complexity management (architecture support) [...]
>
> Concurrency support [...]
>
> Distributed system support [...]
>
> Maintainability [...]
>
> Mixed language support [...]
>
> Object-oriented programming support [...]
>
> Portability [...]
>
> Real-time support [...]
>
> Reliability [...]
>
> Reusability [...]
>
> Safety [...]
>
> Standardization [...]
>
> Support for modern engineering methods [...]
If you go on refusing to shut up and go on refusing to go and spread your
stupidities somewhere else, at least, you could post your fanciful ideas one
by one:
* Thread 1: Portability is a must have.
* Thread 2: HLLs "software engineering technology" is great.
* Thread 3: HLLs "the application domain(s)" is great.
* Thread 4: C++ is readable.
* Thread 5: OOP is impossible in Asm.
* Thread 6: Asm Standardization does not exist.
* ...
How do expect someone to answer to all of this at once? Some points are
nothing but known facts (6). Some others are ideas of a mentaly deseased
person (1). Some others simply show that you understand nothing at
programming (2 / 3 / 5), and/or did not even took a look at the existing
Assemblers.
So, if you like to make yourself ridiculous each day, please go on this
splitted way. Not addressing Master Pdf would also be prefered by guys like
me (no, i am _not_ 100% isolated in my views...), in order to not have the
pain of answering you _beside_ Master Pdf publicity. (Having to agrea with
him on something, while he is here for nothing but selling his shit and for
his personal glory, at any cost, -even at the cost of saying that i am
"right on"-, would be a real pain for me).
Betov.
< http://betov.free.fr/RosAsm.html >
wolfgang kern
Hi Sage!
| >I interrupt your little fight just for a moment ...
| Huh...wha?
| >But some people are needed to create the fast, short,
| >easy usable tools like hardware-links, drivers, libraries, etc.
Those who design hardware "and" write the proper drivers for it,
to not let HLL-compiled stuff slow the hardware down.
| >And in this (smaller) programming area only a hardware-near
| >language will perform best, and this is direct coded ASM.
| A program written in C++ performs just as well as one in ASM, in fact, it is
| more likely for a program written in C++ to perform better than one written in
| ASM, since C++ supports proper programming technique, due to it's structure.
You sure do not mean HLL-compiled code is faster, shorter than ASM-code ?!
| >Just think of real-time video-acquisition or similar
| >'speed on limit' external-device handling.
| And just how many applications in the world need that? One? Two?
| The reality is, professional organizations write real-time
| video-acquisition in an HLL like C++, and use the ASM keyword
| for the few critical sections where it is needed.
Yes. Only a few applications will need top-speed.
And correct, only the time-critical sections need direct coding.
But wouldn't it be nice if all code would be speed- and size-
optimised to run as fast as possible?
I really do hate the frequently frozen sandglass on my win98 screen...
| >You may point to the increasing speed of CPUs and you
| >may find a 'small' save on clock-cycles and memory irrelevant,
| >but demands increase faster and are always beyond the possible.
| So you say without evidence.
Seems you know more about than my experience thought me.
Good luck on your way then.
__
wolfgang
Randall Hyde
"Betov" <be...@free.fr> wrote in message news:Xns93EF76D6EF...@213.228.0.138...
>
> So, if you like to make yourself ridiculous each day, please go on this
> splitted way. Not addressing Master Pdf would also be prefered by guys like
> me (no, i am _not_ 100% isolated in my views...), in order to not have the
> pain of answering you _beside_ Master Pdf publicity. (Having to agrea with
> him on something, while he is here for nothing but selling his shit and for
> his personal glory, at any cost, -even at the cost of saying that i am
> "right on"-, would be a real pain for me).
Hi Rene.
Though we often fight about our views on assembly language,
I do want to complement you on your post about WAV->MIDI
translation in the MASM Forum. When you enter a discussion from
a position of strength and knowledge, and you're not trying to tear
people down in the process, you actually come across as a nice
and knowledgable person.
Cheers,
Randy Hyde
Randall Hyde
"wolfgang kern" <now...@nevernet.at> wrote in message news:bjffi4$3co$3...@newsreader1.netway.at...
>
> | So you say without evidence.
>
> Seems you know more about than my experience thought me.
> Good luck on your way then.
Oh, it gets even better. Wait until you make the same type of assumptions
about *his* knowledge. It's fine and dandy for him to make assumptions about
other people's knowledge and experience, but when you make the same sort
of assumption about him - well, be prepared for a long string of explicatives :-)
We'll see if it has the nerve to break out each of his points into separate posts
and defend each one individually. If history is any indication, expect a punt
real soon now. "The_sag" has a habit of posting a bunch of unsupported
nonsense without any intention of defense just to get emotions stirred up.
It used to be fun watching himself make a total fool out of himself. But after
a while it gets awfully boring listing to the same tired arguments over and
over again that never lead anywhere. Well, now he has a chance to make
good on his desire for an "intelligent debate". Let's see if that's what he really
wants as opposed to a forum where he gets to boost his ego by calling
people names all the time.
Cheers,
Randy Hyde
The_Sage
>MsgID:<3Zz6b.2226$Yt....@newsread4.news.pas.earthlink.net>
>>You are just going by your own rules, which is called "the coward's way out".
>><Snipped rest of thread that nothing to do with regular expression engine in
>>ASM>
>Well, I tell you what.
>I'll call your bluff.
I never made any bluff. Do you need a dictionary?
>Take each and every one of those points you made in your post,
>turn them into separate posts (one post per point), and show (i.e., *prove*)
>that C/C++ supports that feature of a programming language and *also* prove
>that assembly language fails to meet that feature.
I will when you post the regular expression engine in ASM that does the same
exact thing your post for the C code would do.
>You're the one that brought all those points up, so it's up to you to prove
>that C/C++ fulfills those points while assembly fails.
The proof is in the link I gave. It defines all the terms for you, you just have
to learn to read.
>BTW, the "hello world" program in assembly:
>program HelloWorld;
>#include( "stdlib.hhf" )
>begin HelloWorld;
> stdout.put( "Hello World" nl );
>end HelloWorld;
>Doesn't look too different from that C example you gave.
BTW, unlike the "C example", you are hiding the rest of the code in the
"stdlib.hhf". Yet another coward's way out! There is no hidden code in the "C
example".
And it demonstrates how little you know. I made a typo: It wasn't a C program,
it was a C++. The "cout" is a C++ keyword only. How come you nor anyone else
could catch that? Can't you get anything right?
But yet once again, you take the coward's way out, hence the reason we are still
waiting for your regular expression engine in ASM.
The_Sage
>MsgID:<MRz6b.2221$Yt....@newsread4.news.pas.earthlink.net>
>>No it isn't, it is just another MASM.
>Why, just a few short messages ago you were calling it "C". :-)
No I wasn't. Learn to pay attention for once.
The_Sage
>MsgID:<bjffi4$3co$3...@newsreader1.netway.at>
>|>I interrupt your little fight just for a moment ...
>|Huh...wha?
>Oh, not recognised? :)
>|>But some people are needed to create the fast, short,
>|>easy usable tools like hardware-links, drivers, libraries, etc.
>|What people would that be, besides amateur hackers?
>Those who design hardware "and" write the proper drivers for it,
>to not let HLL-compiled stuff slow the hardware down.
In other words, you are making this up as you go along. You *imagine* all these
hundreds of thousands of programmers, all over the world, who have nothing
better to do all day than write hardware-links, drivers, libraries, etc.
Hardware programming is the exception, not the rule and C++ can handle the
critical sections without having to do the entire thing in ASM.
>|>And in this (smaller) programming area only a hardware-near
>|>language will perform best, and this is direct coded ASM.
>|A program written in C++ performs just as well as one in ASM, in fact, it is
>|more likely for a program written in C++ to perform better than one written in
>|ASM, since C++ supports proper programming technique, due to it's structure.
>You sure do not mean HLL-compiled code is faster, shorter than ASM-code ?!
How much "faster" or "shorter" do you mean?
And what I actually said was, it *performs* just as well -- and that is all the
customer cares about: does it perform the same? And the answer is "Yes". And why
should the customer pay two to three times as much for an ASM created
application when a finely-tuned C++ program will perform the same for less?
The vast majority of my applications are not drivers and hardware links, they
are word processors, internet browsers, email, etc. Drivers and hardware links
are the exception, not the rule, and they can easily be done in C++ with the
critical sections done in ASM when needed (most of the time it isn't needed).
>|>Just think of real-time video-acquisition or similar
>|>'speed on limit' external-device handling.
>|And just how many applications in the world need that? One? Two?
>|The reality is, professional organizations write real-time
>|video-acquisition in an HLL like C++, and use the ASM keyword
>|for the few critical sections where it is needed.
>Yes. Only a few applications will need top-speed.
>And correct, only the time-critical sections need direct coding.
Which is just a *small* portion of the overall code.
>But wouldn't it be nice if all code would be speed- and size-
>optimised to run as fast as possible?
Who cares?
>I really do hate the frequently frozen sandglass on my win98 screen...
That is a Bill Gates problem, not an example of language efficiency.
>|>You may point to the increasing speed of CPUs and you
>|>may find a 'small' save on clock-cycles and memory irrelevant,
>|>but demands increase faster and are always beyond the possible.
>|So you say without evidence.
>Seems you know more about than my experience thought me.
>Good luck on your way then.
UFO believers use that same line all the time. Experience without evidence is
just another word for storytelling. Experience tells us nothing factual, as
three different people can physically experience the same exact thing, yet
report three completely different experiences.
sinewave
> Not addressing Master Pdf would also be prefered by guys like me
what? you're still hiding from Randall?
> while he is here for nothing but selling his shit and for his
> personal glory, at any cost
how about putting your "personal glory" aside and fix the RosAsm bug i
posted.
regards,
phil
C
An interesting article
[ http://archive.adaic.com/docs/reports/lawlis/ ],
which covers many of the features a good HLL should have
-- a must read for evey language designer. I shall ignore
your obvious bias in you paraphrasing of the article in
question and look at the article itself, because wording
such as yours in groups specialising in assembler (such as
this) is little more than flame bait.
The more neutral tone of the article does result in a similar
conclusion to yours -- ie. that an assembler is deficient
when used as a general programming language -- but we must
not ignore the fact that several of the other HLLs (most
notibaly COBOL) fairs worse than assembly in many aspects.
Also as the article is posted on an Ada site, so it is
unsurprising that Ada does well for the catorgories selected
in making the comparason.
Now, I would never propose pure assembly as a general
purpose programming tool -- though it is possible to write
large impressive applications (such as Optlink or RosAsm) in
assembler exclusively. This application normally results
in more effort than would a HLL more suited to the domain;
ie. that the advantages gained in the efficiency of the
application binary are commonly insignificant compared to
the effort it requires to programme. Why do you think we
are all impressed when we see an application written in pure
assembly? It is because we know how much effort that takes!
Going back to the point of COBOL doing badly this points
to assembly not always being worse than a HLL, and therefore
would infer that assembly (in limited domains) is superiour
to a given HLL in that domain. As a result, if you are likely
to be dealing with those domains where assembler is profitable
then learning assembly is highly useful.
Now to address the article itself ...
[points enumerated for future reference]
[heavy snipping ahead]
(1)
> Its definition should be independent of any particular
> hardware or operating system.
This is a limitation inherant in assembly language itself,
by getting maximum control over the processor and therefore
maximum speed you loose portability (Java goes the other way:
maximum portability at the expence of speed). The tradeoff
in gaining speed is that assemblers become hardware dependent;
though dependency on the operating system can be avoided
by using constructions such as the UCR standard library.
(2)
> Its definition should be standardized, and compiler
> implementations should comply with this standard.
The failure, on assembly's part here, is due to an error
in considering assembly as a language rather than as a
paradigm, by the very nature of the paradigm it can not
be standardised aross processors and this defeats
standardising assembly across all architectures.
However there are many similarities between different
processors so the overall syntax and semantics could
easily be standardised though the opcodes would have to
vary.
(3)
> It should support software engineering technology,
For the article, 'software engineering technology' seems to
mean object oriented and/or structured programming. While a
specific assembler may not support such constructs, many
assemblers do. Most modern assemblers now have support for
structured programming (either inbuilt of via a standard set
of macros) and a select few have gained object oriented
capabilities -- a trend which may well continue.
The problem here is that assembly is more of a paradigm than a
specific language; therefore we should be comparing assembly
as a paradigm rather than a language. Saying 'a event driven
paradigm is useless as it is not an object oriented paradigm'
is similar to the comparason being made here.
(4)
> It should effectively support the application domain(s) of
> interest.
Surely low level systems programming is an application domain?
That is what assembly supports and what many assemblers are
targeted towards, this being, in my opinion the chief strength
of assembler.
(5)
> It should support the required level of system reliability
> and safety.
This is something I know of now assembler with -- though there
is no reason that something like 'design by contract', invariants
or asserts could not be added, though bounds checking would be
more difficult.
I must also not here that most HLLs do not support such features
notibly C and C++, the two most widely used. Also this is
normally an issue with the design of the software programme
itself and the algorthms implemented within rather than the
language used. Even languages designed with fail safty in mind
(such as Ada) have had some spectacular cock-ups -- Arian-5 for
starters.
(6)
> Its compiler implementations should be commensurate with the
> current state of technology.
The assembly paradigm works by attempting to faithfull map the
instruction sequences understood by the processor. Therefore
an assembler only really needs to support new instructions and
processor modes.
Really assemblers are now support structured programming and
a few even include support for the latest fad -- object oriented
programming.
(7)
> Appropriate software engineering-based supporting tools and
> environments should be available.
I can not really comment here as I cannot stand IDEs and CASE
tools, anything more than keyword highlighting gets on my nerves,
probably due to its lack of support for keyword shortcuts.
Though I must point out Betov's RosAsm package, which is clearly
not a low level tool -- the only pity is that there are not more
committed programmers building similar applications.
This is really a Catch-22 style situation; ie. that as assembler
is not seen as a well used tool applications are not made and
as applications are not made assembler is more difficult to
learn and therefore less used.
(8)
> Clarity of source code
This criteria is _very_ subjective. I frequently find assembler
more expressive than many HLL sources and normally far better
commented. Though the algorithm can get lost in the details,
the statements themselves are simple and easily understood.
(9)
> Complexity management
Many HLLs (such as C) fail to do better than assembler in this
field.
(10)
> Concurrency support
Almost no HLLs support this (Ada and Java being exceptions).
Assembler at least allows the hardware to be accessed at such
a level to allow the primitives to be built, something which
is not really possible in a HLL.
(11)
> Distributed system support
Again nearly all HLLs compared fail here as well, though HLLs
specifically aimed at this domain (eg. Occam) have not been
analysed.
(12)
> Maintainability
This is not really a language feature but a feature of how the
language is used. It is possible to write unmaintailable code
in any language, in this respect assembler has an advantage as
it is what-you-see-is-what-you-get, ie. that the compiler is
not doing things behind your back which could easily result in
the intentions of the code being missread.
(12)
> Mixed language support
Here I think the article got things totally wrong. Not only
do assemblers such as MASM provide such constructs as the
'invoke' and 'proto' keywords (together with related syntax),
but assembler can be easily attached to any language just by
knowing its calling convention. With a HLL, you either have
support or not, with assembler even if you have no direct
support, a few 'equ's will give a fairly reasonable
approximation.
(This makes me think the article is comparing a pure
assembler, similar to my SAss, rather than a more modern
assembler. If we are to give the article the benifit of the
doubt, we must assume that an average is been taken which is
weighting towards older assemblers or those intended as
compiler backends simply because these assemblers are more
common.)
(13)
> Object-oriented programming support
(Partly discussed in (3).)
This is a you-have-it-or-not feature and while many assemblers
do indeed lack support, several notible exceptions have included
this feature.
(14)
> Portability
This has been addressed in points (1) and (2) and is really
a rephrasing of the criteria specified there.
(15)
> Real-time support
[Note that article gives a 50% rating for assembler here,
that is the second highest out of the languages discussed
-- Java gets 0%.]
Also the issue of compiler optimisers producing better code
than programmers is mearly due to the level of skill of the
pragrammer -- this has been done to death in other threads.
(16)
> Reliability
This is very similar to issue (5) combined with a little of (8).
Again most HLLs fail to provide this support.
(17)
> Reusability
> [...] ASM provides very little opportunity for reuse,
I believe the UCR standard library disproves your point here.
Most assembler coders with and level of experience have a
collection of snippets which are frequently reused. Actually
assembler coding results in a great deal of reuse, just that
reuse thens to be in form of cut-and-paste rather than the
more formal methods found in object oriented programming and
contructs of that ilk.
(18)
> Safety
Repeat of (5).
(19)
> Standardization
Repeat of (2).
(20)
> Support for modern engineering methods ?
Repeat of (3), related (13).
> Please teach us how to use logical fallacies by telling
> us that all the above is completely wrong, just because
> you say so.
Ooo?, do we get to play the 'spot the logical fallacy'
game -- that was such fun a few days ago.
C
2003/9/7
Randall Hyde
>
> So, if you like to make yourself ridiculous each day, please go on this
> splitted way. Not addressing Master Pdf would also be prefered by guys like
> me (no, i am _not_ 100% isolated in my views...), in order to not have the
> pain of answering you _beside_ Master Pdf publicity. (Having to agrea with
> him on something, while he is here for nothing but selling his shit and for
> his personal glory, at any cost, -even at the cost of saying that i am
> "right on"-, would be a real pain for me).
Hey, you think it's bad having me agree with you. Just think about
this one - just like you "The_Sage" thinks that HLA is "just like MASM".
Just like you, "The_Sage" thinks that assembly programmers write all
their code from scratch without using libraries, objects, abstractions,
data types, and so on.
Unlike you, I've never seen anything of value that "The_Sage" has
ever done. At least I have a *small* amount of respect for you as
you've actually written an assembler. Personally, of course, I feel
that your assembler embodies much of what "The_Sage" feels is
wrong with assembly language, but at least you've *created*
something. It doesn't balance your destructive tendencies much,
but at least that's better than the "pure destruction" we get from
"He Who Is Too Embarassed To Use His Real Name"...
But it will be interesting to see if "The_Sage" is bold enough to
actually do a true debate on this subject, or if he's content to
stir up some flames and then run away with his tail between his
legs. My guess is that we won't be seeing those new posts that
I've challenged him to create.
Should they appear, however, rest assured that we won't be
seeing eye to eye on a lot of things. I don't particularly disagree
with the basic premise of what "The_Sage" is saying. I simply
disagree with the fact that he is trying to pass off faulty research,
or his misinterpretation of that research, as absolute fact.
Software Engineering is a "soft" science and you cannot make
the sweeping generalizations and absolute statements that
"The_Sage" makes (unless, of course, your whole intent is
simply to stir up a hornet's nest, which is pretty much all he
ever tries to do).
Cheers,
Randy Hyde
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:rpqmlv8i3ikk5bgqg...@4ax.com...
>
> I will when you post the regular expression engine in ASM that does the same
> exact thing your post for the C code would do.
>
thing as the C program. In fact, it does more. The code code only processes
string coming in from the standard input (i.e., it's a filter program) whereas the
HLA program gets a filename from the command line and processes the lines
of text in that file. Other than that, the two programs are fairly equivalent within
the limitations of a quick and dirty translation. It reads the same input file
and produces the same output file (e.g., the "function point analysis" of the
two programs is going to be very similar, sans the difference in file I/O).
As for "screaming assembly performance" I will be the first to admit that
calls to generalized pattern matching routines are not going to run as fast
as a hand-coded algorithm written to specifically process phone numbers.
But the calls to the HLA Standard Library routines will probably outperform
the regex library routines the C code calls by a fair amount - there is no
"regular expression engine" running in the HLA code. Instead, the pattern
matching routines match the pattern (phone numbers) directly (ala SNOBOL4)
rather than running an interpreter on a string containing a regular expression.
Perhaps you'll claim this isn't fair -- that the assembly code should have to
do the same work. But if you go to the "Great Compiler Shoot-out" link
you provided a while back, you'll find that the author of that site didn't have
any problems doing things differently in languages like Icon, Perl, Awk, etc.
I would also argue that HLA's approach is quite a bit more flexible - it supports
matching context-free patterns as well as regular expressions, something the
C code cannot easily do. Also, the HLA pattern matching routines fully support
backtracking and both eager and lazy matching. Something the C routines
probably don't provide. All in all, the HLA approach is far more flexible,
as well as being written in assembly code with fewer lines of source code
(and running faster).
Now, one advantage of the C code is that it interprets a string at run-time,
therefore, it's possible to allow the user to enter a regular expression at run-time
and have the program process that. Not something that's as easy to do with the
HLA code. OTOH, neither he original "Great Computer Language Shoot-out"
nor the original poster had this requirement. OTOH, faced with the prospect
of writing such a regex engine, the pattern matching and character set facilities
in HLA would make this far less work to achieve than the corresponding C code.
Cheers,
Randy Hyde
One other comment worth mentioning: the HLA pattern matching routines
are a supplied component of the HLA Standard Library. The regular expression
matching function used in the "Great Computer..." C code is not a part of the
C (or C++) Standard Library. Therefore, it's not immediately available to most
C/C++ programmers who might want to use it.
The_Sage
>Date written: 7 Sep 2003 15:21:38 -0700
>MsgID:<33d97ee5.03090...@posting.google.com>
> which covers many of the features a good HLL should have
>-- a must read for evey language designer.
Just more info.
>The more neutral tone of the article does result in a similar
>conclusion to yours -- ie. that an assembler is deficient
>when used as a general programming language -- but we must
>not ignore the fact that several of the other HLLs (most
>notibaly COBOL) fairs worse than assembly in many aspects.
But we can ignore it, since the conclusion will still be the same: That ASM is a
deficient language. All that matters is the conclusion -- that ASM is a
deficient language -- since that was the claim.
>Also as the article is posted on an Ada site, so it is
>unsurprising that Ada does well for the catorgories selected
>in making the comparason.
You are illogically assuming that just because it is on an ADA site, it
therefore must be wrong. Maybe ADA is the ultimate language, but you will need
something a little more substantial than "it is on an ADA site therefore it
can't be right". I'm not sure what the ultimate language is or if it even could
exist, but for a general all around general purpose language, it seems as though
a non-MS Visual C++ is the most anyone could ask for.
>Now, I would never propose pure assembly as a general
>purpose programming tool -- though it is possible to write
>large impressive applications (such as Optlink or RosAsm) in
>assembler exclusively.
What? No MASM?
>This application normally results
>in more effort than would a HLL more suited to the domain;
>ie. that the advantages gained in the efficiency of the
>application binary are commonly insignificant compared to
>the effort it requires to programme. Why do you think we
>are all impressed when we see an application written in pure
>assembly? It is because we know how much effort that takes!
I agree except for one caveat: most applications written in ASM are not well
written. For example, all object oriented implementations using ASM. I have yet
to see it done correctly, much less with elegance and intelligence (I have yet
to write one myself, although I have a template of one). But when an ASM program
is good, it is really really great.
>Going back to the point of COBOL doing badly this points
>to assembly not always being worse than a HLL, and therefore
>would infer that assembly (in limited domains) is superiour
>to a given HLL in that domain. As a result, if you are likely
>to be dealing with those domains where assembler is profitable
>then learning assembly is highly useful.
Well it isn't that HLL is worse than ASM, it is the *efficiency* where an HLL is
always better than ASM. BASIC is a weak language but it certainly is a more
efficient language than ASM.
>(1)
>> Its definition should be independent of any particular
>> hardware or operating system.
>This is a limitation inherant in assembly language itself,
>by getting maximum control over the processor and therefore
>maximum speed you loose portability (Java goes the other way:
>maximum portability at the expence of speed).
Don't confuse the language with the machine. The langauge is great, the machine
is slow. If Intel comes out with their processor that supports JAVA, speed will
no longer be an issue with Intel based hardware, and since the vast majority of
users out there are Intel users, it won't matter much that it is slow anywhere
else.
>The tradeoff
>in gaining speed is that assemblers become hardware dependent;
>though dependency on the operating system can be avoided
>by using constructions such as the UCR standard library.
It is possible but is it worth the effort? So far the worldwide consensus has
been "No". The RISC architecture is much different from the CISC architecture so
there is no one on one correspondance between them.
>(2)
>> Its definition should be standardized, and compiler
>> implementations should comply with this standard.
>The failure, on assembly's part here, is due to an error
>in considering assembly as a language rather than as a
>paradigm, by the very nature of the paradigm it can not
>be standardised aross processors and this defeats
>standardising assembly across all architectures.
All languages are therefore built upon a paradigm, so that is no excuse.
>However there are many similarities between different
>processors so the overall syntax and semantics could
>easily be standardised though the opcodes would have to
>vary.
A RISC can have 32 registers, so how can you standardize a "mov ax,bx" to "mov
ax,zx"? When I think of standardization, I think of things like scope. The
syntax for most ASM compilers isn't too logical either, since "mov ax,bx" means
"mov the contents of bx to ax". Why not say "move bx to ax"? Why make it all
cryptic with three letter acronyms and polish grammer?
>(3)
>> It should support software engineering technology,
>For the article, 'software engineering technology' seems to
>mean object oriented and/or structured programming. While a
>specific assembler may not support such constructs, many
>assemblers do. Most modern assemblers now have support for
>structured programming (either inbuilt of via a standard set
>of macros)
True, although the support is very limited -- ASM cannot inherently support
nested for or while loops for example.
>and a select few have gained object oriented
>capabilities -- a trend which may well continue.
There is no assembler can do *true* object oriented programming.
>The problem here is that assembly is more of a paradigm than a
>specific language; therefore we should be comparing assembly
>as a paradigm rather than a language. Saying 'a event driven
>paradigm is useless as it is not an object oriented paradigm'
>is similar to the comparason being made here.
ASM is most definitely a language. Do not redefine terms in defense of ASM, it
is a computer language, plain and simple. And since *all* HLLs are based on
machine code, it proves that anything an HLL can do, ASM *could* do it if
someone only knew how to copy the HLL to ASM.
>(4)
>> It should effectively support the application domain(s) of
>> interest.
>Surely low level systems programming is an application domain?
>That is what assembly supports and what many assemblers are
>targeted towards, this being, in my opinion the chief strength
>of assembler.
The difference is that ASM does not *inherently* support any domain. If you want
to program for a specific domain, you must know all the internals of how to do
that for ASM, whereas for a HLL you just merely need to know how to pass
parameters to a function specifically built-in to handle that domain.
>(5)
>> It should support the required level of system reliability
>> and safety.
>This is something I know of now assembler with -- though there
>is no reason that something like 'design by contract', invariants
>or asserts could not be added, though bounds checking would be
>more difficult.
>I must also not here that most HLLs do not support such features
>notibly C and C++, the two most widely used.
I wonder if that is why ADA gets such high marks?
>Also this is
>normally an issue with the design of the software programme
>itself and the algorthms implemented within rather than the
>language used. Even languages designed with fail safty in mind
>(such as Ada) have had some spectacular cock-ups -- Arian-5 for
>starters.
Well the issue isn't if a perfect language exists, just that is relatively
reliable and safe, not absolutely reliable and safe. C and C++ are much easier
to debug and test for memory leaks, etc, as well as the ability to find tools
that support profiling of your application. All of that adds up to a more robust
application in a much shorter time than for ASM. It is just too easy to make
mistakes in ASM that won't be caught until it has been put to use for years.
>(6)
>> Its compiler implementations should be commensurate with the
>> current state of technology.
>The assembly paradigm works by attempting to faithfull map the
>instruction sequences understood by the processor. Therefore
>an assembler only really needs to support new instructions and
>processor modes.
>Really assemblers are now support structured programming and
>a few even include support for the latest fad -- object oriented
>programming.
In other words, ASM cannot support current state of the art technology. No
matter what the reason, it isn't really a language or it is a 'paradigm' or it
wasn't designed for that, the end result is that it cannot support current state
of the art technology while many HLLs can.
>(7)
>> Appropriate software engineering-based supporting tools and
>> environments should be available.
>I can not really comment here as I cannot stand IDEs and CASE
>tools, anything more than keyword highlighting gets on my nerves,
>probably due to its lack of support for keyword shortcuts.
>Though I must point out Betov's RosAsm package, which is clearly
>not a low level tool -- the only pity is that there are not more
>committed programmers building similar applications.
There are hundreds of such programs out there: SPEW, BASM, GASM, NASM, GoASM,
TMA macro assembler, EASM, TALC...and that is just the ones that have source
code included!
>This is really a Catch-22 style situation; ie. that as assembler
>is not seen as a well used tool applications are not made and
>as applications are not made assembler is more difficult to
>learn and therefore less used.
What about profilers? What about debuggers? What good is an assembler if you
cannot debug or profile it in real time?
>(8)
>> Clarity of source code
>This criteria is _very_ subjective. I frequently find assembler
>more expressive than many HLL sources and normally far better
>commented. Though the algorithm can get lost in the details,
>the statements themselves are simple and easily understood.
"Expressive" is another *very* subjective term, is it not? Clarity refers to the
ability to read code without having to refer to a manual. For example, if you
have never seen an ASM program in your life, it is not immediately intuitive
that "mov ax,bx" means "move the contents of register bx to register ax". Most
beginners frequently misinterprte "mov ax,bx" to mean "move the contents of
regist ax to register bx". BASIC has the most clarity of all languages but I
still wouldn't want to use it for certain applications.
>(9)
>> Complexity management
>Many HLLs (such as C) fail to do better than assembler in this
>field.
ASM basically has no complexity management support, so how is that possible?
Does ASM support different processors? No. Does it support classes? No. Does it
support built-in functions like Boyer-Mayer string searching? No.
>(10)
>> Concurrency support
>Almost no HLLs support this (Ada and Java being exceptions).
Intel's C Itanium compiler supports this too.
>Assembler at least allows the hardware to be accessed at such
>a level to allow the primitives to be built, something which
>is not really possible in a HLL.
It isn't *supported*, it is only *available* if and only if you know how to do
it (which most programmers do not).
>(11)
>> Distributed system support
>Again nearly all HLLs compared fail here as well, though HLLs
>specifically aimed at this domain (eg. Occam) have not been
>analysed.
In other words, ASM still fails.
>(12)
>> Maintainability
>This is not really a language feature but a feature of how the
>language is used. It is possible to write unmaintailable code
>in any language, in this respect assembler has an advantage as
>it is what-you-see-is-what-you-get, ie. that the compiler is
>not doing things behind your back which could easily result in
>the intentions of the code being missread.
The point being that at least it is possible to write maintainable code in many
HLLs whereas that is not an option in languages which don't have much clarity,
such as ASM. Maintainability refers to the ability for anyone to step in and
either continue where the last person left off, or modify what someone else
wrote. If the code is relatively unmaintainable, then it might take weeks to
analyze the code before it could be continued or modified. ASM is like that and
C is not.
>(12)
>> Mixed language support
>Here I think the article got things totally wrong. Not only
>do assemblers such as MASM provide such constructs as the
>'invoke' and 'proto' keywords (together with related syntax),
>but assembler can be easily attached to any language just by
>knowing its calling convention. With a HLL, you either have
>support or not, with assembler even if you have no direct
>support, a few 'equ's will give a fairly reasonable
>approximation.
>(This makes me think the article is comparing a pure
>assembler, similar to my SAss, rather than a more modern
>assembler. If we are to give the article the benifit of the
>doubt, we must assume that an average is been taken which is
>weighting towards older assemblers or those intended as
>compiler backends simply because these assemblers are more
>common.)
You are probably right on for this one.
>(13)
>> Object-oriented programming support
>(Partly discussed in (3).)
>This is a you-have-it-or-not feature and while many assemblers
>do indeed lack support, several notible exceptions have included
>this feature.
I have yet to find more than two ASM programmers who even has a clue what OOP is
about. For example, a requirement for an object is the ability to destroy it,
yet not one of the alleged OOP assemblers has a DESTRUCTOR() function in their
"CLASS" (which brings up another point: a CLASS is not simply just a "structure
with pointers to data and code" -- it is more than just that, although that is a
start).
>(14)
>> Portability
>This has been addressed in points (1) and (2) and is really
>a rephrasing of the criteria specified there.
That does not change the fact that ASM is not portable. JAVA is.
>(15)
>> Real-time support
>[Note that article gives a 50% rating for assembler here,
>that is the second highest out of the languages discussed
>-- Java gets 0%.]
LOL! I would definitely have to disagree with that. I mean ASM has no profiler
or debugger (at least most do not) and JAVA does.
>Also the issue of compiler optimisers producing better code
>than programmers is mearly due to the level of skill of the
>pragrammer -- this has been done to death in other threads.
A simple analogy will suffice here: While an experienced driver could outperform
the average Joe driver in a hi-powered sports car, put a little traction control
on that hi-power sports car, and the difference disappears. ASM is that
hi-powered sports car and HLL is that traction control. HLL is the great
equalizer and can turn average programmers into great programmers (relatively
speaking).
>(16)
>> Reliability
>This is very similar to issue (5) combined with a little of (8).
>Again most HLLs fail to provide this support.
But the point being that at least some HLLs provide this support whereas ASM
does not, hence ASM fails.
>(17)
>> Reusability
>> [...] ASM provides very little opportunity for reuse,
>I believe the UCR standard library disproves your point here.
And how many ASM programmers use UCR? Why not?
>Most assembler coders with and level of experience have a
>collection of snippets which are frequently reused. Actually
>assembler coding results in a great deal of reuse, just that
>reuse thens to be in form of cut-and-paste rather than the
>more formal methods found in object oriented programming and
>contructs of that ilk.
By your definition, all languages are reusable then.
>>Please teach us how to use logical fallacies by telling
>>us that all the above is completely wrong, just because
>>you say so.
>Ooo?, do we get to play the 'spot the logical fallacy'
>game -- that was such fun a few days ago.
Haha! If you want to. I was just trying to beat Randall to the punch, as that is
his usual response.
Mark I Manning IV
> You sure do not mean HLL-compiled code is faster, shorter than ASM-code
> ?!
actually any non trivial applicationm written in forth will be 50% the
size of the equiv assembler and hundreds of times smaller than the equiv c
(c++ will be WAY out there).
As an example go to isforth.clss.net and assemble my forth compiler
kernel. then edit the file isforth.f and comment out where it does fload
src/tui/tui.f - this is a curses like text user interface extension
adding text windowing etc. not the size of the extended compiler
executable (./isforth).
then recompile same with tui.f included. if my memory serves me right the
executable will be about 4k larger. I challenge the above c++ scripter to
write a complete `terminfo parser and text windowing system in 4k of code
(and assembler coder would also have difficulty).
Im cheating here a little, if you examine the sources to libncurses you
will see that it has a hell of alot of code dedicated to tweaking its
output for various terminal quirks and for doing tricks to prevent screen
scroll when writing to the bottom right character of the display - my code
doesnt do any of this (nor does it do sub windowing yet).
you can see the code in action by doing
./isforth -fload help/examples/window.f
what you see it doing there would be next to impossible using ncurses :)
wolfgang kern
"Mark I Manning IV" replied:
| > You sure do not mean HLL-compiled code is faster,
| > shorter than ASM-code ?!
| actually any non trivial applicationm written in forth will be 50% the
| size of the equiv assembler and hundreds of times smaller than the equiv c
| (c++ will be WAY out there).
Yes I know forth creates shorter code than library using, compiling ASM.
That's my reason to still write everything on a machine-code monitor.
| As an example go to isforth.clss.net and assemble my forth ...
Sorry I can't process 'source'-code of any type,
But if you can point to small exe-file produced by your forth,
I may try to reduce it's size and increment it's speed. ;)
__
wolfgang
wolfgang kern
Hi Randy!
| > | So you say without evidence.
| > Seems you know more about than my experience thought me.
| > Good luck on your way then.
| Oh, it gets even better.
| Wait until you make the same type of assumptions about *his* knowledge.
[...]
Yes, true.
I knew 'The Sage' in the past as a skilled programmer with a
large knowledge on a detail-level,
even rude and impolite, he often could help newbies best.
Something may have happened to him recently,
(perhaps divorced, pet died, cancer detected,
or anything similar frustrating)
if he were one of my employees, I'd send him on vacation
right now, just for the chance to find back to himself soon.
__
wolfgang
sinewave
are you saying Forth can create smaller EXEs than asm? because we will just
take your EXE, disassemble, and shave some bytes :p.
regards,
phil
sinewave
why not create an OOP asm? FWIW asm (like HLL) can call any function by
passing parameters [push/call or mov/call]: the win32 api is C-based. low
resource asm programs can use KERNEL32 "C" functions like lstrcpyn.
regards,
phil
C
> >
> > You sure do not mean HLL-compiled code is faster, shorter
> > than ASM-code ?!
>
> actually any non trivial applicationm written in forth will be
> 50% the size of the equiv assembler and hundreds of times smaller
> than the equiv c (c++ will be WAY out there).
Actually I have always considered Forth to be a form of emulated
assembler. Its nature is _very_ similar to stack architectures.
(Which, incidentally, in terms of code size, are normally the most
efficient processors.)
It would not be a large stretch of the imagination to develop a
processor hardware which could read the same bytecode (wordcode?)
that the Forth interpreter reads.
I may look into Forth again with this objective.
C
2003/9/8
The_Sage
>MsgID:<1BS6b.3215$Yt....@newsread4.news.pas.earthlink.net>
>>I will when you post the regular expression engine in ASM that does the same
>>exact thing your post for the C code would do.
>Well, I must admit you have me there.
I knew it.
Now if you could only be honest and tell us that there is code hidden in the
stdlib.hhf file. Hiding code does not reduce the number of lines of code, it
only hides it. Not very honest.
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:r2aqlvs7fbbdli9jk...@4ax.com...
>
> Now if you could only be honest and tell us that there is code hidden in the
> stdlib.hhf file. Hiding code does not reduce the number of lines of code, it
> only hides it. Not very honest.
>
> The Sage
Actually, the "stdlib.hhf" file is simply a header file, much like stdio.h or stdlib.h
in C. The *real* code is "hidden" in the hlalib.lib library file, much like C's
standard library is "hidden" in files like cw32.lib (Borland) and so on.
It is interesting that elsewhere you bemoan the fact that assembly doesn't
support abstraction and encapsulation, but when presented with an
assembler that employs information hiding to help people write assembly
code more productively, you start complaining about the "hidden code".
At some point, I'd like you to explain the difference between hiding code
in the HLA Standard Library and hiding code in the C Standard Library
and why one form is acceptable while the other is not.
Cheers,
Randy Hyde
The_Sage
>Date written: Mon, 08 Sep 2003 07:40:52 -0400
>MsgID:<odqolvg6pqnf4df54...@4ax.com>
>>>The problem here is that assembly is more of a paradigm than a
>>>specific language; therefore we should be comparing assembly
>>>as a paradigm rather than a language. Saying 'a event driven
>>>paradigm is useless as it is not an object oriented paradigm'
>>>is similar to the comparason being made here.
>>ASM is most definitely a language. Do not redefine terms in defense of ASM, it
>>is a computer language, plain and simple.
>Assembler is a mnemonic representation of a processor's instruction set,
>plain and simple.
Not true since it has a syntax and a processor's instruction set does not.
arargh3...@now.at.arargh.com
wrote:
<snip>
>
>>Assembler is a mnemonic representation of a processor's instruction set,
>>plain and simple.
>
>Not true since it has a syntax and a processor's instruction set does not.
What does that have to do with it?
The only reason for an assembler to have a syntax is to make life
easier for the coder. If you want to do it the hard way, dig up a
copy of 1401 SPS. No syntax. If you don't put things in the correct
column, it don't work.
Come to think of it, the 1401 did have a syntax. For example:
For the 'A' opcode (add) there were only 3 forms of the instruction
that were acceptable.
A
A nnn
A nnn nnn
Where 'nnn' is an operand address.
Give it anything else, and it stopped dead.
And, actually, the x86 instruction set does have a syntax.
--
Arargh309 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Beth
> Its definition should be independent of any particular hardware or
operating
> system.
So how do you write device drivers or efficient GUI code? One is
implicitly tied to the hardware by its nature and the second can't be
done while there exists no GUI standardisation (if you use a
cross-platform GUI library then it'll: lack certain specific
functionality, have poorer performance and, to be truely "portable",
it would have to break the user interface guidelines and GUI style of
the operating system with generic "works on all systems" controls)...
This would imply that these things simply cannot be written using a
"good language"...but one would have to simply call into question what
is meant by "good language" when it's throwing out practically all
software written in the last decade...still reading out of date texts
as your "authority", Sage?
> ASM is specific to a particular computer hardware
> architecture, therefore ASM fails this criteria for a good language.
Device drivers fail this too, they are specific to particular hardware
devices...FTP and Telnet fail this too, they are specific to
particular low-level networking protocols...practically all GUI code
fails this (only X Windows is truely "portable" GUI code, on condition
that the X server has been ported to a particular machine...all the
others - Windows, Mac, Menuet, etc. - have their own proprietary GUI
designs), as they are specific to particular operating system
vendors...
C and other HLLs fail this too, as "char" gets linked to a particular
7-bit ASCII encoding scheme and, contrary to the entire definition of
the "char" data type, which is supposed to be abstractually "the
natural size of the native character encoding", Windows NT - who's
subsystems are all 16-bit UNICODE based - requires "wide character"
extensions...this one's quite amusing: specific where it should be
generic and generic where it should be specific :)
The distinction of "bitwise" and "logical" operators on many HLLs
betrays the specifics of the underlying implementation (that the
boolean is not a single bit - as abstractually, it logically is - but
is multi-bit, due to the _specifics_ of a particular hardware
architecture that the machine word or a byte is the smallest
addressable quantity)...they all do it so it's okay? NOT if
_particular hardware_ appears on the scene that _doesn't_ require this
stuff, proving that it never was "portable" thinking whatsoever...
What's "portable" about "network byte-order" when we can see
little-endian source code taking pains to byte swap but big-endian
coders don't even think about it and code without? And the operation
"byte swap" is size-dependent, so that breaks "portable" notions
too...
Time to wake up and smell the coffee...first, "portability" is not a
simple binary attribute of a program: it has it or it
doesn't...second, _whatever_ you choose, it _will_ fail the
"portability" test at some point...so you can't get all "theoretical"
about this, it must be grounded in _practicality_...only universal
laws are "portable", everything else is "non-portable" on some
grounds...24 hours in a day only applies to the Earth, timezones to
rotating spherical planets (or moons...but _the_ Moon is
geosynchronous with the Earth - always shows the same side - so would
Moon people be claiming that using the Earth to measure this passage
of time is "portable"?)...blah-blah-blah...
"Portability", like Communism, was a red herring...trust me, I chased
after it for about a decade...I swallowed the hype...I got all
"theoretical" because the books did...and I got obsessed with it...add
something "portable"...but, wait, it's still not portable to a washing
machine...make it more "portable" again...wait, washing machines on
the Moon won't find this "portable"...and again...and again...and
again...
And, in the end, _NOTHING_ can ever pass the test with flying
colours...you and all the academics talking out of their backsides on
this are chasing Fool's Gold...yes, add a layer of indirection here
and another there...choose to make it work across some current subset
of machines...but all of them? For all time? In every country? With
every character set? Under every endianness? For all bitages? Every
network protocol possible? etc., etc., etc....
Simply - pardon the crudity but it's accurate appraisal - it's just
bollocks...it's a fundamental misunderstanding of the nature of
abstraction...it's not "the more, the better"...it never was and it
never will be...
But I tell you what...you're not going to believe this because some
textbook told you to worship and you always do what you're told by
unknown, faceless strangers because they have a book in
black-and-white...so, just try it...you go chasing the end of that
rainbow for as long as it takes for you to realise that the whole "pot
of gold" nonsense is just a story to tell children, safe in the
knowledge that they'll never be able to reach it to find out that it's
total nonsense...
"The gold road's sure a long road
Winds on through the hills for 15 days
The pack on my back is aching
The straps seem to cut me like a knife
I'm no clown...
I won't back down...
I don't need you to tell me what's going down.
Down down down...
I'm standing alone...
I'm watching you all...
I'm seeing you sinking...
I'm standing alone
Your weight in gold...
I'm watching you sinking...
Fool's gold
These boots weren't made for walking
The Marquis de Sade never made no boots like these
Gold's just around the corner...
But the breakdown's coming up round the bend...
I know the truth and I know what you're thinking...
Down down down...
I'm standing alone...
I'm watching you all...
I'm seeing you sinking...
I'm standing alone...
Your weight in gold...
I'm watching you sinking...
Fool's gold"
[ "Fool's Gold", Stone Roses...at times, when looking at the state of
the world around me, I can't help but find this song almost a theme
tune or national anthem for human stupidity...but, in your case, Sage,
this seems slightly more apt than it usually does :) ]
> Its definition should be standardized,
Ture, there's no disagreeing with that...
> and compiler implementations should
> comply with this standard.
...oh, except there is disagreeing with it, isn't there? The
publishing of a standard so often doesn't mean a thing...you do know
that there actually _is_ some ISO standard for assembly language? And
though there's standards for HLLs in all directions (that's another
point...with conflicting multiple standards, doesn't that itself
compromise the entire notion of "standard"?), there's no such thing as
an "ANSI C Compiler" that doesn't have some weird quirks or
"proprietary extension"...
After all, if your C compiler has "asm" rather than "_asm", it's just
gone and broken standards and conventions in order to supply you a bit
of "convenience"...
> Assembly languages cannot be standardized due to
> variations in processor architecture, therefore ASM fails this
criteria for a
> good language.
ASM has been standardised (somehow) by ISO...no, I've no idea how they
think they've managed that but pay the money to them and go look-see,
if you like...just thought that should be pointed out here before
carrying on...
Assembly language, though, cannot be standardised as it's bound to the
underlying machine instructions...hence, if assembly language is
"non-portable" then it's because the _machine itself_ is
"non-portable"...the thing that demonstrates that it's the
_processor_, not assembly language at fault is that where processors
have binary compatibility, assembly _is_ portable...and that occurs
with "CPU families"...the 8086's physical design is nothing like the
latest AMD chip...but the latest chip has 8086 binary compatibility
and, therefore, an assembly language program _is_ "portable" between
these different processors...
"But they aren't different processors, really", I hear you say...well,
no, sorry, you're wrong...they are completely different
internally...what is actually happening here is, due to the binary
compatibility allowing "portability", people merely _think_ of them as
being all the same chip...note that this also holds for the 68K family
and others, as well as the x86, which isn't the only CPU in a "family"
of binary compatible chips...
Assemblers need no modifications for this portability (only careful
selection to use instructions within the common "8086" subset of
shared opcodes)...therefore, the assembler is not at fault...and
neither is assembly language...
The lack of standardisation is present in chip design and
manufacture...where it isn't, note that I quote AMD rather than Intel
above...so, where they _do_ follow the same standards, this
"non-portability" nonsense also disappears...
Assembly language is merely a human-readable representation of the
machine instructions...the language is not at fault for what you
accuse it of...the _machine_ is...
Consider this: Were there a standard for CPUs and, as you say, all
manufacturers adhered to that standard, this entire argument and all
this "HLL vs. ASM" bullcrap would _instantly die_...HLLs are merely
curing an inherent problem posed by _copyright_ and CPU manufacturers
trying to "out-compete" each other...if these were not there then HLLs
would be nothing more than macro packages to save time...
Fool's Gold, Sage...you'd better spend your time doing something
that's actually useful to the world...you see, this nonsense has all
just been invented to either give people jobs or to try to pretend
that _human failings_ present in the processes are universal laws that
can't be violated or something...
Let's all use Java CPUs and the _assembly language_ of Java byte codes
directly...completely "portable"...
Pay close attention to that one: Java, the language built from the
ground up to be the ultimate answer to "portability" once and for all
(and though it's a crap language for other reasons, it's "portability"
aspects are, basically, _second to none_), includes _assembly
language_ as an integral part of its design and
implementation...ponder that one over with the other things I've
said...you might eventually be able to see the bullcrap as they feed
it to you, if you work hard at it...
> It should support software engineering technology, ie -- for those
of you
> who don't know what that is yet, by discouraging or prohibiting poor
> practices, and promoting or supporting maintenance activities.
Yes; Typed set theory, mathematical analysis, pre- and post-condition
schemas, Z notation, built-in assertion testing, ...
Oh, what? You just meant "draw pretty data flow diagrams" when you
said "software engineering"? That's not engineering...there's
absolutely no discipline or formal structure to it...you only meant
the practice of by-passing bad phased tool design using physical
division and encapsulation? Oh, that's like "I can't find a hammer in
the nail, this screwdriver'll do" type of "engineering" that many a
DIY enthusiast employs to awful "has anyone got any duct tape to cover
up this pipe that's leaking water like there's no tomorrow?" effect...
Yeah, right...you know, garbage men like to call themselves "refuse
reclaimation and disposal executives" these days too...they still, of
course, just pick up the garbage and throw it in the back of the
truck, however "fancy" and "posh" they make their job
description...so, sure, if you like, you're a "software engineer" or
perhaps a "abstractual co-ordination officer" or a "QA negligance
patching executive"...
Whatever...you still won't know your arse from your elbow, however
clever the name you use to try to make people think you're actually
useful somehow...
> ASM provides no
> support for software engineering technology.
ASM supports _everything_ that the machine is capable of; Its support
is, in fact, _total_...the one snag is that you've got to do all that
hard work yourself that those HLL authors already did on your
behalf...note, though, that Randy has made some of that effort on
behalf of his HLA compiler...and it starts to take on HLL
characteristics...it has support that's _higher-level_ than some HLLs
in places...the OS portability with absolutely no code modification
with specially written code (and you only need to specially write your
code because HLA also supports total "non-portability" too...thus,
you're selecting the "portable" subset of the total superset of
facilities provided) is something a heck of a lot of HLLs can't do and
would desparately aspire to being able to provide...
Earlier, you were confusing the language with the "non-portability" of
the machine itself...now, you are confusing the language with its
pre-packaged support...ASM can do all these things too...it just
doesn't come out of the box like that...note that you could extend
HLA's "portability" even to other processors by creating "portable"
instructions macros unconnected to the native machine instructions and
then make selective use of these, having a ported version of the HLA
compiler and its libraries to the target machine of your choice...
The truth is, _HLLs ARE DOING THIS IN EXACTLY THE SAME WAY_...it's NOT
"magic"...they just do all these things on your behalf _prior_ to
release and hide it away inside the compiler or its libraries so you
can proceed none the wiser that, simply, all "portability" ever boils
down to is _indirection_...that's it...it's all just
indirection...that's all your precious "portability" actually is...
Well, ASM is as capable (more capable, often, due to ASM
implementations tending to carry some of the most impressive macro
facilities) as any other language in creating such indirections...
The reason why this isn't often the case is just that ASM programmers
are actually wanting to _avoid_ unnecessary indirections...and that's
because every indirection comes with a price of size, bloat, slowness,
crap performance, inability to access specific functionality that the
machine has just because some other machine doesn't have it and it
would be "non-portable" to use it, etc., etc....
"Portability" is merely indirection...such indirection as implemented
by HLLs, is perfectly available to ASM programmers...ASM programs tend
NOT to implement these indirections because, often, many of them can
actually be quite redundent and completely unnecessary...ASM
programmers choose ASM because it puts this decision in their hands...
To be "portable" or not to be "portable", that is the question...and
only ASM leaves the choice fully open for either answer...HLLs try to
answer the question by just picking "portable" and trying to force the
world and its brother into that answer, whether it'll actually fit or
not...
Go back to your fancy textbooks, Sage, the reality would be far too
unsatisfactory to your sense of order in the universe...the theory
sounds nice...like some magical fairy tale land where every machine
works beautifully and every program runs on everything for all
eternity...yes, I think you should stay there...reality would probably
give you a heart attack, as you and your favourite theoreticians run
smack face-first into a brick wall, that your "theory map" tells you
shouldn't be there :)
> ASM does not work with
> abstractions, just machine-level specifics, therefore ASM fails this
criteria
> for a good language.
Well, that's nonsense from the start...feed the ASCII of "mov eax, [
ebx ]" into an x86 chip and see where that gets you...look up
"mnemonic" in a dictionary and see how "non-abstract" this highly
abstract concept is...
In fact, all assembly language is, is one big abstraction of the
binary the machine actually executes...it _is_ an abstraction
itself...
More over, ASM has among the best macro facilities available, allowing
abstractions that no other language comes close to providing or
allowing...the machine itself, irrespective of language, provides for
abstractions via procedures (and you've got to allow this one through
because if you try to condemn this as not counting, you're throwing
every HLL baby out with the bathwater at the same time, because _all_
of them depend on this to do their thang)...
And since when does abstraction pass or fail as the sole criteria for
a good language? If so, though English is clearly highly abstract
(which, it must be noted, actually conspires to make it _MORE
AMBIGUOUS_ with the increased expressiveness of a higher and wider
form of abstraction, rather than more accurate as a communication
medium), what about mathematics? It is abstract, true enough...but it
is abstract in an entirely different way to English...less expressive,
more pedantic...Maths deals with abstract entities but does so in an
entirely non-abstract way...the laws and relationships are absolute
and pedantic with no detail left out...
Thus, if there's different kinds of abstraction appropriate for
different kinds of expression (English is useful for "how are you?"
where Maths is useless, Maths is useful for scientific inquiry where
English's ambiguity often makes it useless...hence, people use one for
one situation and the other for other situations...neither "beats" the
other - stop that habit of falling into adversorial thinking
automatically - but they are different tools for different jobs)..then
can the mere presence of any type of abstraction regardless and in any
quantity of any quality actually stand as the sole criteria of a good
language?
This assertion smacks heavily of not being thought through
properly...you're not really considering what abstraction does for
language to make it "good"...you're not even really acknowledging that
abstraction is a generic term for a large, large superset of tools for
expression...where's the talk of traditional measures of language
properties? How does abstraction effect signal-to-noise? How does
abstraction effect expressiveness? How does abstraction effect
accuracy (what with chaos always in effect)? Blah-blah-blah...
You're trying to fit the facts to your theory rather than the theory
to your facts...you're keeping "abstraction" still and then trying to
force everything else around it so as to force "abstraction" to be
god-like in its perfection, by twisting definitions to be entirely
based on this unfounded premise of "the more abstraction, the better
things are"...even when you can cite practically any example of
language and analysis reveals abstraction is merely a focussing tool
and when its focus is on one thing, it's taken off something
else...thus, abstraction is actually merely a _necessary compromise_
to suit the human condition...
Note that machines have no inherent ability to abstract
whatsoever...they achieve "expressiveness" through exacting exhausting
enumeration of base elemental properties, which separate hardware
transforms into differing physical properties...without abstraction,
the accuracy of machines is not in dispute...they make absolutely no
mistakes whatsoever until physical defects damage them...without
abstraction, their expressiveness is theoretically inexhaustable
(within the limits of Godel) and, thus, second to none...
However we humans choose to express ourselves to these machines, the
machines themselves employ no means of abstract internally or between
each other...there is only "bits" (no types, no intent, no inherent
nature...nothing our human abstractions regularly demand) and those
are ruled over by utterly strict and deterministic law...yet this
"language" - though you would deem it as the worst language possible
as it contains no hint of abstraction whatsoever - has proved its
worth in billions of machines, large and small, throughout the world
as being utterly invaluable in dealing with those operations which are
too tedious, too complicated, too numerous for humans and our
_failing_ of being creatures that must abstract everything to cope
with...
In traditional measures of language analysis, natural languages like
English and French are considered low quality - the worst of the
bunch - on all properties...except for one that entirely redeems them
in their chosen context: expressiveness...they beat them all in
expressiveness, thanks to abstraction to absurd degrees...if you're
thinking "English-like" makes a measure of good language, you're
sorely mistaken...in fact, for a while they even tried it...so, if
it's such "good language" to do this, why has COBOL fallen out of
favour? Why do programmers - new and experienced - actually find the
English-like syntax unnecessarily cumbersome?
This mistake was made decades ago, Sage...read more up to date books
and avoid dooming yourself to repeat flawed history...language is a
lot more than a series of abstractions...abstraction is a wide field
of possibilities, not just one "got it or haven't got it" property of
a language...and it is NOT "the more, the better" as there are
inherent trade-offs and balances between various different language
properties...there is no perfect language in terms of there being a
flawless language...though there is a contextual "perfect language" in
terms of matching your tool of language to the task to which you need
to perform...
Perfect does not mean "flawless" - there is no such thing - it means
accurate corresponance of advantage and disadvantage to the specific
context, where advantages are all helping and the disadvantages -
though they exist - do not hinder...your adversorial mindset is itself
flawed in its belief that "winning" demonstrates flawlessness...to
which one need only ask the question: "if so, then why does everything
'fail' in the end? Why do languages change and others come to replace
them?"...you're viewing the whole thing from far too narrow a context
and, thus, fail to see the wider implications of your precious
abstraction...
> It should effectively support the application domain(s) of interest.
Depending on what you mean by "support", ASM is the _ONLY_ language to
provide absolute blanket coverage of all application
domains...whatever an application is permitted to do (with respect to
the machine's capabilities and its operating environment), ASM lets
you access it...no other language comes close...
In fact, HLLs are universally guilty of "specialising"...thus,
improving the native support towards a particular application domain,
at the expense of not supporting other domains as well...
Note, also, that "exacting machine-dependent behaviour" _IS_ a valid
application domain too...and all application domains are implicitly
effected by it regardless...thus, the HLL mindset to exclude this
domain can often be foolhardy and dangerous...if you abstract
(bounded, limited precision) "floating point" to represent all
unbounded real numbers then you're going to be losing accuracy and not
even realise it...ignoring a problem does NOT make it go away...
> ASM only
> supports a particular hardware architecture, and, in general, it has
no
> inherent relationship with any particular application domains,
therefore ASM
> fails this criteria for a good language.
Wrong; You've stated one set of facts and then magically jumped over
to the opposite conclusion...you've stated that assembly has "no
inherent relationship with any particular application domain" and,
clearly, it is capable of operating in all domains, as the machine is
capable of doing so and assembly is merely an abstraction of the
machine...
Hence, this actually demonstrates a total lack of bias to any
particular application domain...it treats them all equally...thus, it
provides equal, unbiased "support" for all application domains with no
bias...
Somehow, you state "It should effectively support the application
domain(s) of interest" then confirm yourself that assembly has no
inherent bias to any particular application domain but is capable of
dealing with any application domain - thus, it is providing equal,
unbiased "support" for ALL application domains without exception -
but, somehow, you make a "leap" as you say the word "therefore" to the
total reverse conclusion...
If this completely opposite conclusion to what the facts actually
suggest seems self-evident to you then I'll have to request that you
make explicit the reasoning that resides in your "therefore" because
you've made a giant leap there without any suggestion as to the
rationale at all...there appears to be faulty reasoning hidden inside
the abstraction of "therefore"...make it explicit for examination or,
otherwise, it'll have to be presumed as merely faulty reasoning and
your conclusion is invalid and forfeit...
You actually make the case to the opposite but then jump to the
reverse conclusion without elucidating how you could suddenly switch
arguments half-way through...
You don't even seem to be listening to yourself...merely stating some
facts and then putting "therefore, it's not a good language" does not
work in this (or any of the other) cases...one possible reason for
this "logical fallacy" entering into your arguments is that the
conclusion you're trying to force on all the facts is actually not
supported by them...
> It should support the required level of system reliability and
safety.
Oh, you've cocked up here big-time, sunshine...you should not even
approach this one...
> ASM provides no support for reliability or safety.
ASM provides the base mechanisms for unparalleled reliability and
safety...the fact that people make no use of this support is a _human
failing_, not a language failing...
ASM exposes the full machine via its base elements
unabstracted...theoretically, absolute reliability and safety can be
fully _proved_ only at the ASM level...HLLs abstract and, therefore,
the "hidden" elements of that abstraction have to be relied upon to
function correctly...only by exhaustively examining the ASM-level
machine output can these abstractions be _proved_ correct...without
the low-level, these little bits of "magic" have to simply be relied
upon to function correctly with absolutely no proof that they always
will...
And what of assemblers that do provide type safety checks? This is the
same inherently flawed "safety" system as used by HLLs...the support
is equal in such cases...and on modern assemblers, there is validation
via prototypes, matching pesudo-instruction pairing, a specified
rather than implied application across processors, etc....what
particular HLL "reliability and safety" measure are you thinking of
that does not exist in an assembler somewhere?
Not that HLL "safety" measures are anything to be writing home
about...data typing is inherently flawed - similar to testing - as a
logical fallacy (to which I'm sure you're glad I pointed this out,
knowing your Love of avoiding logical fallacy) - when there exist
generic "primitive data types"...how does one differentiate one
integer "type" from another integer "type"? The integer of cars in a
car park is NOT of the same logical quality as an index into a train
timetable...what support exists in any language to deal with this
"safety" issue? Creating user-defined data types that are inherently
incompatible...except, oh dear, they aren't...not in ASM, not in
HLLs...data typing is currently inherently flawed because the
"typedefs" to primitive data types merely rename rather than create a
new, unique and distinct data type...in fact, if you want this sort of
functionality then creating classes (such as Windows use of "#define
STRICT", which forces conditional compile statements to equate unique
data types to structures, which are all considered unique, distinct
types...the compiler itself - even though it's a HLL - does not
include this very necessary facility, thereby forcing MS to use quite
an ugly "hack" to provide their "STRICT" data typing verification
checks) appears to be the only option to force tool support of such
things...and that sort of support, where it exists on ASM tools, tends
to be of equal or better measure than HLL equivalents...
> ASM will not object to any
> form of programming, good or bad, therefore ASM fails this criteria
for a good
> language.
But is it the responsibility of a language to dictate and enforce
"good practice"? Should official bodies delibrately restrict English
so that you may only express the approved doctorines of state? Oh,
indeed, NewSpeak exists...and those HLLs really have vastly restricted
your thinking capacity by enforcing unfamiliarity with the actual
underlying issues of good language design and the implications of
language design decisions...
And this assertion could only really stand up if you could demonstrate
that there exists no examples of where HLL code goes to error under
the legitimate syntax of that language...in short, _all_ HLL
programs - with no exceptions - must be entirely flawless without a
single bug for this notion of "enforced correctness" to prove its
worth as a legitimate means of ensuring correct programs...
Unfortunately, the reality is entirely different...bugs seem as
equally present in all programs regardless of language constructs
trying to enforce "good practice"...
Better yet, there's even a case for _better_ reliability and safety
from ASM code because though it's common to find faulty HLL code, ASM
code tends to be more rigourously scrutinised before release...
As I suggested to Ed in another post, if you're relying on your
compiler as the first port of call and sole layer of error detection
then you're actually practising a far more dangerous game with
reliability and safety...programmers _will_ simply fall onto the
compiler as a crutch to verify all "evils" are not present and presume
that if it passes the compilation and a few simple tests, it's fully
functioning and correct...thus, if the compiler fails to detect
logical error (which no machine is actually equipped to be able to
detect without knowledge of _intent_) then the errors pass by
untouched...
ASM programmers, on the other hand, do not generally take code passing
the assembler as a measure of "correctness" at all...we, in general,
take our time to verify things manually before posting code, yes? HLL
programmers, on the other hand, would be tempted to merely check that
an example compiles and if it does then they post, presuming this is
an indication of "correctness"...
In short, HLLs take on this responsibility for reliability and
safety...even though a machine is actually not qualified to do so
because it has no notion of _higher intent_ for a program...ASM, on
the other hand, forces this responsibility on the programmer - who
does know program intent - and helps to ensure that they verify their
code properly...
More laws make for more criminals, not less crime...
> Its compiler implementations should be commensurate with the current
state of
> technology. In the sense that an assembler, the "compiler" for an
assembly
> language, is created for each new assembly language as it is
introduced,
> language implementations keep up with computer technology. However,
in the
> sense of supporting the current level of software technology, ASM
does not,
> therefore ASM fails this criteria for a good language.
Depends upon your assembler; _Some_ assemblers take pride in not
bothering...others take pride in _bothering_...HLA, MASM, TASM contain
support for all commonly used HLL methods...
Although, again, you're taking an "out of sight, out of mind" attitude
here...assemblers are almost immediately updated to include new
instructions as they appear...compilers take longer to do so...and,
often, are fundamentally incapable of supporting new extensions
without compromising their "portable" status...as an example, the MMX
instruction set extensions...compilers do not automatically employ
them, due to the need to compromise these with higher level
intent...instrinsics may be provided for a compiler but, inherently,
these are _low-level_...a means to code assembly through a HLL...
Please what specific level of software technology does C employ - what
with C being a highly popular language, used in many actual
applications - that HLA doesn't kick its arse on? The only thing you
could name is cross-processor portability...but you can't use that
because you've just stated that you're concern with _software
technology_, irrespective of keeping up with _computer_
technology...you cut off your own escape route there...name _one_...I
await the answer with excitement :)
> Appropriate software engineering-based supporting tools and
environments
> should be available. The tools available for working with ASM are
typically
> other very low-level tools, and they do not provide software
engineering
> support, therefore ASM fails this criteria for a good language.
"Typically" being the operative word; There are tools which aren't
"typical", providing such environments...if people aren't using those
then that's _their_ failing, not the language's...and, in fact, it is
NOT a languge failing whatsoever for it to be used in an inappropriate
manner...
HLL compilers are command-line tools too...and sticking a visual face
over a tool is purely cosmetic...don't tell me you're that sicophantic
after the coattails of "experts" that you really believe a minor
cosmetic change - with no substance of change to the process -
actually makes that great a difference? No, you probably do...you
wouldn't know an original thought if it hit you on the head...just
perpetuating Chinese Whispers from people, thinking that passing on
their wisdom in an inaccurate, non-representative form somehow gives
you their wisdom and authority...no dice, sunshine...people who do
that are generally _more stupid_, not less so...
> Clarity of source code - the extent to which inherent language
features
> support source code that is readable and understandable and that
clearly
> reflects the underlying logical structure of the program. The source
code for
> an ASM application is cryptic and in a very low machine-specific
form.
> Hence, it is error-prone, and the structure of the program is not
evident,
> therefore ASM fails this criteria for a good language.
Other than "it is error-prone" - as, after all, that boils down to
whether you're accustomed to it or not - I'd completely agree to these
points about lesser readability...it _is_ an inherent problem for the
current arbitrary choice of assembly language representation...note,
though, that HLA and Terse and others demonstrate that it need not be
the case that it's like it is...but, granted, blind adherance to
"tradition" regardless of application means that this is an area ASM
could do with some "fixing"...although, watch out, if and when it
does, then the basis of the perpetual "myths" surrounding ASM are in
danger of being found out for the mythological status that they really
are...at the moment, the unreadability helps to disguise the
inaccuracy of your assessments of ASM...people can't easily see that
you're wrong...if ASM gets "improved" by this then your inaccuracy
will be exposed...
Mind you, C is similarly cursed with regard to bracketing statements,
control structures and other things...showing ASM has problems does
not automatically mean HLL are without similar problems...
Also, comprehensibility of a language is a subjective matter...hence,
it's a foolhardy measure to take in evaluating "good language"...it
_is_ something to consider but you need to make exhaustive studies
with large sample sizes to cancel out the bias of the inherently
subjective nature of this point...you can't presume that because
_you're_ more prone to coming to error with ASM that, universally,
this is a problem everyone else also has...you can suspect it but you
cannot consider it "fact" without the large studies of how this facet
effects the entire programming population to confirm your
suspicions...
[ Replying to this is making me tired...I'll continue with only minor
points from now on...just to stress this is not because there isn't
entire novels worth of inaccuracy in what you're saying but just that
I can't be bothered to type it all out :) ]
> Complexity management (architecture support) - the extent to which
inherent
> language features support the management of system complexity, in
terms of
> addressing issues of data, algorithm, interface, and architectural
complexity.
> ASM has some algorithmic complexity management and limited
structuring, but
> ASM provides minimal support for complexity management, therefore
ASM fails
> this criteria for a good language.
ASM requires more work to get this done...but its support is
effectively equal to that of _ANY_ imperative language of your
choosing...
> Concurrency support - the extent to which inherent language features
support
> the construction of code with multiple threads of control (also
known as
> parallel processing). ASM will often provide instructions for
accomplishing
> multiple threads of control. However, such support is neither
straightforward
> nor easy to use, therefore ASM fails this criteria for a good
language.
At least it exists; Most 3GL programming languages are entirely devoid
of concurrency support...C, C++, Pascal, etc. do not come with it "out
of the box"...requiring actual OS API - which is independent of
language and could be potentially used by them all - to even be able
to approach it at all...
> Distributed system support - the extent to which inherent language
features
> support the construction of code to be distributed across multiple
platforms
> on a network. ASM provides no specific support for distributed
systems,
> therefore ASM fails this criteria for a good language.
Then nearly _ALL_ languages are bad languages here because distributed
system support and concurrency support are never implemented in the
vast majority of cases...at least ASM has the ability to support such
things without modification...when HLLs need to add such support, we
find them lacking that additional keywords and structures need to be
added to make use of such possibilities...there is no need for
creating a "Concurrent ASM" version of an assembler but there is a
need to create "Concurrent Pascal" and "Distributed C"...
Both are actually catered for by the OS environment, anyway...they
have to be because it requires their support...hence, one could
abstract and place wrappers around the OS API for these things,
exactly as the HLLs are actually implicitly doing on your behalf,
anyway (and they do the same for exception handling too)...this isn't
a language responsibility, in fact...it's an operating environment
responsibility that a language should provide loose to exacting (some
applications may merely "take advantage of it when available", others
may _depend_ on such functionality...therefore, the typical HLL
abstraction of always going for "loose" support, forsaking exacting
control is inappropriate for some application domains) support for
expressing the inherent dependencies and such of a program...
On that score, practically all languages other than specialising
concurrent and distributed languages _FAIL_...ASM at least already has
the means and support - for it supports anything that the machine or
OS provides - to start in this direction...with most HLLs, it's simply
_impossible_ to do...
> Maintainability - the extent to which inherent language features
support the
> construction of code that can be readily modified to satisfy new
requirements
> or to correct deficiencies. ASM provides no inherent support for
> maintainability, therefore ASM fails this criteria for a good
language.
Linked to readability; Which is a subjective matter...although, my own
subjective view is that the strides toward better readability in
Terse, HLA, MASM, etc. are to be commended...also, maintainability has
an awful lot to do with how well coded something was in the first
place...again, trying to apply something that's not really a language
attribute onto a language...unable to distinguish design from
implementation from the people using it...hardly a good point to start
arguing this sort of thing...
> Mixed language support - the extent to which inherent language
features
> support interfacing to other languages. ASM provides no capability
to
> interface to a higher level language (however, some high level
languages
> provide a capability to interface with an assembly language),
therefore ASM
> fails this criteria for a good language.
Are you talking out of your arse or what? ASM is the only language
capable of interfacing with _ALL_ languages inherently...HLLs need to
be tailored to all the various possible calling conventions and they
are the ones lacking here...ASM supports them all, HLLs can't support
everything ASM is capable of...it's the HLLs that are lacking on this
score, ASM's record is, in fact, entirely faultless here...so if this
is a criterion of "good language" then ASM succeeds and HLLs fail
miserably on this score...HLLs need proprietary extensions and
specific mixed language support (and if they leave out your chosen
language, it's just tough luck)...ASM has the means straight out of
the box to interface with _anything_ in _any_ language...
Moreover, HLA / MASM / TASM / others come with prototyping and
automatically generated prologue and epilogues and support to deal
with parameter passing for a range of HLL languages...the equal of
anything C or Pascal provides using this support, way beyond what any
other language provides when done manually, as it can interface with
_anything_...
> Object-oriented programming support - the extent to which inherent
language
> features support the construction of object-oriented code. ASM
provides no
> object-oriented programming support, therefore ASM fails this
criteria for a
> good language.
HLA and TASM provide native support...MASM provides a good
framework...other assemblers are all capable of doing this, if you
actually know _how_ OOP works "under the hood" (if your HLL worship
hasn't made you so dependent on them doing it all for you that you're
totally ignorant as to what's going on)...
OOP is a style of programming, nothing more..."magical" keywords may
ease the burden but the support is total...because, simply, ASM
SUPPORTS EVERYTHING...
> Portability - the extent to which inherent language features support
the
> transfer of a program from one hardware and/or software platform to
another.
> ASM is not portable from one type of computer to another. At best,
it can be
> portable to another computer within the same family of computers
built by the
> same manufacturer, therefore ASM fails this criteria for a good
language.
Portability is indirection...ASM supports indirection like any other
language...portability is entirely possible...the only difference in
ASM's case is that, generally, its users are coming specifically to it
to _avoid_ portability for increased performance when it matters not
for being "portable"...hence, generally, there is little "out of the
box" support for it...
But it's certainly entirely possible...HLA _does_ have "out of the
box" support for cross-OS portability without any need for code
modification at all...the principle by which Randy has achieved this -
indirection via the standard library - is entirely similar to how C
and other HLLs achieve the same thing...and potentially could be
extended to _ANY_ situation where "portability" is needed...on top of
everything else, you're now confusing "language possibility" with
"human intent"...just because ASM programmers tend to want to be
avoiding unnecessary "portability" constructs enforced on their
programs, unacceptably reducing performance to perhaps levels that
make a project unfeasible (so use of ASM has actually made an
application possible, where HLLs were not capable at all to support
it)...this doesn't mean that it cannot be done...ASM is the language
that _supports everything_ and guarantees that if the machine can do
it, it's possible...the possibility completely exists - HLA
demonstrates one aspect for supporting multiple OSes via the same
unmodified assembly source code - and, therefore, demonstrates that
there's nothing wrong with the _language_...even if you might argue
there's something wrong with the people who use it for forsaking this
"good practice" of "good language"...
> Real-time support - the extent to which inherent language features
support the
> construction of real-time systems. ASM inherently supports a
streamlined
> version of code because it does not contain the inefficiencies of
expression
> found in HLLs. This is often assumed to mean that an assembly
language
> produces the best possible performance, but this is not the case.
Today's
> compiler technology benefits both from current technology
improvements as well
> as from the experience of hundreds of language performance experts.
Hence,
> compiler optimizers can often do a better job of streamlining code
than a
> programmer can do using an assembly language [Lawlis 92]. ASM also
is
> inherently more difficult to use to accomplish streamlining,
therefore ASM
> fails this criteria for a good language.
An "application of language" issue rather than inherent in the
language itself...
Just because you're a bad cook doesn't make your oven a bad cooking
tool...it'll make perfectly good pies when a good cook uses it, even
if your pathetic cooking talents mean that all you can produce are
pies that burnt...
> Reliability - the extent to which inherent language features support
the
> construction of components that can be expected to perform their
intended
> functions in a satisfactory manner throughout the expected lifetime
of the
> product. ASM provides no inherent support for reliability, therefore
ASM fails
> this criteria for a good language.
You've mentioned this point before...you're now repeating
yourself...so few points that you need to double up on some of them to
pretend you've more to say than you really have?
> Reusability - the extent to which inherent language features support
the
> adaptation of code for use in another application. ASM provides very
little
> opportunity for reuse, therefore ASM fails this criteria for a good
language.
It's implicit in the word; "Re-use-ability" is an _application of
language_ issue...if no-one re-uses their code then that's their own
foolish decision...
> Safety - the extent to which inherent language features support the
> construction of safety-critical systems, yielding systems that are
> fault-tolerant, fail-safe, or robust in the face of systemic
failures. ASM
> provides no inherent support for safety-critical systems, although
they are
> often used in this domain, therefore ASM fails this criteria for a
good
> language.
Oh, sorry...ASM is the only language where you can _prove_, thus
guarantee, correct operation...the rest deal with abstractions so
there's an implicit assumption that these abstractions do "what it
says on the side of the tin"...if they don't then the error propogates
throughout the analysis...ASM, on the other hand, exposes the whole
lot to scrutiny...if you exhaustively test the program (and all
dependent components) completely at this level and _prove_ that it is
correct, only hardware failure needs to be accounted for (which, of
course, would certainly be fully done for any safety-critical
system)...
ASM exposes everything...so there are no nasty surprises or little
nooks and crannies where bugs can hide, if you take advantage of this
exposure to scrutinise every aspect of the program, proving its
correctness throughout...you can quote some nobody, if you like, I'm
going straight to _Knuth_ here...there's no inherent reason why bugs
should be present in any closed, deterministic system, other than
laziness leading to oversight...or perhaps the inherently dangerous
practice of relying solely on your compiler as the first and last port
of call for error detection...testing and debugging afterward is _too
late_...the bugs are alreayd in there...prevention rather than cure,
Sage...prevention rather than cure...
> Standardization - the extent to which the language definition has
been
> formally standardized (by recognized bodies such as ANSI and ISO)
and the
> extent to which it can be reasonably expected that this standard
will be
> followed in a language translator. ASM is not standardized,
therefore ASM
> fails this criteria for a good language.
True; But standardisation is also a route to stagnation and holds back
progress...
Mind you, in the case of ASM, only Terse and HLA (and perhaps RosAsm
in certain ways) are even attempting to exploit this for actually
making some sort of progress...hence, though it can do this, I'd have
to regretfully agree that no-one actually is bothering to do
that...so, to all intents and purposes, though there's potentially a
possible advantage to this, no-one's exploiting it to any great
use...and an opportunity missed is as pointless as not having any
opportunities at all...
So, it probably should be standardised (ISO have actually tried but
it's universally ignored)...unless someone actually wants to take
advantage of being "non-standard" in order to actually _progress_
things...
> Support for modern engineering methods - the extent to which
inherent language
> features support the expression of source code that enforces good
software
> engineering principles. ASM provides no inherent support for
software
> engineering principles, therefore ASM fails this criteria for a good
language.
> (Paraphrased from
http://archive.adaic.com/docs/reports/lawlis/r.htm)
Correct; ASM is not NewSpeak...
Some would see this as its advantage...evidently, though, you don't...
> Now please continue to entertain me by telling us, in light of the
above, what
> is so good about ASM that everyone should abandon their good
languages and go to
> ASM? Haha! Please teach us how to use logical fallacies by telling
us that all
> the above is completely wrong, just because you say so. Haha!
"Those who mock simply do not understand"...you prove this saying
deadly accurate here, poor little misguided Sage...
Beth :)
Beth
> I think Randy's HLA is already more HLL than ASM,
> even it can be used to create true, but restricted ASM-code.
Yes, on some scores, HLA _exceeds_ some HLLs...but, at the same time,
it doesn't do this by forsaking the low-level but by _supplementing_
it with HLL-like features...
> (I haven't heard about a boot-able stand-alone HLA-Os yet.)
It's a 32-bit only assembler, so the parts that need to be 16-bit code
(bootsector, code that switches to 32-bit protected mode, etc.) have
to be dealt with either by some other tool...otherwise, though, HLA is
totally capable to do the task...you haven't heard of it simply
because no-one's actually written an OS with it yet...
[ On the other hand, you'll _NEVER_ hear of a "boot-able stand-alone"
Delphi / VisualBASIC / C# / etc. OS because, inherently, these
languages are truely "application development only" from their
design...even the C and C++ OSes have occasion to need their
sprinklings of ASM to deal with hardware and I/O... ]
Beth :)
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:jhfqlvk4d3adps186...@4ax.com...
>
> >Assembler is a mnemonic representation of a processor's instruction set,
> >plain and simple.
>
> Not true since it has a syntax and a processor's instruction set does not.
>
Were you paying attention in your "Formal Languages and Automata Theory" class in college?
Did you even take one?
It's very easy to generate a grammar for machine instructions.
Therefore, they have a syntax (indeed, given formal language theory, it's easy enough
to show that you could generate an infinite number of syntaxes for a given instruction set).
Of course, if you don't know formal language theory/automata theory, you probably
don't have a clue what I'm talking about, so I won't bother to go on. And, yes, I
*have* taught those courses at *two* different Universities as well as having taking
graduate level sources in this subject, so I *do* have a small understanding of this
subject (lest you go off in one of your tirades accusing me otherwise).
Cheers,
Randy Hyde
Beth
> Randy wrote:
> >BTW, the "hello world" program in assembly:
>
> >program HelloWorld;
> >#include( "stdlib.hhf" )
> >begin HelloWorld;
> > stdout.put( "Hello World" nl );
> >end HelloWorld;
>
> >Doesn't look too different from that C example you gave.
>
> BTW, unlike the "C example", you are hiding the rest of the code in
the
> "stdlib.hhf". Yet another coward's way out! There is no hidden code
in the "C
> example".
Are you taking the piss? Or is your knowledge of _C++_ (heck, you
aren't even getting the name right...that's a _C++_ example, NOT a C
example) really that bad?
The "hidden code" for one particular compiler (Borland) has been
listed out for you to see...note that those header files aren't
actually containing the actual library source code...oh no...all they
do is define the interface for being able to link to the standard
library...if you had the source code to that added in there too, then
we can begin to see exactly why HLL programs bloat to stupid sizes and
slow performance in comparison to ASM...
> And it demonstrates how little you know. I made a typo: It wasn't a
C program,
> it was a C++. The "cout" is a C++ keyword only. How come you nor
anyone else
> could catch that? Can't you get anything right?
I caught you out; Shame I'm late posting this to prove that
outright...
> But yet once again, you take the coward's way out, hence the reason
we are still
> waiting for your regular expression engine in ASM.
And we're still waiting for you to post that full working VESA
example...or your own C / C++ regular expression engine...or, quite
frankly, a _logical argument_ would be nice...perhaps maybe _any_ sort
of code that backs up even one point you're making...any of these
things would be nice to see coming from you too...
Beth :)
Beth
> Here is a "hello world" program written in ASM:
>
> .model small
> .stack 100h
> .data
>
> hello_message db 'Hello, World!',0dh,0ah,'$'
>
> .code
> main proc
> mov ax,@data
> mov ds,ax
>
> mov ah,9
> mov dx,offset hello_message
> int 21h
>
> mov ax,4C00h
> int 21h
> main endp
> end main
>
> Now let's compare that to one written in C:
>
> #include <iostream.h>
> void main() {
> cout << "Hello, World!" }
>
> That is a typical example. Of course, it gets worse for more
sophisticated
> programs, especially for MZ and PE formats.
>
> I proved you completely wrong again. If you were my teacher, I would
have
> flunked you.
Actually, you're wrong, Sage...on many counts...
First, what you've shown is a _C++_ program, not a C program...
Secondly, you're hiding behind the preprocessor...let's look at your
C++ program with the "#include <iostream.h>" preprocessor directive
expanded:
------------------------------------------------------
#include <iostream.h>
/* iostream.h -- basic stream I/O declarations
There are some inline functions here which generate a LOT of code
(as much as 300 bytes), but are available inline because AT&T did
it that way. We have also made them true functions in the library
and conditionally deleted the inline code from this header.
If you really want these big functions to be inline, #define the
macro name _BIG_INLINE_ before including this header.
Programs will compile and link correctly even if some modules are
compiled with _BIG_INLINE_ and some are not.
*/
/*
* C/C++ Run Time Library - Version 6.5
*
* Copyright (c) 1990, 1994 by Borland International
* All Rights Reserved.
*
*/
#ifndef __cplusplus
#error Must use C++ for the type iostream.
#endif
#ifndef __IOSTREAM_H
#define __IOSTREAM_H
#if !defined(___DEFS_H)
#include <_defs.h>
/* _defs.h
Common definitions for pointer size and calling conventions.
Calling conventions:
_RTLENTRY Specifies the calling convention used by the RTL
_USERENTRY Specifies the calling convention the RTL expects
user
compiled functions to use (for callbacks)
Export (and size for DOS) information:
_EXPCLASS Exports class if building DLL version of library
For DOS16 also provides size information
_EXPDATA Exports data if building DLL version of library
_EXPFUNC Exports function if building DLL version of
library
For DOS16 also provides size information
_FAR Promotes data pointers to far in DLLs (DOS16 only)
Obsolete versions:
_Cdecl Use _RTLENTRY
_CLASSTYPE Use _EXPCLASS
_FARFUNC Use _EXPFUNC
_FARCALL Use _EXPFUNC and declare function explicity __far
*/
/*
* C/C++ Run Time Library - Version 6.5
*
* Copyright (c) 1991, 1994 by Borland International
* All Rights Reserved.
*
*/
#if !defined(___DEFS_H)
#define ___DEFS_H
#if defined(__MT__)
# define _MT
#endif
#if defined(__OS2__)
# define _RTLENTRY __stdcall
# define _USERENTRY __stdcall
#elif defined(__WIN32__)
# define _RTLENTRY __cdecl
# define _USERENTRY __cdecl
#else
# define _RTLENTRY __cdecl
# define _USERENTRY __cdecl
#endif
#if defined(__PAS__)
# define _RTLENTRYF __pascal
#else
# define _RTLENTRYF _RTLENTRY
#endif
#if defined(__FLAT__)
# define _FAR
# if defined(_BUILDRTLDLL)
# define _EXPCLASS __export
# define _EXPDATA __export
# define _EXPFUNC __export
# elif defined(_RTLDLL) && !defined(__OS2__)
# define _EXPCLASS __import
# define _EXPDATA __import
# define _EXPFUNC __import
# else
# define _EXPCLASS
# define _EXPDATA
# define _EXPFUNC
# endif
#else
# if defined(__DLL__)
# if defined(_BUILDRTLDLL)
# define _EXPCLASS __export
# elif defined(_RTLDLL) || defined(_CLASSDLL)
# define _EXPCLASS __export
# else
# define _EXPCLASS __far
# endif
# define _FAR __far
# elif defined(_RTLDLL) || defined(_CLASSDLL)
# define _EXPCLASS __export
# define _FAR __far
# else
# if defined(__TINY__) || defined(__SMALL__) ||
defined(__MEDIUM__)
# if defined(_RTLFARVTABLE)
# define _EXPCLASS __huge
# else
# define _EXPCLASS __near
# endif
# elif defined(__COMPACT__) || defined(__LARGE__)
# if defined(_RTLFARVTABLE)
# define _EXPCLASS __huge
# else
# define _EXPCLASS __far
# endif
# else
# define _EXPCLASS __huge
# endif
# define _FAR
# endif
# if defined(_BUILDRTLDLL)
# define _EXPFUNC __export
# else
# if defined(_RTLDLL) || defined(_CLASSDLL)
# define _EXPFUNC __far
# else
# define _EXPFUNC
# endif
# endif
# define _EXPDATA
#endif
#if defined(__FLAT__)
#define _EXPFUNC32 _EXPFUNC
#define _EXPFUNC16
#else
#define _EXPFUNC32
#define _EXPFUNC16 _EXPFUNC
#endif
#define _Cdecl _RTLENTRY
#define _CType _RTLENTRYF
#define _CLASSTYPE _EXPCLASS
#define _FARFUNC _EXPFUNC
#define _FARCALL _EXPFUNC __far
#if defined(__FLAT__)
# define _M_IX86 300
#endif
#if !defined(__FLAT__) && defined(__MSC)
# define __emit db
# ifdef __SMALL__
# define _M_I86SM
# endif
# ifdef __COMPACT__
# define _M_I86CM
# endif
# ifdef __MEDIUM__
# define _M_I86MM
# endif
# ifdef __LARGE__
# define _M_I86LM
# endif
# ifndef _Windows
# define _DOS
# else
# define _WINDOWS
# endif
#endif
#if defined(__cplusplus)
# define _PTRDEF(name) typedef name _FAR * P##name;
# define _REFDEF(name) typedef name _FAR & R##name;
# define _REFPTRDEF(name) typedef name _FAR * _FAR & RP##name;
# define _PTRCONSTDEF(name) typedef const name _FAR * PC##name;
# define _REFCONSTDEF(name) typedef const name _FAR & RC##name;
/*********** Obsolete definitions for OWL 1.0 *************/
# define _CLASSDEF(name) class _EXPCLASS name; \
_PTRDEF(name) \
_REFDEF(name) \
_REFPTRDEF(name) \
_PTRCONSTDEF(name) \
_REFCONSTDEF(name)
#endif
#endif /* ___DEFS_H */
#endif
#if !defined(__MEM_H)
#include <mem.h> // to get memcpy and NULL
/* mem.h
Memory manipulation functions
*/
/*
* C/C++ Run Time Library - Version 6.5
*
* Copyright (c) 1987, 1994 by Borland International
* All Rights Reserved.
*
*/
#if !defined(__MEM_H)
#define __MEM_H
#if !defined(___DEFS_H)
#include <_defs.h>
/* _defs.h
Common definitions for pointer size and calling conventions.
Calling conventions:
_RTLENTRY Specifies the calling convention used by the RTL
_USERENTRY Specifies the calling convention the RTL expects
user
compiled functions to use (for callbacks)
Export (and size for DOS) information:
_EXPCLASS Exports class if building DLL version of library
For DOS16 also provides size information
_EXPDATA Exports data if building DLL version of library
_EXPFUNC Exports function if building DLL version of
library
For DOS16 also provides size information
_FAR Promotes data pointers to far in DLLs (DOS16 only)
Obsolete versions:
_Cdecl Use _RTLENTRY
_CLASSTYPE Use _EXPCLASS
_FARFUNC Use _EXPFUNC
_FARCALL Use _EXPFUNC and declare function explicity __far
*/
/*
* C/C++ Run Time Library - Version 6.5
*
* Copyright (c) 1991, 1994 by Borland International
* All Rights Reserved.
*
*/
#if !defined(___DEFS_H)
#define ___DEFS_H
#if defined(__MT__)
# define _MT
#endif
#if defined(__OS2__)
# define _RTLENTRY __stdcall
# define _USERENTRY __stdcall
#elif defined(__WIN32__)
# define _RTLENTRY __cdecl
# define _USERENTRY __cdecl
#else
# define _RTLENTRY __cdecl
# define _USERENTRY __cdecl
#endif
#if defined(__PAS__)
# define _RTLENTRYF __pascal
#else
# define _RTLENTRYF _RTLENTRY
#endif
#if defined(__FLAT__)
# define _FAR
# if defined(_BUILDRTLDLL)
# define _EXPCLASS __export
# define _EXPDATA __export
# define _EXPFUNC __export
# elif defined(_RTLDLL) && !defined(__OS2__)
# define _EXPCLASS __import
# define _EXPDATA __import
# define _EXPFUNC __import
# else
# define _EXPCLASS
# define _EXPDATA
# define _EXPFUNC
# endif
#else
# if defined(__DLL__)
# if defined(_BUILDRTLDLL)
# define _EXPCLASS __export
# elif defined(_RTLDLL) || defined(_CLASSDLL)
# define _EXPCLASS __export
# else
# define _EXPCLASS __far
# endif
# define _FAR __far
# elif defined(_RTLDLL) || defined(_CLASSDLL)
# define _EXPCLASS __export
# define _FAR __far
# else
# if defined(__TINY__) || defined(__SMALL__) ||
defined(__MEDIUM__)
# if defined(_RTLFARVTABLE)
# define _EXPCLASS __huge
# else
# define _EXPCLASS __near
# endif
# elif defined(__COMPACT__) || defined(__LARGE__)
# if defined(_RTLFARVTABLE)
# define _EXPCLASS __huge
# else
# define _EXPCLASS __far
# endif
# else
# define _EXPCLASS __huge
# endif
# define _FAR
# endif
# if defined(_BUILDRTLDLL)
# define _EXPFUNC __export
# else
# if defined(_RTLDLL) || defined(_CLASSDLL)
# define _EXPFUNC __far
# else
# define _EXPFUNC
# endif
# endif
# define _EXPDATA
#endif
#if defined(__FLAT__)
#define _EXPFUNC32 _EXPFUNC
#define _EXPFUNC16
#else
#define _EXPFUNC32
#define _EXPFUNC16 _EXPFUNC
#endif
#define _Cdecl _RTLENTRY
#define _CType _RTLENTRYF
#define _CLASSTYPE _EXPCLASS
#define _FARFUNC _EXPFUNC
#define _FARCALL _EXPFUNC __far
#if defined(__FLAT__)
# define _M_IX86 300
#endif
#if !defined(__FLAT__) && defined(__MSC)
# define __emit db
# ifdef __SMALL__
# define _M_I86SM
# endif
# ifdef __COMPACT__
# define _M_I86CM
# endif
# ifdef __MEDIUM__
# define _M_I86MM
# endif
# ifdef __LARGE__
# define _M_I86LM
# endif
# ifndef _Windows
# define _DOS
# else
# define _WINDOWS
# endif
#endif
#if defined(__cplusplus)
# define _PTRDEF(name) typedef name _FAR * P##name;
# define _REFDEF(name) typedef name _FAR & R##name;
# define _REFPTRDEF(name) typedef name _FAR * _FAR & RP##name;
# define _PTRCONSTDEF(name) typedef const name _FAR * PC##name;
# define _REFCONSTDEF(name) typedef const name _FAR & RC##name;
/*********** Obsolete definitions for OWL 1.0 *************/
# define _CLASSDEF(name) class _EXPCLASS name; \
_PTRDEF(name) \
_REFDEF(name) \
_REFPTRDEF(name) \
_PTRCONSTDEF(name) \
_REFCONSTDEF(name)
#endif
#endif /* ___DEFS_H */
#endif
#ifndef NULL
#include <_null.h>
/* _null.h
Definition of NULL.
*/
/*
* C/C++ Run Time Library - Version 6.5
*
* Copyright (c) 1987, 1994 by Borland International
* All Rights Reserved.
*
*/
#ifndef NULL
# if !defined(__FLAT__)
# if defined(__TINY__) || defined(__SMALL__) || defined(__MEDIUM__)
# define NULL 0
# else
# define NULL 0L
# endif
# else
# if defined(__cplusplus) || defined(_Windows)
# define NULL 0
# else
# define NULL ((void *)0)
# endif
# endif
#endif
#endif
#if !defined(RC_INVOKED)
#if defined(__STDC__)
#pragma warn -nak
#endif
#endif /* !RC_INVOKED */
#ifdef __cplusplus
extern "C" {
#endif
#ifndef _STDDEF
#define _STDDEF
#ifndef _PTRDIFF_T
#define _PTRDIFF_T
#if defined(__LARGE__) || defined(__HUGE__) || defined(__COMPACT__)
typedef long ptrdiff_t;
#else
typedef int ptrdiff_t;
#endif
#endif
#ifndef _SIZE_T
#define _SIZE_T
typedef unsigned size_t;
#endif
#endif
#if !defined(__FLAT__) || defined(__DPMI32__)
void _RTLENTRY _EXPFUNC movedata(unsigned __srcseg, unsigned
__srcoff,
unsigned __dstseg, unsigned
__dstoff, size_t __n);
#endif
void _FAR * _RTLENTRY _EXPFUNC memccpy(void _FAR *__dest, const void
_FAR *__src,
int __c, size_t __n);
int _RTLENTRY _EXPFUNC memcmp(const void _FAR *__s1, const
void _FAR *__s2,
size_t __n);
void _FAR * _RTLENTRY _EXPFUNC memcpy(void _FAR *__dest, const void
_FAR *__src,
size_t __n);
int _RTLENTRY _EXPFUNC memicmp(const void _FAR *__s1, const
void _FAR *__s2,
size_t __n);
void _FAR * _RTLENTRYF _EXPFUNC memmove(void _FAR *__dest, const void
_FAR *__src,
size_t __n);
void _FAR * _RTLENTRYF _EXPFUNC memset(void _FAR *__s, int __c, size_t
__n);
#if defined(__cplusplus)
extern "C++"
{
void _FAR * _RTLENTRY _EXPFUNC32 memchr(void _FAR *__s, int
__c, size_t __n);
const void _FAR * _RTLENTRY _EXPFUNC32 memchr(const void _FAR
*__s, int __c, size_t __n);
}
#else
void _FAR * _RTLENTRY _EXPFUNC32 memchr(const void _FAR
*__s, int __c, size_t __n);
#endif
#if !defined(__STRING_H)
/* Intrinsic functions */
void _FAR * _RTLENTRY _EXPFUNC16 __memchr__(const void _FAR * __s,
int __c, size_t __n);
int _RTLENTRY _EXPFUNC16 __memcmp__(const void _FAR * __s1,
const void _FAR * __s2, size_t __n);
void _FAR * _RTLENTRY _EXPFUNC16 __memcpy__(void _FAR * __dest, const
void _FAR * __src, size_t __n);
void _FAR * _RTLENTRYF _EXPFUNC16 __memset__(void _FAR * __s, int __c,
size_t __n);
#endif
#if !defined(__FLAT__)
void _RTLENTRY _EXPFUNC movmem(const void _FAR *__src, void
_FAR *__dest,
unsigned __length);
void _RTLENTRY _EXPFUNC setmem(void _FAR *__dest,unsigned
__length, char __value);
#if !defined(__STDC__) /* NON_ANSI */
void __far * _RTLENTRY _FARCALL _fmemccpy(void __far *__dest, const
void __far *__src,
int __c, size_t __n);
void __far * _RTLENTRY _FARCALL _fmemchr(const void __far *__s, int
__c, size_t __n);
int _RTLENTRY _FARCALL _fmemcmp(const void __far *__s1,
const void __far *__s2,
size_t __n);
void __far * _RTLENTRY _FARCALL _fmemcpy(void __far *__dest, const
void __far *__src,
size_t __n);
int _RTLENTRY _FARCALL _fmemicmp(const void __far *__s1,
const void __far *__s2,
size_t __n);
void __far * _RTLENTRY _FARCALL _fmemmove(void __far *__dest, const
void __far *__src,
size_t __n);
void __far * _RTLENTRY _FARCALL _fmemset(void __far *__s, int __c,
size_t __n);
void _RTLENTRY _FARCALL _fmovmem(const void __far *__src,
void __far *__dest,
unsigned __length);
void _RTLENTRY _FARCALL _fsetmem(void __far *__dest, unsigned
__length,
char __value);
#endif /* __STDC__ */
#else /* defined __FLAT__ */
#define movmem(src,dest,length) (void)memmove(dest,src,length)
#define setmem(dest,length,value) (void)memset(dest,value,length)
#if !defined(__STDC__) /* NON_ANSI */
#define _fmemccpy memccpy
#define _fmemchr memchr
#define _fmemcmp memcmp
#define _fmemcpy memcpy
#define _fmemicmp memicmp
#define _fmemmove memmove
#define _fmemset memset
#define _fmovmem movmem
#define _fsetmem setmem
#endif /* __STDC__ */
#endif /* __FLAT__ */
#ifdef __cplusplus
}
#endif
#if !defined(RC_INVOKED)
#if defined(__STDC__)
#pragma warn .nak
#endif
#endif /* !RC_INVOKED */
#endif /* __MEM_H */
#endif
#if !defined(RC_INVOKED)
#pragma option -a- // byte packing
#if defined(__BCOPT__)
#if !defined(_RTL_ALLOW_po) && !defined(__FLAT__)
#pragma option -po- // disable Object data calling convention
#endif
#endif
#if !defined(__TINY__)
#pragma option -RT
#endif
#pragma option -Vo- // set standard C++ options
#if defined(__STDC__)
#pragma warn -nak
#endif
#endif /* !RC_INVOKED */
// Definition of EOF must match the one in <stdio.h>
#define EOF (-1)
// extract a char from int i, ensuring that zapeof(EOF) != EOF
#define zapeof(i) ((unsigned char)(i))
typedef long streampos;
typedef long streamoff;
_CLASSDEF(ios)
_CLASSDEF(streambuf)
_CLASSDEF(istream)
_CLASSDEF(ostream)
_CLASSDEF(iostream)
_CLASSDEF(istream_withassign)
_CLASSDEF(ostream_withassign)
_CLASSDEF(iostream_withassign)
class _EXPCLASS ios {
public:
// stream status bits
enum io_state {
goodbit = 0x00, // no bit set: all is ok
eofbit = 0x01, // at end of file
failbit = 0x02, // last I/O operation failed
badbit = 0x04, // invalid operation attempted
hardfail = 0x80 // unrecoverable error
};
// stream operation mode
enum open_mode {
in = 0x01, // open for reading
out = 0x02, // open for writing
ate = 0x04, // seek to eof upon original open
app = 0x08, // append mode: all additions at eof
trunc = 0x10, // truncate file if already exists
nocreate = 0x20, // open fails if file doesn't exist
noreplace= 0x40, // open fails if file already exists
binary = 0x80 // binary (not text) file
};
// stream seek direction
enum seek_dir { beg=0, cur=1, end=2 };
// formatting flags
enum {
skipws = 0x0001, // skip whitespace on input
left = 0x0002, // left-adjust output
right = 0x0004, // right-adjust output
internal = 0x0008, // padding after sign or base indicator
dec = 0x0010, // decimal conversion
oct = 0x0020, // octal conversion
hex = 0x0040, // hexadecimal conversion
showbase = 0x0080, // use base indicator on output
showpoint = 0x0100, // force decimal point (floating output)
uppercase = 0x0200, // upper-case hex output
showpos = 0x0400, // add '+' to positive integers
scientific= 0x0800, // use 1.2345E2 floating notation
fixed = 0x1000, // use 123.45 floating notation
unitbuf = 0x2000, // flush all streams after insertion
stdio = 0x4000 // flush stdout, stderr after insertion
};
// constants for second parameter of seft()
static const long basefield; // dec | oct | hex
static const long adjustfield; // left | right | internal
static const long floatfield; // scientific | fixed
// constructor, destructor
_RTLENTRY ios(streambuf _FAR *);
virtual _RTLENTRY ~ios();
// for reading/setting/clearing format flags
long _RTLENTRY flags();
long _RTLENTRY flags(long);
long _RTLENTRY setf(long _setbits, long _field);
long _RTLENTRY setf(long);
long _RTLENTRY unsetf(long);
// reading/setting field width
int _RTLENTRY width();
int _RTLENTRY width(int);
// reading/setting padding character
char _RTLENTRY fill();
char _RTLENTRY fill(char);
// reading/setting digits of floating precision
int _RTLENTRY precision(int);
int _RTLENTRY precision();
// reading/setting ostream tied to this stream
ostream _FAR * _RTLENTRY tie(ostream _FAR *);
ostream _FAR * _RTLENTRY tie();
// find out about current stream state
int _RTLENTRY rdstate(); // return the stream state
int _RTLENTRY eof(); // non-zero on end of file
int _RTLENTRY fail(); // non-zero if an operation
failed
int _RTLENTRY bad(); // non-zero if error occurred
int _RTLENTRY good(); // non-zero if no state bits
set
void _RTLENTRY clear(int = 0); // set the stream state
_RTLENTRY operator void _FAR * (); // zero if state failed
int _RTLENTRY operator! (); // non-zero if state failed
streambuf _FAR * _RTLENTRY rdbuf(); // get the assigned
streambuf
// for declaring additional flag bits and user words
static long _RTLENTRY bitalloc(); // acquire a new flag bit, value
returned
static int _RTLENTRY xalloc(); // acquire a new user word, index
returned
long _FAR & _RTLENTRY iword(int); // return the nth user word
as an int
void _FAR * _FAR & _RTLENTRY pword(int); // return the nth
user word as a pointer
static void _RTLENTRY sync_with_stdio();
// obsolete, for streams 1.2 compatibility
int _RTLENTRY skip(int);
protected:
// additional state flags for ispecial and ospecial
enum { skipping = 0x100, tied = 0x200 };
streambuf _FAR * bp; // the associated streambuf
ostream _FAR * x_tie; // the tied ostream, if any
int state; // status bits
int ispecial; // istream status bits ***
int ospecial; // ostream status bits ***
long x_flags; // formatting flag bits
int x_precision; // floating-point precision on output
int x_width; // field width on output
int x_fill; // padding character on output
int isfx_special; // unused ***
int osfx_special; // unused ***
int delbuf; // unused ***
int assign_private; // unused ***
/*
* The data members marked with *** above are not documented in the
AT&T
* release of streams, so we cannot guarantee compatibility with any
* other streams release in the use or values of these data members.
* If you can document any expected behavior of these data members, we
* will try to adjust our implementation accordingly.
*/
_RTLENTRY ios(); // null constructor, does not
initialize
void _RTLENTRY init(streambuf _FAR *); // the actual
initialization
void _RTLENTRY setstate(int); // set all status bits
static void _RTLENTRY (*stdioflush)();
private:
// for extra flag bits and user words
static long nextbit;
static int usercount;
union ios_user_union _FAR *userwords;
int nwords;
void _RTLENTRY usersize(int);
// these declarations prevent automatic copying of an ios
_RTLENTRY ios(ios _FAR &); // declared but not
defined
void _RTLENTRY operator= (ios _FAR &); // declared but not
defined
};
inline streambuf _FAR * _RTLENTRY ios::rdbuf() { return bp; }
inline ostream _FAR * _RTLENTRY ios::tie() { return x_tie; }
inline char _RTLENTRY ios::fill() { return (char)x_fill; }
inline int _RTLENTRY ios::precision() { return x_precision; }
inline int _RTLENTRY ios::rdstate() { return state; }
inline int _RTLENTRY ios::eof() { return state & eofbit; }
inline int _RTLENTRY ios::fail()
{ return state & (failbit | badbit |
hardfail); }
inline int _RTLENTRY ios::bad() { return state & (badbit |
hardfail); }
inline int _RTLENTRY ios::good() { return state == 0; }
inline long _RTLENTRY ios::flags() { return x_flags; }
inline int _RTLENTRY ios::width() { return x_width; }
inline int _RTLENTRY ios::width(int _w)
{ int _i = x_width; x_width = _w; return _i; }
inline char _RTLENTRY ios::fill(char _c)
{ char _x = (char)x_fill; x_fill = _c; return
_x; }
inline int _RTLENTRY ios::precision(int _p)
{ int _x = x_precision; x_precision = _p;
return _x; }
inline _RTLENTRY ios::operator void _FAR *()
{ return fail() ? 0 : this; }
inline int _RTLENTRY ios::operator! () { return fail(); }
class _EXPCLASS streambuf {
public:
// constructors and destructors
_RTLENTRY streambuf(); // make empty streambuf
_RTLENTRY streambuf(char _FAR *, int); // make streambuf with
// given char array
virtual _RTLENTRY ~streambuf();
// use the provided char array for the buffer if possible
virtual streambuf _FAR * _RTLENTRY setbuf(char _FAR *, int);
// obsolete, for streams 1.2 compatibility
streambuf _FAR * _RTLENTRY setbuf(char _FAR *, int, int);
// getting (extracting) characters
int _RTLENTRY sgetc(); // peek at next char
int _RTLENTRY snextc(); // advance to and return next
char
int _RTLENTRY sbumpc(); // return current char and
advance
void _RTLENTRY stossc(); // advance to next character
int _RTLENTRY sgetn(char _FAR *, int); // get next n chars
virtual int _RTLENTRY do_sgetn(char _FAR *, int); // implementation
of sgetn
virtual int _RTLENTRY underflow(); // fill empty buffer
int _RTLENTRY sputbackc(char); // return char to input
virtual int _RTLENTRY pbackfail(int); // implementation of sputbackc
int _RTLENTRY in_avail(); // number of avail chars in
buffer
// putting (inserting) characters
int _RTLENTRY sputc(int); // put one char
int _RTLENTRY sputn(const char _FAR *, int); // put n chars
from string
virtual int _RTLENTRY do_sputn(const char _FAR * s, int n); //
implementation of sputn
virtual int _RTLENTRY overflow(int = EOF); // flush buffer and make
more room
int _RTLENTRY out_waiting(); // number of unflushed
chars
// moving around in stream
virtual streampos _RTLENTRY seekoff(streamoff, ios::seek_dir,
int = (ios::in | ios::out));
virtual streampos _RTLENTRY seekpos(streampos, int = (ios::in |
ios::out));
virtual int _RTLENTRY sync();
#if defined(__FLAT__)
// locking and unlocking file handle associated with stream
virtual void _RTLENTRY lock();
virtual void _RTLENTRY unlock();
#endif
void _RTLENTRY dbp(); // for debugging streambuf
implementations
protected:
char _FAR * _RTLENTRY base(); // return start of buffer area
char _FAR * _RTLENTRY ebuf(); // return end+1 of buffer area
int _RTLENTRY blen(); // return length of buffer area
char _FAR * _RTLENTRY pbase(); // return start of put area
char _FAR * _RTLENTRY pptr(); // return next location in put area
char _FAR * _RTLENTRY epptr(); // return end+1 of put area
char _FAR * _RTLENTRY eback(); // return base of putback section
of get area
char _FAR * _RTLENTRY gptr(); // return next location in get area
char _FAR * _RTLENTRY egptr(); // return end+1 of get area
void _RTLENTRY setp(char _FAR *, char _FAR *); // initialize
the put pointers
void _RTLENTRY setg(char _FAR *, char _FAR *, char _FAR *); //
initialize the get pointers
void _RTLENTRY pbump(int); // advance the put pointer
void _RTLENTRY gbump(int); // advance the get pointer
void _RTLENTRY setb(char _FAR *, char _FAR *, int = 0 ); //
set the buffer area
void _RTLENTRY unbuffered(int);// set the buffering state
int _RTLENTRY unbuffered(); // non-zero if not buffered
int _RTLENTRY allocate(); // set up a buffer area
virtual int _RTLENTRY doallocate(); // implementation of allocate
private:
short alloc_; // non-zero if buffer should be deleted
short unbuf_; // non-zero if unbuffered
char _FAR * base_; // start of buffer area
char _FAR * ebuf_; // end+1 of buffer area
char _FAR * pbase_; // start of put area
char _FAR * pptr_; // next put location
char _FAR * epptr_; // end+1 of put area
char _FAR * eback_; // base of putback section of get area
char _FAR * gptr_; // next get location
char _FAR * egptr_; // end+1 of get area
int _RTLENTRY do_snextc(); // implementation of snextc
// these declarations prevent copying of a streambuf
_RTLENTRY streambuf(streambuf _FAR &); // declared but
not defined
void _RTLENTRY operator= (streambuf _FAR &); // declared but
not defined
};
inline char _FAR * _RTLENTRY streambuf::base() { return base_; }
inline char _FAR * _RTLENTRY streambuf::pbase() { return pbase_; }
inline char _FAR * _RTLENTRY streambuf::pptr() { return pptr_; }
inline char _FAR * _RTLENTRY streambuf::epptr() { return epptr_; }
inline char _FAR * _RTLENTRY streambuf::gptr() { return gptr_; }
inline char _FAR * _RTLENTRY streambuf::egptr() { return egptr_; }
inline char _FAR * _RTLENTRY streambuf::eback() { return eback_; }
inline char _FAR * _RTLENTRY streambuf::ebuf() { return ebuf_; }
inline int _RTLENTRY streambuf::unbuffered() { return unbuf_; }
inline int _RTLENTRY streambuf::blen() { return (int)(ebuf_ -
base_);}
inline void _RTLENTRY streambuf::pbump(int _n) { pptr_ += _n; }
inline void _RTLENTRY streambuf::gbump(int _n) { gptr_ += _n; }
inline void _RTLENTRY streambuf::unbuffered(int _unb) { unbuf_ =
(short)(_unb != 0); }
inline int _RTLENTRY streambuf::in_avail()
{ return (egptr_ > gptr_) ? (int)(egptr_ - gptr_) :
0; }
inline int _RTLENTRY streambuf::out_waiting()
{ return pptr_ ? (int)(pptr_ - pbase_) : 0; }
inline int _RTLENTRY streambuf::allocate() {
return (base_ || unbuf_) ? 0 : doallocate();
}
inline int _RTLENTRY streambuf::sgetc() {
return (gptr_ >= egptr_) ? underflow() :
(unsigned char)(*gptr_);
}
inline int _RTLENTRY streambuf::snextc() {
return (! gptr_ || (++gptr_ >= egptr_)) ?
do_snextc() :
(unsigned char)(*gptr_);
}
inline int _RTLENTRY streambuf::sbumpc() {
return (gptr_ >= egptr_ && underflow() == EOF) ?
EOF :
(unsigned char)(*gptr_++);
}
inline void _RTLENTRY streambuf::stossc() {
if( gptr_ >= egptr_ ) underflow();
else ++gptr_;
}
inline int _RTLENTRY streambuf::sputbackc(char _c) {
return (gptr_ > eback_) ?
(unsigned char)(*--gptr_ = _c) :
pbackfail(_c);
}
inline int _RTLENTRY streambuf::sputc(int _c) {
return (pptr_ >= epptr_) ?
overflow((unsigned char)_c) :
(unsigned char)(*pptr_++ = (char)_c);
}
#ifdef _BIG_INLINE_
inline int _RTLENTRY streambuf::sputn(const char _FAR * _s, int _n) {
if( _n <= (epptr_ - pptr_) ) {
memcpy(pptr_, _s, _n);
pbump(_n);
return _n;
}
return do_sputn(_s, _n);
}
inline int _RTLENTRY streambuf::sgetn(char _FAR * _s, int _n) {
if( _n <= (egptr_ - gptr_) ) {
memcpy(_s, gptr_, _n);
gbump(_n);
return _n;
}
return do_sgetn(_s, _n);
}
#endif
#if defined(__FLAT__)
inline void _RTLENTRY streambuf::lock() {}
inline void _RTLENTRY streambuf::unlock() {}
#endif
class _EXPCLASS istream : virtual public ios {
public:
// constructor and destructor
_RTLENTRY istream(streambuf _FAR *);
virtual _RTLENTRY ~istream();
// Obsolete constructors, for streams 1.2 compatibility
// obsolete: set skip via format, tie via tie() function
_RTLENTRY istream(streambuf _FAR *, int _sk, ostream _FAR *
_t=0);
// obsolete: use strstream
_RTLENTRY istream(int _sz, char _FAR *, int _sk=1);
// obsolete: use fstream
_RTLENTRY istream(int _fd, int _sk=1, ostream _FAR * _t=0);
int _RTLENTRY ipfx(int = 0); // input prefix function
int _RTLENTRY ipfx0(); // same as ipfx(0)
int _RTLENTRY ipfx1(); // same as ipfx(1)
void _RTLENTRY isfx() { } // unused input suffix function
// set/read the get pointer's position
istream _FAR & _RTLENTRY seekg(streampos);
istream _FAR & _RTLENTRY seekg(streamoff, ios::seek_dir);
streampos _RTLENTRY tellg();
int _RTLENTRY sync();
/*
* Unformatted extraction operations
*/
// extract characters into an array
istream _FAR & _RTLENTRY get( char _FAR *, int, char =
'\n');
istream _FAR & _RTLENTRY get( signed char _FAR *, int, char =
'\n');
istream _FAR & _RTLENTRY get(unsigned char _FAR *, int, char =
'\n');
istream _FAR & _RTLENTRY read( char _FAR *, int);
istream _FAR & _RTLENTRY read( signed char _FAR *, int);
istream _FAR & _RTLENTRY read(unsigned char _FAR *, int);
// extract characters into an array up to termination char
istream _FAR & _RTLENTRY getline( char _FAR *, int, char =
'\n');
istream _FAR & _RTLENTRY getline( signed char _FAR *, int, char =
'\n');
istream _FAR & _RTLENTRY getline(unsigned char _FAR *, int, char =
'\n');
// extract characters into a streambuf up to termination char
istream _FAR & _RTLENTRY get(streambuf _FAR &, char = '\n');
// extract a single character
istream _FAR & _RTLENTRY get( char _FAR &);
istream _FAR & _RTLENTRY get( signed char _FAR &);
istream _FAR & _RTLENTRY get(unsigned char _FAR &);
int _RTLENTRY get();
int _RTLENTRY peek(); // return next char without
extraction
int _RTLENTRY gcount(); // number of unformatted chars last
extracted
istream _FAR & _RTLENTRY putback(char); // push back char into
input
// extract and discard chars but stop at delim
istream _FAR & _RTLENTRY ignore(int = 1, int = EOF);
/*
* Formatted extraction operations
*/
istream _FAR & _RTLENTRY operator>> (istream _FAR & (_RTLENTRY
*_f)(istream _FAR &));
istream _FAR & _RTLENTRY operator>> (ios _FAR & (_RTLENTRY
*_f)(ios _FAR &) );
istream _FAR & _RTLENTRY operator>> ( char _FAR *);
istream _FAR & _RTLENTRY operator>> ( signed char _FAR *);
istream _FAR & _RTLENTRY operator>> (unsigned char _FAR *);
istream _FAR & _RTLENTRY operator>> ( char _FAR &);
istream _FAR & _RTLENTRY operator>> ( signed char _FAR &);
istream _FAR & _RTLENTRY operator>> (unsigned char _FAR &);
istream _FAR & _RTLENTRY operator>> (short _FAR &);
istream _FAR & _RTLENTRY operator>> (int _FAR &);
istream _FAR & _RTLENTRY operator>> (long _FAR &);
istream _FAR & _RTLENTRY operator>> (unsigned short _FAR &);
istream _FAR & _RTLENTRY operator>> (unsigned int _FAR &);
istream _FAR & _RTLENTRY operator>> (unsigned long _FAR &);
istream _FAR & _RTLENTRY operator>> (float _FAR &);
istream _FAR & _RTLENTRY operator>> (double _FAR &);
istream _FAR & _RTLENTRY operator>> (long double _FAR &);
// extract from this istream, insert into streambuf
istream _FAR & _RTLENTRY operator>> (streambuf _FAR *);
protected:
_RTLENTRY istream();
void _RTLENTRY eatwhite(); // extract consecutive
whitespace
private:
int gcount_; // chars extracted by last unformatted operation
signed char _RTLENTRY do_get(); // implementation of get
};
inline int _RTLENTRY istream::gcount() { return gcount_; }
inline int _RTLENTRY istream::ipfx0() { return ipfx(0); }
inline int _RTLENTRY istream::ipfx1() { return ipfx(1); }
#ifdef _BIG_INLINE_
inline istream _FAR & _RTLENTRY istream::operator>> (char _FAR & _c) {
if( ipfx0() )
_c = bp->in_avail() ? bp->sbumpc() : do_get();
return *this;
}
inline istream _FAR & _RTLENTRY istream::operator>> (signed char _FAR
& _c) {
if( ipfx0() )
_c = bp->in_avail() ? bp->sbumpc() : do_get();
return *this;
}
inline istream _FAR & _RTLENTRY istream::operator>> (unsigned char
_FAR & _c) {
if( ipfx0() )
_c = bp->in_avail() ? bp->sbumpc() : do_get();
return *this;
}
#endif
inline istream _FAR & _RTLENTRY istream::operator>> (signed char _FAR
* _p) {
return *this >> (char _FAR *)_p;
}
inline istream _FAR & _RTLENTRY istream::operator>> (unsigned char
_FAR * _p) {
return *this >> (char _FAR *)_p;
}
inline istream _FAR & _RTLENTRY istream::get(signed char _FAR * _p,
int _l, char _t) {
return get((char _FAR *)_p, _l, _t);
}
inline istream _FAR & _RTLENTRY istream::get(unsigned char _FAR * _p,
int _l, char _t) {
return get((char _FAR *)_p, _l, _t);
}
inline istream _FAR & _RTLENTRY istream::read(signed char _FAR * _p,
int _l) {
return read((char _FAR *)_p, _l);
}
inline istream _FAR & _RTLENTRY istream::read(unsigned char _FAR *
_p, int _l) {
return read((char _FAR *)_p, _l);
}
inline istream _FAR & _RTLENTRY istream::getline(signed char _FAR *
_p, int _l, char _t) {
return getline((char _FAR *) _p, _l, _t);
}
inline istream _FAR & _RTLENTRY istream::getline(unsigned char _FAR *
_p, int _l, char _t) {
return getline((char _FAR *) _p, _l, _t);
}
inline int _RTLENTRY istream::sync() { return bp->sync(); }
inline istream _FAR & _RTLENTRY istream::operator>> (istream _FAR &
(_RTLENTRY *_f)(istream _FAR &)) {
return (*_f)(*this);
}
#ifdef _BIG_INLINE_
inline istream _FAR & _RTLENTRY istream::get(char _FAR & _c) {
if( ipfx1() )
if( bp->in_avail() ) {
gcount_ = 1;
_c = bp->sbumpc();
}
else _c = do_get();
return *this;
}
inline istream _FAR & _RTLENTRY istream::get(signed char _FAR & _c) {
if( ipfx1() )
if( bp->in_avail()) {
gcount_ = 1;
_c = bp->sbumpc();
}
else _c = do_get();
return *this;
}
inline istream _FAR & _RTLENTRY istream::get(unsigned char _FAR & _c)
{
if( ipfx1() )
if( bp->in_avail() ) {
gcount_ = 1;
_c = bp->sbumpc();
}
else _c = do_get();
return *this;
}
inline int _RTLENTRY istream::get() {
if( ipfx1() ) {
int _c = bp->sbumpc();
if( _c == EOF ) setstate(eofbit);
else gcount_ = 1;
return _c;
}
else return EOF;
}
#endif
inline int _RTLENTRY istream::peek() { return ipfx1() ? bp->sgetc() :
EOF; }
class _EXPCLASS ostream : virtual public ios {
public:
// constructors and destructor
_RTLENTRY ostream(streambuf _FAR *);
virtual _RTLENTRY ~ostream();
// Obsolete constructors, for streams 1.2 compatibility
_RTLENTRY ostream(int _fd); // obsolete, use fstream
_RTLENTRY ostream(int _sz, char _FAR *); // obsolete, use
strstream
int _RTLENTRY opfx(); // output prefix function
void _RTLENTRY osfx(); // output suffix function
ostream _FAR & _RTLENTRY flush();
// set/read the put pointer's position
ostream _FAR & _RTLENTRY seekp(streampos);
ostream _FAR & _RTLENTRY seekp(streamoff, ios::seek_dir);
streampos _RTLENTRY tellp();
/*
* Unformatted insertion operations
*/
ostream _FAR & _RTLENTRY put( char); // insert the
character
ostream _FAR & _RTLENTRY put(signed char); // insert the
character
ostream _FAR & _RTLENTRY put(unsigned char); // insert the
character
ostream _FAR & _RTLENTRY write(const char _FAR *, int);
// insert the string
ostream _FAR & _RTLENTRY write(const signed char _FAR *, int);
// insert the string
ostream _FAR & _RTLENTRY write(const unsigned char _FAR *, int);
// insert the string
/*
* Formatted insertion operations
*/
// insert the character
ostream _FAR & _RTLENTRY operator<< ( char);
ostream _FAR & _RTLENTRY operator<< ( signed char);
ostream _FAR & _RTLENTRY operator<< (unsigned char);
// for the following, insert character representation of numeric
value
ostream _FAR & _RTLENTRY operator<< (short);
ostream _FAR & _RTLENTRY operator<< (unsigned short);
ostream _FAR & _RTLENTRY operator<< (int);
ostream _FAR & _RTLENTRY operator<< (unsigned int);
ostream _FAR & _RTLENTRY operator<< (long);
ostream _FAR & _RTLENTRY operator<< (unsigned long);
ostream _FAR & _RTLENTRY operator<< (float);
ostream _FAR & _RTLENTRY operator<< (double);
ostream _FAR & _RTLENTRY operator<< (long double);
// insert the null-terminated string
ostream _FAR & _RTLENTRY operator<< (const char _FAR *);
ostream _FAR & _RTLENTRY operator<< (const signed char _FAR *);
ostream _FAR & _RTLENTRY operator<< (const unsigned char _FAR *);
// insert character representation of the value of the pointer
ostream _FAR & _RTLENTRY operator<< (void _FAR *);
// extract from streambuf, insert into this ostream
ostream _FAR & _RTLENTRY operator<< (streambuf _FAR *);
// manipulators
ostream _FAR & _RTLENTRY operator<< (ostream _FAR & (_RTLENTRY
*_f)(ostream _FAR &));
ostream _FAR & _RTLENTRY operator<< (ios _FAR & (_RTLENTRY
*_f)(ios _FAR &));
protected:
int _RTLENTRY do_opfx(); // implementation of opfx
void _RTLENTRY do_osfx(); // implementation of osfx
_RTLENTRY ostream();
private:
void _RTLENTRY outstr(const char _FAR *, const char _FAR *);
};
inline int _RTLENTRY ostream::opfx() { return ospecial ? do_opfx() :
1; }
inline void _RTLENTRY ostream::osfx() { if( x_flags & (stdio |
unitbuf) ) do_osfx(); }
#ifdef _BIG_INLINE_
inline ostream _FAR & _RTLENTRY ostream::operator<< (char _c) {
if( opfx() )
if( bp->sputc(_c) == EOF ) setstate(badbit);
osfx();
return *this;
}
#endif
inline ostream _FAR & _RTLENTRY ostream::operator<< (signed char _c) {
return *this << (char)_c;
}
inline ostream _FAR & _RTLENTRY ostream::operator<< (unsigned char _c)
{
return *this << (char)_c;
}
inline ostream _FAR & _RTLENTRY ostream::operator<< (const char _FAR *
_s) {
outstr(_s, (const char _FAR *)0);
return *this;
}
inline ostream _FAR & _RTLENTRY ostream::operator<< (const signed char
_FAR * _s) {
outstr((const char _FAR *)_s, (const char _FAR *)0);
return *this;
}
inline ostream _FAR & _RTLENTRY ostream::operator<< (const unsigned
char _FAR * _s) {
outstr((const char _FAR *)_s, (const char _FAR *)0);
return *this;
}
inline ostream _FAR & _RTLENTRY ostream::operator<< (short _i)
{ return *this << (long) _i; }
inline ostream _FAR & _RTLENTRY ostream::operator<< (unsigned short
_i)
{ return *this << (unsigned long) _i; }
inline ostream _FAR & _RTLENTRY ostream::operator<< (int _i)
{ return *this << (long) _i; }
inline ostream _FAR & _RTLENTRY ostream::operator<< (unsigned int _i)
{ return *this << (unsigned long) _i; }
inline ostream _FAR & _RTLENTRY ostream::operator<< (float _f)
{ return *this << (long double) _f; }
inline ostream _FAR & _RTLENTRY ostream::operator<< (double _d)
{ return *this << (long double) _d; }
inline ostream _FAR & _RTLENTRY ostream::operator<< (ostream _FAR &
(_RTLENTRY *_f)(ostream _FAR &))
{ return (*_f)(*this); }
inline ostream _FAR & _RTLENTRY ostream::write(const signed char _FAR
* _s, int _n)
{ return write((const char _FAR *)_s, _n); }
inline ostream _FAR & _RTLENTRY ostream::write(const unsigned char
_FAR * _s, int _n)
{ return write((const char _FAR *)_s, _n); }
inline ostream _FAR & _RTLENTRY ostream::put(char _c) {
if( bp->sputc(_c) == EOF ) setstate(badbit);
return *this;
}
inline ostream _FAR & _RTLENTRY ostream::put(signed char _c)
{ return put((char) _c); }
inline ostream _FAR & _RTLENTRY ostream::put(unsigned char _c)
{ return put((char) _c); }
#ifdef _BIG_INLINE_
inline ostream _FAR & _RTLENTRY ostream::write(const char _FAR * _s,
int _n) {
if( ! fail() )
if( bp->sputn(_s, _n) != _n )
setstate(badbit);
return *this;
}
#endif
class _EXPCLASS iostream : public istream, public ostream {
public:
_RTLENTRY iostream(streambuf _FAR *);
virtual _RTLENTRY ~iostream();
protected:
_RTLENTRY iostream();
};
class _EXPCLASS istream_withassign : public istream {
public:
// does no initialization
_RTLENTRY istream_withassign();
virtual _RTLENTRY ~istream_withassign();
// gets buffer from istream and does entire initialization
istream_withassign _FAR & _RTLENTRY operator= (istream _FAR &);
// associates streambuf with stream and does entire initialization
istream_withassign _FAR & _RTLENTRY operator= (streambuf _FAR *);
};
class _EXPCLASS ostream_withassign : public ostream {
public:
// does no initialization
_RTLENTRY ostream_withassign();
virtual _RTLENTRY ~ostream_withassign();
// gets buffer from istream and does entire initialization
ostream_withassign _FAR & _RTLENTRY operator= (ostream _FAR &);
// associates streambuf with stream and does entire initialization
ostream_withassign _FAR & _RTLENTRY operator= (streambuf _FAR *);
};
class _EXPCLASS iostream_withassign : public iostream {
public:
// does no initialization
_RTLENTRY iostream_withassign();
virtual _RTLENTRY ~iostream_withassign();
// gets buffer from stream and does entire initialization
iostream_withassign _FAR & _RTLENTRY operator= (ios _FAR &);
// associates streambuf with stream and does entire initialization
iostream_withassign _FAR & _RTLENTRY operator= (streambuf _FAR *);
};
#if defined(__FLAT__)
/*
* The predefined streams
*/
extern istream_withassign _RTLENTRY _EXPDATA cin;
extern ostream_withassign _RTLENTRY _EXPDATA cout;
extern ostream_withassign _RTLENTRY _EXPDATA cerr;
extern ostream_withassign _RTLENTRY _EXPDATA clog;
/*
* Manipulators
*/
ostream _FAR & _RTLENTRY _EXPFUNC endl(ostream _FAR &); // insert
newline and flush
ostream _FAR & _RTLENTRY _EXPFUNC ends(ostream _FAR &); // insert
null to terminate string
ostream _FAR & _RTLENTRY _EXPFUNC flush(ostream _FAR &);// flush the
ostream
ios _FAR & _RTLENTRY _EXPFUNC dec(ios _FAR &); // set
conversion base to decimal
ios _FAR & _RTLENTRY _EXPFUNC hex(ios _FAR &); // set
conversion base to hexadecimal
ios _FAR & _RTLENTRY _EXPFUNC oct(ios _FAR &); // set
conversion base to octal
istream _FAR & _RTLENTRY _EXPFUNC ws(istream _FAR &); // extract
whitespace characters
ios& _RTLENTRY _EXPFUNC lock(ios&); // lock file handle
ios& _RTLENTRY _EXPFUNC unlock(ios&); // unlock file
handle
#else /* __FLAT__ */
/*
* The predefined streams
*/
extern istream_withassign _RTLENTRY cin;
extern ostream_withassign _RTLENTRY cout;
extern ostream_withassign _RTLENTRY cerr;
extern ostream_withassign _RTLENTRY clog;
/*
* Manipulators
*/
ostream _FAR & _RTLENTRY endl(ostream _FAR &); // insert newline and
flush
ostream _FAR & _RTLENTRY ends(ostream _FAR &); // insert null to
terminate string
ostream _FAR & _RTLENTRY flush(ostream _FAR &);// flush the ostream
ios _FAR & _RTLENTRY dec(ios _FAR &); // set conversion
base to decimal
ios _FAR & _RTLENTRY hex(ios _FAR &); // set conversion
base to hexadecimal
ios _FAR & _RTLENTRY oct(ios _FAR &); // set conversion
base to octal
istream _FAR & _RTLENTRY ws(istream _FAR &); // extract whitespace
characters
ios& _RTLENTRY lock(ios&); // lock file handle
ios& _RTLENTRY unlock(ios&); // unlock file handle
#endif
#if !defined(__FLAT__)
/*
* Initialization call for Easy Windows
*/
extern "C" void _RTLENTRY _InitEasyWin(void);
#endif
#if !defined(RC_INVOKED)
#pragma option -Vo. // restore user C++ options
#if !defined(__TINY__)
#pragma option -RT.
#endif
#if defined(__BCOPT__)
#if !defined(_RTL_ALLOW_po) && !defined(__FLAT__)
#pragma option -po. // restore Object data calling convention
#endif
#endif
#pragma option -a. // restore default packing
#if defined(__STDC__)
#pragma warn .nak
#endif
#endif /* !RC_INVOKED */
#endif /* __IOSTREAM_H */
void main() {
cout << "Hello, World!" }
------------------------------------------------------
_This_ is really what is being compiled by your C++ compiler (well,
something similar...your exact header files depend on the compiler you
have :)...the preprocessor only expands those "#include" directives by
automatically including the code...and I may have missed an "#include"
or two here...even snipping out all the comments, it's an unholy,
messy monster of a program...
Thus, in fact, the C++ program you've given is _monsterously_ bigger
than the ASM equivalent...the LOC count ain't even worth
comparing...and all that nonsense _IS_ required by the C++
compiler...try leaving out the "#include <iostream.h>" and see if
it'll work...
Now, you may want to claim "but I didn't write those header
files"...true enough...but the argument was that "C requires less LOC
than ASM" (that is, if I leave your completely inability to tell the
difference between C and C++ in there :)...patently NOT true...
ASM actually also has the lower LOC count too...the sole difference
here is that the ASM program was written _solely_ by yourself...while
for the C++ program, you depended on some pre-written library
routines...
Well, works both ways...you can use pre-written ASM library routines
(such as the HLA "Hello, World!"...which by using similar include
files and library routines comes out at around the same size as the
Pascal "Hello, world!" would)...and, conversely, you could try writing
this C++ code without using the standard library...try that
sometime...then you'll immediately realise:
1. C++ has no "portable" I/O routines...basically, because it has no
native I/O at all...
2. The amount of code required to do the _exact same job_ as the ASM
version (that is, actually 100% equivalent programs...so if you're not
depending on library routines for the ASM then you're not allowed to
depend on them for C++...and vice versa) is MORE than you'd need for
the ASM version...
3. Due to the lack of any I/O routines then it would, in fact, be
quite _impossible_ to write a "pure" C++ program that even does
something as basic as "Hello, world"...you _must_ rely on the OS API
or on library routines (which only call the OS API on your
behalf...but the added layer of "indirection" allows these library
routines to be "portable" so that your program would be "portable" to
other OSes...mind you, this _does_ come at a cost...the extra layer of
indirection means more source code lines, a larger file size and worse
performance...to do _exactly the same thing_ ASM does in _fewer_
source code lines, producing a vastly smaller and vastly faster
executable)...
Now, you may argue that due to the existence of the library routines,
none of this is your concern because you _are_ able to exploit them to
reduce your programming effort...it's false to suggest that you just
"can't" use them for no particular reason...
Indeed, you're absolutely correct...but the _EXACT SAME THING APPLIES
TO ASM_...
Sorry, as always, wrong on all counts...heck, you couldn't even call
your C++ program a C++ program but mixed it up with "C" instead...
Anyway, Sage...is something in particular bothering you? It seems odd
that you waste your time trying to just stir up trouble and
resentment...when someone starts Marquis de Sade self-abuse, there's
often a further reason for them tormenting themselves so...the world
isn't actually out to get you, you know...if something's bothering you
then, in fact, you'd probably find a very sympathetic and accomodating
audience, in truth...the snapping and biting is only because you're
attacking first...not because anyone actually has any real problems
with you or anything daft like that...
Beth :)
wolfgang kern
Hi Beth!
| > I think Randy's HLA is already more HLL than ASM,
| > even it can be used to create true, but restricted ASM-code.
| Yes, on some scores, HLA _exceeds_ some HLLs...but, at the same time,
| it doesn't do this by forsaking the low-level but by _supplementing_
| it with HLL-like features...
Fine, as long it produces equal code ;)
| > (I haven't heard about a boot-able stand-alone HLA-Os yet.)
| It's a 32-bit only assembler, so the parts that need to be 16-bit code
| (bootsector, code that switches to 32-bit protected mode, etc.) have
| to be dealt with either by some other tool...otherwise, though, HLA is
| totally capable to do the task...you haven't heard of it simply
| because no-one's actually written an OS with it yet...
I really have no clue why assemblers cannot mix
true-REAL-, PM16- and PM32 -code.
(My linkers for all mode-interchanges are smaller than 100 bytes.)
Perhaps caused by the totally wrong
"every task needs it's own stack"-school.
I'd correct this to "one stack per CPU is enough".
| [ On the other hand, you'll _NEVER_ hear of a "boot-able stand-alone"
| Delphi / VisualBASIC / C# / etc. OS because, inherently, these
| languages are truely "application development only" from their
| design...even the C and C++ OSes have occasion to need their
| sprinklings of ASM to deal with hardware and I/O... ]
I think most of the AOD-members use C++ or similar to get their job done.
But I'm not sure if all of the OSes there are "stand-alone"-things.
The 'how do call win-API after I boot my Os?' appears frequently :)
There aren't much tools around which support all demands.
My first boot-sector was written manually with Norton/diskedit.exe.
__
wolfgang
The_Sage
>MsgID:<sMa7b.4061$Yt....@newsread4.news.pas.earthlink.net>
>>Now if you could only be honest and tell us that there is code hidden in the
>>stdlib.hhf file. Hiding code does not reduce the number of lines of code, it
>>only hides it. Not very honest.
>Actually, the "stdlib.hhf" file is simply a header file, much like stdio.h or stdlib.h
>in C. The *real* code is "hidden" in the hlalib.lib library file, much like C's
>standard library is "hidden" in files like cw32.lib (Borland) and so on.
Since my example didn't use any hidden libraries, including cw32.lib, who cares?
On the other hand, your program did use some hidden libraries, so that makes you
intellectually dishonest.
You also failed to notice that the cw32.lib is a standardized part of the C
language, whereas the hlalib.lib is not a standardized part of the ASM language.
Furthermore, someone has to write the code for those library files. Those
libraries could have been created with the inefficient language of ASM or the
more efficient language of C++, but it wouldn't be a fair compare the two
languages if you don't post all the code that had to be used. So leave out the
libraries and the macros, and use pure ASM.
So here it is again. Do try not to fall flat on your face again, please? Here is
a "hello world" program written in ASM:
.model small
.stack 100h
.data
hello_message db 'Hello, World!',0dh,0ah,'$'
.code
main proc
mov ax,@data
mov ds,ax
mov ah,9
mov dx,offset hello_message
int 21h
mov ax,4C00h
int 21h
main endp
end main
Now let's compare that to one written in C++:
#include <iostream.h>
void main() { cout << "Hello, World!" }
Go for it Randall. Prove what ASM can do as compared to C++ using just pure ASM.
Or you can take the coward's way out like you usually do and come up with some
lame excuse for why you can't do it.
You harp on and on that ASM is the best, but the only evidence you offer is your
big mouth. Are you going to bark all day little doggy, or are you going to bite?
Let's see what ASM can do, as you blindly assert without evidence or logic that
it can do. You had your heyday to promote the virtues of ASM when a request was
made for a regular expression engine written in ASM, but you preached ASM and
posted C. You had your chance to let ASM shine, but you failed. Miserably. Just
like when you failed to refute monday's post on the vices of ASM, such as it's
lack of independance from a particular computer hardware architecture, lack of
standardization of libraries, failure to work with abstractions, lack of support
for reliability or safety, failure to keep up with computer technology, most
lack appropriate engineering-based support tools and environments, lack of
clarity in the source code, lack of complexity management, lack of
straightfoward and user friendly concurrency support, lack of distributed system
support, poor maintainability, lack of true object-oriented programming support,
lack of portability, etc, etc, etc. Of course you dodged and evade that subject
with some silly excuse like you usually have, so it won't do any good to go over
that fiasco of your's again. Sorta reminds me of the silly dodge and evade you
did for function points.
So again, please post an ASM version of the regular expression engine as
originally requested and let's compare the ASM to the C version. So now what is
your next lame excuse for not posting the ASM version of the regular expression
engine going to be? That you are booked up teaching your software engineering
classes?
The_Sage
>Date written: Mon, 08 Sep 2003 22:39:29 -0500
>MsgID:<76iqlv0kpq9be6vg1...@4ax.com>
>>>Assembler is a mnemonic representation of a processor's instruction set,
>>>plain and simple.
>>Not true since it has a syntax and a processor's instruction set does not.
>What does that have to do with it?
Everything since syntax is defined as, "The rules governing the formation of
statements in a programming language".
>The only reason for an assembler to have a syntax is to make life
>easier for the coder.
What a bunch of total bullshit. The purpose of a syntax is so it makes more
sense, ie -- having a syntax is logical. There is no such thing as a language
without a syntax. If it has no syntax, then by definition, it is random.
>If you want to do it the hard way, dig up a
>copy of 1401 SPS. No syntax. If you don't put things in the correct
>column, it don't work.
Since there are rules for what columns things had to be placed it, by definition
it had a syntax.
>Come to think of it, the 1401 did have a syntax. For example:
>For the 'A' opcode (add) there were only 3 forms of the instruction
>that were acceptable.
>A
>A nnn
>A nnn nnn
>Where 'nnn' is an operand address.
>Give it anything else, and it stopped dead.
>And, actually, the x86 instruction set does have a syntax.
Such as?
The_Sage
>MsgID:<Mwd7b.4271$Yt....@newsread4.news.pas.earthlink.net>
>>>Assembler is a mnemonic representation of a processor's instruction set,
>>>plain and simple.
>>Not true since it has a syntax and a processor's instruction set does not.
>Were you paying attention in your "Formal Languages and Automata Theory" class in college?
>Did you even take one?
>It's very easy to generate a grammar for machine instructions.
>Therefore, they have a syntax (indeed, given formal language theory, it's easy enough
>to show that you could generate an infinite number of syntaxes for a given instruction set).
I never said otherwise. Weren't you paying attention to what was said? The
poster implied that ASM wasn't a language, just a bunch of random mnemonics. You
just helped me prove my point even more. Thank you.
>Of course, if you don't know formal language theory/automata theory, you probably
>don't have a clue what I'm talking about, so I won't bother to go on. And, yes, I
>*have* taught those courses at *two* different Universities as well as having taking
>graduate level sources in this subject, so I *do* have a small understanding of this
>subject (lest you go off in one of your tirades accusing me otherwise).
I probably would have flunked you as a teacher in those courses too.
Randall Hyde
"wolfgang kern" <now...@nevernet.at> wrote in message news:bjks6l$vnf$2...@newsreader1.netway.at...
>
> Hi Beth!
>
> | > I think Randy's HLA is already more HLL than ASM,
> | > even it can be used to create true, but restricted ASM-code.
> | Yes, on some scores, HLA _exceeds_ some HLLs...but, at the same time,
> | it doesn't do this by forsaking the low-level but by _supplementing_
> | it with HLL-like features...
>
> Fine, as long it produces equal code ;)
HLA assembles almost every 32-bit machine instruction out there
(it doesn't support 3DNow! and a few other esoteric things, or things
that MASM doesn't support, like CMPSD [SSE2], but for the
most part if you can create it with MASM, you can create it with HLA).
The two do *not* produce equal code for the HLL-like control structures.
HLA is better on procedure calls, MASM is a little better on nested
control structures.
>
> | > (I haven't heard about a boot-able stand-alone HLA-Os yet.)
> | It's a 32-bit only assembler, so the parts that need to be 16-bit code
> | (bootsector, code that switches to 32-bit protected mode, etc.) have
> | to be dealt with either by some other tool...otherwise, though, HLA is
> | totally capable to do the task...you haven't heard of it simply
> | because no-one's actually written an OS with it yet...
>
> I really have no clue why assemblers cannot mix
> true-REAL-, PM16- and PM32 -code.
> (My linkers for all mode-interchanges are smaller than 100 bytes.)
Well, HLA doesn't do this because (right or wrong) HLA was specifically
written to force people to leave DOS and 16-bit code behind.
MASM is perfect for those who want to write 16-bit code. Why waste
time implementing features that very few people in the target audience are
going to use?
> Perhaps caused by the totally wrong
> "every task needs it's own stack"-school.
> I'd correct this to "one stack per CPU is enough".
?????
Cheers,
Randy Hyde
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:forslvc8ak499bjff...@4ax.com...
> >Reply to article by: "Randall Hyde" <rand...@earthlink.net>
> >Date written: Tue, 09 Sep 2003 02:19:04 GMT
> >MsgID:<sMa7b.4061$Yt....@newsread4.news.pas.earthlink.net>
>
Really?
Are you really that ignorant or are you simply lying to try and extend
a completely ridiculous line of reasons for the purposes of trying to
get an emotional response out of someone?
But as long as you're not using any hidden libraries in your
C++ code, feel free to show me where you've provided
the overloaded function for "<<" that you use with the cout
stream variable. Also, show me where you've declared cout
and provided the type declaration for that object.
Maybe the file wasn't called "cw32.lib" (which I made clear was
an example, not *the* file that everyone links with), but you *did*
link with some vendor-supplied and vendor-specific library file.
> On the other hand, your program did use some hidden libraries, so that makes you
> intellectually dishonest.
Why would you say that?
> You also failed to notice that the cw32.lib is a standardized part of the C
> language, whereas the hlalib.lib is not a standardized part of the ASM language.
hlalib.lib is a standardized part of the HLA language.
But you can even call HLA Standard Library routines from MASM (and other
assemblers, though you will have to supply the header files for assemblers beyond
MASM or HLA). Go ahead, try and change the subject by claiming that "HLA
isn't a standard assembly language" (which, of course, it isn't -- there is no "standard"
assembly language), but the point is irrelevant. You've been given an example
of an assembly language that has a standard library and makes writing "hello world"
(and regular expression code) so much easier. You can elect not to use it if you like,
but then, you have to take responsibility for the lack of productivity that ensues.
> Furthermore, someone has to write the code for those library files. Those
> libraries could have been created with the inefficient language of ASM or the
> more efficient language of C++, but it wouldn't be a fair compare the two
> languages if you don't post all the code that had to be used. So leave out the
> libraries and the macros, and use pure ASM.
Sorta like you left out the code for "operator<<", eh?
> So here it is again. Do try not to fall flat on your face again, please? Here is
> a "hello world" program written in ASM:
>
> .model small
> .stack 100h
>
> .data
> hello_message db 'Hello, World!',0dh,0ah,'$'
>
> .code
> main proc
> mov ax,@data
> mov ds,ax
> mov ah,9
> mov dx,offset hello_message
> int 21h
> mov ax,4C00h
> int 21h
> main endp
> end main
Let's see, isn't "int 21h" a "hidden library"?
You could have written the code to copy those characters one
at a time to the video display, ya know.
>
> Now let's compare that to one written in C++:
>
> #include <iostream.h>
> void main() { cout << "Hello, World!" }
Isn't this "intellectually dishonest?" I mean, what exactly
are you hiding inside "#include <iostream.h>"?
>
> Go for it Randall. Prove what ASM can do as compared to C++ using just pure ASM.
> Or you can take the coward's way out like you usually do and come up with some
> lame excuse for why you can't do it.
You're absolute right.
If you allow C++ programmers to take advantage of C++ Standard Libraries
and you force assembly language programmers to write every line of code
from scratch, and not take advantage of the libraries that come with their
assembly package (e.g., MASM32 or HLA), then the assembly programmer
is going to be less productive - no surprise there. I believe, however, that the
whole point I've been making all along is that *modern* assembly language
development systems provide things like libraries, better control structures,
fancy macro systems, and so on. This is what is making assembly language
programmers more productive today. If you're going to fix the rules such
that an assembly programmer has to write code the same way they did
back in the 50's, of course assembly is going to look bad compared to
modern programming languages. The point is, people don't have to write
assembly code that way anymore. They get to use "hidden" code to make
them more productive. And as they didn't have to write that "hidden" code
themselves, it doesn't cost them much to use it (they do have to *read* the
documentation, but that's true for any language's library routines, including
C++'s).
>
> You harp on and on that ASM is the best, but the only evidence you offer is your
> big mouth.
Hmmm...
I do believe I've said that ASM is best for *some* things. Do you dispute that?
Your statement implies that I've said this unequivocally. Do you care to correct this
statement (or provide the reference where I've said that ASM is best for everything?)
As for my big mouth, hmm...
Why don't you provide a C++ example, using only C++ and C Standard Library
function calls, that is capable of parsing regular expressions with less lines of code
that the HLA example I provided does? I've provided code, let's see, you've provided
a "hello world" program, of which an example in HLA appears in the first chapter
of "The Art of Assembly."
> Are you going to bark all day little doggy, or are you going to bite?
> Let's see what ASM can do, as you blindly assert without evidence or logic that
> it can do. You had your heyday to promote the virtues of ASM when a request was
> made for a regular expression engine written in ASM, but you preached ASM and
> posted C.
You keep saying it's C. That's a laugh.
But as long as we're barking and not biting, feel free to attach the
"C" code I posted right here to prove I posted C code.
I don't remember posting any C code (outside of some HLA comments).
Maybe I've just lost it completely and posted the wrong code. Feel free
to repost the code I supposedly posted and prove me wrong.
Oh, and by the way, make sure a reasonable C compiler (MS, Borland,
or GNU, I don't care) *compiles* that C code I posted....
> You had your chance to let ASM shine, but you failed. Miserably. Just
> like when you failed to refute monday's post on the vices of ASM,
Yeah, which post was that?
Was that the one whose response I posted you didn't bother to read? :-)
> such as it's
> lack of independance from a particular computer hardware architecture, lack of
> standardization of libraries, failure to work with abstractions, lack of support
> for reliability or safety, failure to keep up with computer technology, most
> lack appropriate engineering-based support tools and environments, lack of
> clarity in the source code, lack of complexity management, lack of
> straightfoward and user friendly concurrency support, lack of distributed system
> support, poor maintainability, lack of true object-oriented programming support,
> lack of portability, etc, etc, etc. Of course you dodged and evade that subject
> with some silly excuse like you usually have, so it won't do any good to go over
> that fiasco of your's again. Sorta reminds me of the silly dodge and evade you
> did for function points.
Oh, that post.
As you've not provided any support for your claims, why should I bother?
But just to make things fair, I'll give you the chance to support your claims.
Keep watching the newsgroup.
>
> So again, please post an ASM version of the regular expression engine as
> originally requested and let's compare the ASM to the C version. So now what is
> your next lame excuse for not posting the ASM version of the regular expression
> engine going to be? That you are booked up teaching your software engineering
> classes?
As soon as you post the "C" code that I supposed posted, then I'll convert it to
assembly. I don't remember posting any C code (outside of some comments).
So have at it.
Cheers,
Randy Hyde
Andreas Schmitz
>>>stdlib.hhf file. Hiding code does not reduce the number of lines of code, it
>>>only hides it. Not very honest.
Ah...
>>Actually, the "stdlib.hhf" file is simply a header file, much like stdio.h or stdlib.h
>>in C. The *real* code is "hidden" in the hlalib.lib library file, much like C's
>>standard library is "hidden" in files like cw32.lib (Borland) and so on.
> Since my example didn't use any hidden libraries, including cw32.lib, who cares?
> On the other hand, your program did use some hidden libraries, so that makes you
> intellectually dishonest.
> You also failed to notice that the cw32.lib is a standardized part of the C
> language, whereas the hlalib.lib is not a standardized part of the ASM language.
Well, I do not know exactly which example you are referring to (I have
not read all of the past NG postings)...
but...
I guess you are using some functions like printf or something (you say
it is part of the stdlib for C).
If I (or anyone) wrote and designed a new (compiled) language, and I
would write myself some functions/classes to output text or something
like that, and then try to compete with your example ("secretly" using
some of these functions/classes, which are all publicitly accessible),
would you really dare to say I am "intelleacually dishonest" because I
am using a "standard library" which is not actually approved by ISO or
another organization?
> Furthermore, someone has to write the code for those library files. Those
> libraries could have been created with the inefficient language of ASM or the
^^^^^^^^^^^
> more efficient language of C++, but it wouldn't be a fair compare the two
^^^^^^^^^
Ah, well. I think Randall already pointed out why assembly can (always,
as in every possibly language depending on the programmer) be at least
as efficient as every other possible language (on a given hardware
platform). If you don't believe me (or accept Randall's arguments), read
a book on what is the difference between a compiled and an assembly
language.
> languages if you don't post all the code that had to be used. So leave out the
> libraries and the macros, and use pure ASM.
It has also been pointed out, that no code that has any relationship to
the real calculations is in the "hidden" (and thus not by any "approved"
licensing organization ... - approved library) code/library.
> So here it is again. Do try not to fall flat on your face again, please? Here is
> a "hello world" program written in ASM:
The audience is listening/reading:
> .model small
> .stack 100h
> .data
> hello_message db 'Hello, World!',0dh,0ah,'$'
> .code
> main proc
> mov ax,@data
> mov ds,ax
> mov ah,9
> mov dx,offset hello_message
> int 21h
> mov ax,4C00h
> int 21h
> main endp
> end main
> Now let's compare that to one written in C++:
> #include <iostream.h>
^^^^^^^
So much for hidden code.
> #include <iostream.h>
^^
So you don't even know "standardized" C++...
> void main() { cout << "Hello, World!" }
^^^^
Well, do you know, what is executed at all (in a given operating system
like Linux) before even the main() function is executed? Like start?
> void main() { cout << "Hello, World!" }
^
Now what do you think entering a new block does generate on a given
compiler on IA32?
> void main() { cout << "Hello, World!" }
^^
You know what that is? Yep, This is like calling a function. Didn't
know?
> void main() { cout << "Hello, World!" }
^^^^^^^^^^^^^^^
Where does this come from? I would guess the computer won't guess this
text. It has to be stored *somewhere*.
> void main() { cout << "Hello, World!" }
^
Well, leaving the function throws some well defined questions. What
about the stack? Where does the stack pointer point to? Questions that
must be answered...
Yes, I also think that programming C++ is easier than programming
ASM. Especially on programming something that uses (for example)
anything that can be expressed as a stream. I can easily modify the
above example to accept either stdin (on POSIX systems (is it POSIX
where stdin is defined?)) or any file/stream/network resource possible
on the system. Easy in C++. You cannot do this in ASM (x86). And that is
exactly the point. One (maybe even I) can do the appropriate network
transfer and the output even more efficient that some given C++
compiler, and (if that is the main purpose of the program) it would even
be worth it.
Ok, I am not in the mood to talk more about it. If the reader hasn't got
the little horse's sense to understand the previous paragraph, he should
go read some more (very basic) books.
Well, I must admit that someone who calls himself "The Sage" triggers
some prejudice on my side. But such blatant ignorance calls the hells
advocate out of me.
Well, yes, efficiency on the "programmers side" is obviously most of the
time better on the side of the C/C++ programmer or even more on the side
of the Java programmer (think of some GUI programming on certain
platforms).
But I guess speaking of "efficiency" in a NG like this should really not
include comparing the developer manpower from one HLL to another. If
yes, please feel free to explain the abbreviation "ASM" to me (I am no
expert in (x86) assembly, but I know what I know).
...
I may be missing something, but the recent amassment of articles
containing "The Sage" in the subject tells me I am on the right way
being prejudiced against his/her posts...
Regards, Andreas
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:rguslvgsb3aar22sq...@4ax.com...
> >Reply to article by: "Randall Hyde" <rand...@earthlink.net>
> >Date written: Tue, 09 Sep 2003 05:27:08 GMT
> >MsgID:<Mwd7b.4271$Yt....@newsread4.news.pas.earthlink.net>
>
> >>>Assembler is a mnemonic representation of a processor's instruction set,
> >>>plain and simple.
>
> >>Not true since it has a syntax and a processor's instruction set does not.
>
> >Were you paying attention in your "Formal Languages and Automata Theory" class in college?
> >Did you even take one?
> >It's very easy to generate a grammar for machine instructions.
> >Therefore, they have a syntax (indeed, given formal language theory, it's easy enough
> >to show that you could generate an infinite number of syntaxes for a given instruction set).
>
> I never said otherwise. Weren't you paying attention to what was said? The
> poster implied that ASM wasn't a language, just a bunch of random mnemonics. You
> just helped me prove my point even more. Thank you.
Shall I quote you?
You said
"Not true since it has a syntax and a processor's instruction set does not."
Now, it doesn't really matter what the OP said. You explicitly said
that a processors instruction set does not have a syntax.
Then again, your command of the English language hasn't been too good
in the past, so maybe you were thinking one thing and writing another, eh?
>
> >Of course, if you don't know formal language theory/automata theory, you probably
> >don't have a clue what I'm talking about, so I won't bother to go on. And, yes, I
> >*have* taught those courses at *two* different Universities as well as having taking
> >graduate level sources in this subject, so I *do* have a small understanding of this
> >subject (lest you go off in one of your tirades accusing me otherwise).
>
> I probably would have flunked you as a teacher in those courses too.
Of course you would have.
Because if you tried to pull this kind of B.S. in one of my classes you would
have failed miserably and that probably would have really pissed you off.
Cheers,
Randy Hyde
sinewave
> void main() { cout << "Hello, World!" }
// FWIW phil's version:
#include <iostream>
using namespace std;
int main() {
cout << "Hello, World!\n";
return 0;
}
regards,
phil
Randall Hyde
"Andreas Schmitz" <vstr...@arcor.de> wrote in message news:slrnblt21j.r...@sammael.tabu.stw-bonn.de...
>
> Yes, I also think that programming C++ is easier than programming
> ASM. Especially on programming something that uses (for example)
> anything that can be expressed as a stream. I can easily modify the
> above example to accept either stdin (on POSIX systems (is it POSIX
> where stdin is defined?)) or any file/stream/network resource possible
> on the system. Easy in C++. You cannot do this in ASM (x86).
Sure you can.
HLA (the High Level Assembler) and the HLA Standard Library make
this very easy. Want to do it the procedural way? How about:
stdout.put( "hello world" nl ); // goes to the standard output
fileio.put ( filehandle, "hello world", nl ); // goes to a file
Of course, you can also supply the standard output handle to
fileio.put and it will also send the output to stdout. "stdout.put",
in fact, is simply a tiny procedure that does exactly this.
Now, if you prefer the object-oriented approach, the HLA
Standard Library also provides object-oriented file variables
that let you do things like the following:
fileObject1.put( "Hello World" nl );
fileObject2.put( "Hello World" nl );
etc.
> And that is
> exactly the point. One (maybe even I) can do the appropriate network
> transfer and the output even more efficient that some given C++
> compiler, and (if that is the main purpose of the program) it would even
> be worth it.
If I understand what you're saying here, the work has been done for you.
It's in the HLA Standard Library that comes with HLA on Webster:
http://webster.cs.ucr.edu.
>
> Ok, I am not in the mood to talk more about it. If the reader hasn't got
> the little horse's sense to understand the previous paragraph, he should
> go read some more (very basic) books.
I still haven't figured out whether he's a total troll or really is that ignorant.
I'm hoping he's a troll and is doing this for his own amusement.
He claims to know a lot; alas, I haven't seen him post much of
substance around here (most of the half-way intelligent things he
has posted have come from web sites; then, of course, he completely
mis-represents or mis-interprets the information).
>
> Well, I must admit that someone who calls himself "The Sage" triggers
> some prejudice on my side. But such blatant ignorance calls the hells
> advocate out of me.
Yeah, I find ignorance distasteful too. Especially when it might prejuidice
someone and keep them from learning assembly language.
> But I guess speaking of "efficiency" in a NG like this should really not
> include comparing the developer manpower from one HLL to another. If
> yes, please feel free to explain the abbreviation "ASM" to me (I am no
> expert in (x86) assembly, but I know what I know).
I can explain "ASM".
It's TS' way of being non-comittal. If you give an example with
a specific assembler system (like MASM32 or HLA), his use of
"ASM" allows him to claim nonsense like "I meant *all* assemblers,
not just that one." Of course, try and apply that same logic to HLLs
and see how far that gets you with TS.
> ...
>
> I may be missing something, but the recent amassment of articles
> containing "The Sage" in the subject tells me I am on the right way
> being prejudiced against his/her posts...
Most people take him serious for one or two posts. Then it's all over.
I don't know who he's trying to impress or how he thinks he's impressing
them. But you should see some of the emails I get that discuss this
guy in rather frank terms :-)
Cheers,
Randy Hyde
Mark I Manning IV
lol - that would be cheating
also, development in forth is usually some orders of magnitude faster than
almost any other language, you no longer have an "edit, compile/assemble,
link, debug" development cycle, what you have is an "edit, debug" cycle.
Even in dos, using Eric Isaacsons A86 assembler you still dont have the
ability to easilly test each function as its defined. You could do this
but there would be a hell of alot of juggling to do that would make the
whole effort a waste of time :)
There 'are' times when assembler is the better way to go but this is
usually on a per function basis, not per application. Isforth however is
still deficient one assembler extension so your basically stuck writing
everything in forth - the first thing im going to rework once I have an
assembler is the memory manager, alot of that realy needs to be low level
:)
Some day I should pluck up the courage to write that assembler :)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Mark I Manning IV
there are many devices that are microcoded in forth - chuck moore is
developing some for instance.
Ed Beroset
> On Mon, 08 Sep 2003 19:28:17 -0400, sinewave <no...@nowhere.com> wrote:
>
>> hi Mark:
>>
>> are you saying Forth can create smaller EXEs than asm? because we will
>> just take your EXE, disassemble, and shave some bytes :p.
>>
>> regards,
>> phil
>
>
>
> lol - that would be cheating
>
> also, development in forth is usually some orders of magnitude faster
> than almost any other language, you no longer have an "edit,
> compile/assemble, link, debug" development cycle, what you have is an
> "edit, debug" cycle.
I like Forth, and have done projects with it, but I'm very skeptical of
this claim. Have you any independently verifiable data to demonstrate
this assertion?
Ed
Alex McDonald
Sage posts -- my poor newsreader has indigestion -- please excuse the bad
protocol of replying to both messages in one ]
"Ed Beroset" <ber...@mindspring.com> wrote in message
news:dRC7b.3221$TC1....@newsread2.news.atl.earthlink.net...
> Mark I Manning IV wrote:
> > On Mon, 08 Sep 2003 19:28:17 -0400, sinewave <no...@nowhere.com> wrote:
> >
> >> hi Mark:
> >>
> >> are you saying Forth can create smaller EXEs than asm? because we will
> >> just take your EXE, disassemble, and shave some bytes :p.
> >>
> >> regards,
> >> phil
> >
Yes, it can, but you need to understand how it works to see that Forth EXEs
can be very much smaller. Create an EXE with "primitives" for a VM type
machine that operates on the top of the stack (pseduo code in what follows).
For instance, an ADD for the top two stack entries;
CODE VMADD
pop eax
pop ebx
add eax, ebx
push eax
END-CODE
Other primitives to suit. Now, encode a 256 instruction table with all the
instructions;
| VMADD-addr | VMSUB-addr | .... |
Now write your program
1|2|1
which is VMADD, VMSUB , VMADD in 3 bytes
Obviously you'll need a little interpreter from this "byte-code" VM (the
inner interpreter), a parser (the outer interpreter) and there are a few
housekeeping details (Forth has two stacks, for instance), but you get the
picture. 3 bytes (plus the overhead of the VM) vs several (obviously, the
more code the more Forth is smaller). Even better, add the address of 1|2|1
to my table (let's make it the 213th entry), then 213|213 is equivalent of
1|2|1|1|2|1 which is executed as... and so on. (This BTC example would be
atrociously inefficent btw, and most Forth systems don't use this technique
as a consequence unless space is very very tight.) Closer to home,
Win32Forth is a complete Forth system, including the Forth compiler (written
in Forth), an x86 assembler (Forth again) & editor (Forth too); supports
OOP, multithreading, Windows; fits in a 1.6Mb zip file, of which 615k is
zipped documentation, rest is the source, demos etc; and this is considered
a heavyweight Forth.
There are a variety of Forths; this example is a BTC, and there are ITC, STC
and DTC and native code as well. See "Moving Forth: a series on writing
Forth kernels" at http://zetetics.com/bj/papers/index.html which discusses
these (although the examples are for processors that are now old hat, such
as the 8051 and the Z80).
> >
> >
> > lol - that would be cheating
> >
> > also, development in forth is usually some orders of magnitude faster
> > than almost any other language, you no longer have an "edit,
> > compile/assemble, link, debug" development cycle, what you have is an
> > "edit, debug" cycle.
>
> I like Forth, and have done projects with it, but I'm very skeptical of
> this claim. Have you any independently verifiable data to demonstrate
> this assertion?
The claim that it's edit/debug is accurate. I'm sceptical of the development
time claims; but there are those (on comp.lang.forth) that may be able to
verify. Certainly, the _code_ (both generated and lines/words used) can be
orders of magnitude smaller compared with, say C++. And it's a fun language;
it sure beats arguing about high-level vs low-level vs whatever.
: HI! ( print Hello World on the output device)
S" Hello World" TYPE ;
HI!
Forth does "Hello World"; this will run on any Forth system (which covers
just about every processor/opsys out there, including ones you've never
heard of).
>
>
> Ed
>
--
Regards
Alex McDonald
sinewave
> lol - that would be cheating
:D you're right. Forth looks interesting, i will be reading up on it. btw,
welcome back! how would you describe your last two years?
regards,
phil
sinewave
great post! i've been designing something similar to Forth without
realizing it. thanks for the link!
> And it's a fun language; it sure beats arguing about high-level vs low-
> level vs whatever.
my strategy is simple... first, i let the major players debate themselves
to boredom... then i enter the battlefield: hurtling the dead and trampling
the wounded. then i shall slay the would-be winner with a mighty sword and
shout "MY LANGUAGE IS BETTER THAN YOURS"... while holding up a coke so as
to cut a deal for a commercial... "coke, the breakfast of alt.lang.asm
champions". hlt
regards,
phil
Mark I Manning IV
well i sold alot of stock at a loss just to stay afloat, the bank sold my
house out from under me, my fathers $5000 lathe drill mill was damaged in
the move rendering it absolutely useless (anyone need a paperweight?) -
all in all its been a wonderfull tuime :)
I used that "down" time to do alot of intense development in my forth
system and the situation never realy got ME depressed, just annoyed. I
knew things would improve and they have. Im now working a contract in
texas using FORTH!!! (related to satelite tracking too which is where
chuck moore invented forth :)
hope none of you ever need to go through this particular object lesson :/
if i was a drag and drop object obfuscated windows visual c++ coder
wannabe i wouldnt have had ANY problems finding any work - they use that
crap in embedded apps too these days - i doubt very seriously if it
improves th esituation for those using it however, ive never seen OOP do
anything to improve an embedded application - seen it kill a few though :/
anyway, realy great to be back :)
The_Sage
>Date written: 10 Sep 2003 02:14:22 GMT
>MsgID:<slrnblt21j.r...@sammael.tabu.stw-bonn.de>
>>You also failed to notice that the cw32.lib is a standardized part of the C
>>language, whereas the hlalib.lib is not a standardized part of the ASM language.
>Well, I do not know exactly which example you are referring to (I have
>not read all of the past NG postings)...
>but...
>I guess you are using some functions like printf or something (you say
>it is part of the stdlib for C).
It was "cout" and it was for C++.
>If I (or anyone) wrote and designed a new (compiled) language, and I
>would write myself some functions/classes to output text or something
>like that, and then try to compete with your example ("secretly" using
>some of these functions/classes, which are all publicitly accessible),
>would you really dare to say I am "intelleacually dishonest" because I
>am using a "standard library" which is not actually approved by ISO or
>another organization?
Did I say that? Heck no, not even close! I said that ASM doesn't have any
standardized print functions and C++ does. Now if you wrote an ASM program and
hide your non-standard print function in a macro or a library and claimed that
your resulting one line program was an example of what standard ASM can do, you
would be intellectually dishonest, just like Randall has done.
>> Furthermore, someone has to write the code for those library files. Those
>> libraries could have been created with the inefficient language of ASM or the
^^^^^^^^^^^
>> more efficient language of C++, but it wouldn't be a fair compare the two
> ^^^^^^^^^
>Ah, well. I think Randall already pointed out why assembly can (always,
>as in every possibly language depending on the programmer) be at least
>as efficient as every other possible language (on a given hardware
>platform). If you don't believe me (or accept Randall's arguments), read
>a book on what is the difference between a compiled and an assembly
>language.
Talk is cheap. Give us an example. I did.
>>languages if you don't post all the code that had to be used. So leave out the
>>libraries and the macros, and use pure ASM.
>It has also been pointed out, that no code that has any relationship to
>the real calculations is in the "hidden" (and thus not by any "approved"
>licensing organization ... - approved library) code/library.
And your point has been countered with what was actually the issue: non-hidden
code that demonstrates efficiency of the language.
>>So here it is again. Do try not to fall flat on your face again, please? Here is
>>a "hello world" program written in ASM:
>> .model small
>> .stack 100h
>> .data
>> hello_message db 'Hello, World!',0dh,0ah,'$'
>> .code
>> main proc
>> mov ax,@data
>> mov ds,ax
>> mov ah,9
>> mov dx,offset hello_message
>> int 21h
>> mov ax,4C00h
>> int 21h
>> main endp
>> end main
>> Now let's compare that to one written in C++:
>> #include <iostream.h>
> ^^^^^^^
>So much for hidden code.
It's a header, not code.
>> #include <iostream.h>
^^
>So you don't even know "standardized" C++...
So you don't even know what a *header* is. At least you got the C++ part right,
finally.
>> void main() { cout << "Hello, World!" }
> ^^^^
>Well, do you know, what is executed at all (in a given operating system
>like Linux) before even the main() function is executed? Like start?
That is what makes the language *efficient*. There is no hidden C++ code there.
Try again.
>> void main() { cout << "Hello, World!" }
> ^
>Now what do you think entering a new block does generate on a given
>compiler on IA32?
It is irrelevant since there is NO HIDDEN C++ CODE in the block because the
block is the code. And in this instance, the block doesn't do anything except
desginate the end and beginning of a function.
>> void main() { cout << "Hello, World!" }
>
> ^^
>You know what that is? Yep, This is like calling a function. Didn't
>know?
Wrong again, it is a C++ keyword, not a function. Obviously you don't know much
about higher level languages.
>> void main() { cout << "Hello, World!" }
>
> ^^^^^^^^^^^^^^^
>Where does this come from? I would guess the computer won't guess this
>text. It has to be stored *somewhere*.
It is declared in the code right where you type it, WITHOUT ANY HIDDEN C++ CODE.
>> void main() { cout << "Hello, World!" }
> ^
>Well, leaving the function throws some well defined questions. What
>about the stack? Where does the stack pointer point to? Questions that
>must be answered...
Your questions are stupid since they have absolutely nothing to do with any
HIDDEN CODE. Unless you can "unravel" the hidden C++ code in any of your
examples above, you've failed the challenge. If there is any hidden C++ code, as
Randall hid his code in a library that was precompiled with ASM code, show it.
Not a single one of your points demonstrated any hidden C++ code. Did you take
one of Randall's classes? Then why can't you understand simple code and simple
english? There is no C++ code that is being hidden. Not one. The "cout" keyword
is a standardized keyword for the C++ language, it isn't a non-standardized
macro or a non-standardized function that hides a bunch of other C++ code. Get a
clue please, that way I won't have to embarass you in public like this anymore.
The_Sage
>MsgID:<1rv7b.5180$PE6...@newsread3.news.pas.earthlink.net>
>> So here it is again. Do try not to fall flat on your face again, please? Here is
>> a "hello world" program written in ASM:
>> .model small
>> .stack 100h
>> .data
>> hello_message db 'Hello, World!',0dh,0ah,'$'
>> .code
>> main proc
>> mov ax,@data
>> mov ds,ax
>> mov ah,9
>> mov dx,offset hello_message
>> int 21h
>> mov ax,4C00h
>> int 21h
>> main endp
>> end main
>Let's see, isn't "int 21h" a "hidden library"?
No, it is a part of the operating system. Any other stupid questions?
>You could have written the code to copy those characters one
>at a time to the video display, ya know.
Go for it. Show us how efficient you can make ASM as compared to C++.
>> Now let's compare that to one written in C++:
>> #include <iostream.h>
>> void main() { cout << "Hello, World!" }
>Isn't this "intellectually dishonest?" I mean, what exactly
>are you hiding inside "#include <iostream.h>"?
It isn't code.
I asked you to demonstrate, without using non-standardized libraries or dlls or
"unravled" macros, how much more efficient ASM is than C++ for the SAME EXACT
FUNCTIONS.
I showed you example C++ code that didn't use any non-standardized libraries or
dlls or "unravled" macros, that way we could compure PURE ASM TO PURE C++. You
completley and miseraly failed. You don't know what you are talking about and
this proves it.
>>So again, please post an ASM version of the regular expression engine as
>>originally requested and let's compare the ASM to the C version. So now what is
>>your next lame excuse for not posting the ASM version of the regular expression
>>engine going to be? That you are booked up teaching your software engineering
>>classes?
>As soon as you post the "C" code that I supposed posted, then I'll convert it to
>assembly. I don't remember posting any C code (outside of some comments).
>So have at it.
Yet another lame ass excuse for not posting an ASM version of the regular
expression engine? You are a coward, plain and simple. If you were my teacher, I
would have kicked your ass out of the classroom.
The_Sage
>MsgID:<FSv7b.5211$PE...@newsread3.news.pas.earthlink.net>
>>>>>Assembler is a mnemonic representation of a processor's instruction set,
>>>>>plain and simple.
>>>>Not true since it has a syntax and a processor's instruction set does not.
>>>Were you paying attention in your "Formal Languages and Automata Theory" class in college?
>>>Did you even take one?
>>>It's very easy to generate a grammar for machine instructions.
>>>Therefore, they have a syntax (indeed, given formal language theory, it's easy enough
>>>to show that you could generate an infinite number of syntaxes for a given instruction set).
>>I never said otherwise. Weren't you paying attention to what was said? The
>>poster implied that ASM wasn't a language, just a bunch of random mnemonics. You
>>just helped me prove my point even more. Thank you.
>Shall I quote you?
>You said
>"Not true since it has a syntax and a processor's instruction set does not."
>Now, it doesn't really matter what the OP said. You explicitly said
>that a processors instruction set does not have a syntax.
>Then again, your command of the English language hasn't been too good
>in the past, so maybe you were thinking one thing and writing another, eh?
You are quoting out of context. Get a clue by finishing off "a syntax and a
processor's instruction set does not" with the topic that it was refering to.
You are an idiot Randall, so don't even bother trying or I will have to embarass
you again like I did with your inablity to post an efficient pure ASM version of
a pure C++ program, and your complete inability to post ASM code for a regular
expression engine, which you obviously don't and haven't ever created since the
C version is all you have. You preach ASM and then post C and that tells us all
we need to really know about what you really believe.
Mark I Manning IV
wrote:
there are plenty of cases out there, forth is THE secret weapon in a
number of very large companies. One intersting case was in a competition
where you could bring your own development environment, work solo or as a
team, use any language you wanted but had to work on a given problem which
you only learned of on the day.
This particular compo was as follows. You were given a block of wood
with a hacksaw blade embedded vertically in it. on either side of the
blade were solenoids which were to be connected to a port on your
machine. the blade also had a series of LED's which you also connect to a
port on your pc.
The task was to set the blade swinging left and right by switching the
solenoids on and off and while you do this you switch the led's on and off
to produce some character display (using the persistence of the eye).
In forth one might proceed as follows
: left_on ....... ;
: left_off ....... ;
: right_on ....... ;
: right off ....... ;
where the code inside each of the definitions writes the correct values to
the correct ports to switch the right bits on/off to make the solenoids
toggle.
You enter the above into your forth terminal and you can now do....
Left_on [enter]
left_off [enter]
etc. You test your definitions and when they work you can go on and maybe
create a delay word...
: delay ..... ;
and now you can do (the following is very crude and probably not exactly
how it was done but...)
: do_left left_on delay left off delay ;
: do_right right_on delay right_off delay ;
: do_test
begin
key? not \ while no key is pressed
while
do_left \ swing left
do_right \ then right
repeat ;
run do_test with the current delay and you will maybe get the blade
swinging. - press a key and adjust the delay and repeat till you have the
blade swinging correctly.
You would then proceed along these lines to insert code to switch the
led's on and off - you might have a swinger_task and an led_task or
something.
I believe that the forth team had a message scrolling accross the
"display" before anyone else had even found the resonant frequency of the
hacksaw blade.
This however might be an unfair test, visual basic for instance doesnt
usually do well in these sorts of tests but if you use the above methods
to develop your code you can develop very quickly in any language - but
who wants to compile after every fiddly little edit in visual c++ ? - it
just isnt the same :/
in forth you develop the lowest level words that you are going to need and
test them right there on the spot. When they are all working you can use
those to create higher level definitions and so on and so forth (no pun
intended :).
What this means is that at each stage of development ALL of the previously
developed parts of your code are fully tested You dont write a 50 gig
source file, wait the 6 days for it to compile and then try to debug it
with a "source level debugger" (exaggerating for effect :).
Which brings me to another point, source level debugging is absolutely
MORONIC. you do NOT debug source files, you debug objetct code!
sinewave
> the bank sold my house out from under me
damn, sorry to hear that. rough times often make us better people. sounds
like you are now at an ideal job... doing something you love... Forth!
regards,
phil
Mark I Manning IV
<alex...@btopenworld.com> wrote:
> [ Not being able to see the original postings due to the flood of Hyde vs
> Sage posts -- my poor newsreader has indigestion -- please excuse the bad
> protocol of replying to both messages in one ]
forgiven - and agreed, all that bullshit spam is uncalled for - it would
be better if some people took their wars elsewhere!
>
> CODE VMADD
> pop eax
> pop ebx
> add eax, ebx
> push eax
> END-CODE
can save space and time again by cashing top of stack in a register
sometimes... (isforth does this)
> Other primitives to suit. Now, encode a 256 instruction table with all
> the
> instructions;
>
> | VMADD-addr | VMSUB-addr | .... |
>
> Now write your program
>
> 1|2|1
>
> which is VMADD, VMSUB , VMADD in 3 bytes
>
yes this is called token threading, i use direct threading in isforth
(thers also indirect and subroutine threading and some other more funky
ones :)
even a direct threaded forth can produce smaller object code than the
equiv assembler (in direct threading instead of storing a token for each
primative you store a pointer to each). - if your forth is a 32 bit forth
like my isforth the space saving is eaten up to some degree but a 16 bit
forth (say on an 8051) gives a huge saving even without token threading -
assuming you are a fairly competent forther :)
> Obviously you'll need a little interpreter from this "byte-code" VM (the
> inner interpreter), a parser (the outer interpreter) and there are a few
> housekeeping details (Forth has two stacks, for instance),
the second stack isnt an inconvinence or a hinderance to object size or
execution, in fact c is realy realy stupid for not using two stacks (an
aquantence of linus t was working on a dual stack c - may still be). The
single stack method has problems, look at some example compiled c...
push parameter
push parameter
call function...
the above call just buried your parameters underneath the return
address...
open local stack frame for local variables
bury parameters even deeper!!
do function
clean local stack frame and return ONE value
(in forth you can return ANY number of values - assuming stack space of
corse).
return from function
clean parameters off stack.
The above can be optimized to some degree by variouis trickery etc but c
is STILL very inefficient when it comes to function calls which is why
most c coders write all their code in rather large functions nested to the
umpteenth level. In forth you write alot of words that do things like....
: 1+ 1 + ;
..you just defined a word called 1+ (one plus) which adds 1 to the top
stack item. you can do this in forth because generally there is very
little hit for making a function call. this also means that you have alot
of very small REUSEABLE functions which can save you a hell of alot of
space in the long run.
> but you get the
> picture. 3 bytes (plus the overhead of the VM) vs several (obviously, the
> more code the more Forth is smaller).
yes i always qualify my "forth is slaller" statement with "for any NON
TRIVIAL" application :)
> Even better, add the address of 1|2|1
> to my table (let's make it the 213th entry), then 213|213 is equivalent
> of
> 1|2|1|1|2|1 which is executed as... and so on. (This BTC example would be
> atrociously inefficent btw, and most Forth systems don't use this
> technique
I have a pc version of the old "wizardry" game for the apple iie - it runs
under a apple emulator that i discovered was written in a realy funky
(read difficult to reverse engineer) token threaded forth :)
> as a consequence unless space is very very tight.) Closer to home,
> Win32Forth is a complete Forth system, including the Forth compiler
> (written
> in Forth), an x86 assembler (Forth again) & editor (Forth too); supports
> OOP, multithreading, Windows; fits in a 1.6Mb zip file, of which 615k is
> zipped documentation, rest is the source, demos etc; and this is
> considered
> a heavyweight Forth.
>
tom zimmer always did have featureitis too, heh = i cut my teeth on his
FPC (16 but dos forth) and isforth is designed to have a similar look and
feel to it - i have nothing bad to say about tom zimmer however, i seem to
have caught his feature-itis :)
btw he also wrote the old commodore 64 forth that came on a cartridge way
back when.
>
> There are a variety of Forths; this example is a BTC, and there are ITC,
> STC
> and DTC and native code as well. See "Moving Forth: a series on writing
> Forth kernels" at http://zetetics.com/bj/papers/index.html which
> discusses
> these (although the examples are for processors that are now old hat,
> such
> as the 8051 and the Z80).
ahem the 8051 isnt old hat, i happen to be working on a commercial 8051
umbilical forth compiler heh - you need to go to www.cygnal.com - their
8051's have a 1:! instruction:processor clock cycle (original 8051's had
12 clocks per instruction cycle) and they execute at 25 mhz too!!!
You also get a complete "not so" interactive development environment
including a source level debugger which runs through the jtag present on
ALL of their processors and you can do this without even thinking about an
in circuite emulator :)
>
> : HI! ( print Hello World on the output device)
> S" Hello World" TYPE ;
> HI!
i refuse to support s" in isforth, its (imho) DUMB.
what s" does is compile a string inline - when execution gets to the
string forth leaves the address of the string on the stack and moves the
interprative pointer beyond the end of the string. i will not include
this sort of silyness in my forth, in isforth you would do
: hello ." hello" ;
this also compiles the string inlinebut the ." (dot quote" processes the
string (outputs it) when executed. if you need a string that you can
address you can do
create the-string
," the string"
: do-stuff the-string blah blah ;
however, the examples you posted are more inline with the new fangled ans
standard :)
> Forth does "Hello World"; this will run on any Forth system (which covers
> just about every processor/opsys out there, including ones you've never
> heard of).
>
there are very few processors/controlers that havent had a forth of one
sort or other written for them and porting forth accross platforms is very
simple (i also say that porting ASSWMBLER accross platforms is simple but
dont quote me to a c++ coder, he would have a fit!).
btw, nice to see there are other forthers in here (i know hpr sneeks a
peek this way every now and then - hi hp!! :)
Mark I Manning IV
you mean "my language is l3373r than yours?" - dont you ??? :)
Mark I Manning IV
that would be an afermative :)
Frank Kotler
Okay, you've convinced me. Asm is bad. "How bad is it?"...
>>>So here it is again.
Again?
>>>a "hello world" program written in ASM:
As I suspected might be the case, you're using crap asm for the
comparison. This'll easily fit in a single segment, so there's no need
for the MZ bloat. "main proc"! WTF is that supposed to mean? Then
there's the "int 21h" which some people might claim is "hidden code". I
agree that, since it's not part of your executable, it shouldn't be
counted, but lets dispense with it, to remove any doubt. I happened to
have this on my hard drive (excuse the newbie comments):
;---------------------------------
; nasm -f bin -o hwnoint.com hwnoint.asm
org 100h
push word 0B800h ; segment of video memory
pop es ; (because stosw uses es:di)
mov di, (10 * 80 + 30) * 2 ; offset into screen
; (row * width + column) * 2 bytes/character
mov si, msg ; offset of our string
mov ah, 0B0h ; color (blinking black on cyan)
top:
lodsb ; get byte from [ds:si] into al
; and increment si for next one
or al, al ; this doesn't change al, but sets
jz depart ; the flags - if zero, we're done
stosw ; stores ax (char & color) to [es:si]
; and add 2 to di for next one
jmp short top ; do more
depart:
ret ; return to dos (or other caller)
msg db " Look, Ma! No ints! ",0 ; note 0, not '$', terminated
; '$' is just for int 21h/9
;------------------------------------
26 lines, counting blanks.
>>>Now let's compare that to one written in C++:
>
>>> #include <iostream.h>
>>> void main() { cout << "Hello, World!" }
2 lines.
Asm is 13 times worse, by this (rather meaningless, I think we agree?)
criterion.
So how much more productive was I in C++?
hwnoint.com - 42 bytes.
hwcpp.exe - 112,640 bytes.
Almost 2682 times more productive! I had no idea C++ was *that* much
better. Of course, the two programs do slightly different things. The
C++ program can be re-directed, and mine can't. Mine puts the text at a
specified place on the screen, in a specified color, the C++ just does
black and white at the current cursor position...
Which leads me to an odd observation. My program, by default, produces
blinking text. Running hwcpp.exe turns my damn blink off, and leaves it
that way! (until I turn it back on, or reset video mode) Pretty
astonishing for a program with no hidden code! What would I change in
the C++ code to get it to *not* do that?
Best,
Frank
Randall Hyde
>
> Your questions are stupid since they have absolutely nothing to do with any
> HIDDEN CODE. Unless you can "unravel" the hidden C++ code in any of your
> examples above, you've failed the challenge. If there is any hidden C++ code, as
> Randall hid his code in a library that was precompiled with ASM code, show it.
> Not a single one of your points demonstrated any hidden C++ code. Did you take
> one of Randall's classes? Then why can't you understand simple code and simple
> english? There is no C++ code that is being hidden. Not one. The "cout" keyword
> is a standardized keyword for the C++ language, it isn't a non-standardized
> macro or a non-standardized function that hides a bunch of other C++ code. Get a
> clue please, that way I won't have to embarass you in public like this anymore.
>
I can see why you'd flunk me as a teacher :-)
You are incapble of learning!
You've already been told by your's truly that "cout"
is not a C++ keyword. Yet you continue to insist that
it is one (sorta like you insist that there is no "hidden code"
here).
I really like how you claim there was no function call here.
I guess you don't consider "operator<<" to be a function, right?
I think you last statement was really funny!
Sometimes I think you work real hard at say ridiculous things
just for the emotional impact they cause; other times I tend
to believe you really *are* that ignorant. It's amazing how
you're constantly lecturing people on what is "C" and what
is "C++" but your examples are completely wrong (e.g.,
"cout is a keyword").
As for the "hidden code" thing, well, behave like an
Ostrich with its head in the sand. Crying out "that's
hidden code in the HLA Standard Library, but C++'s
library routines are not 'hidden'" is the height of
intelligence, let me tell you.
Cheers,
Randy Hyde
P.S., boy, you must have one heck of a persecution
complex; after you've been spanked from all directions
you still insist on use the same broken examples. One
would think you *thrive* on looking bad and getting
whomped on by everyone.
Randall Hyde
"The_Sage" <thee...@azrmci.net> wrote in message news:bdivlvoc326sl1qok...@4ax.com...
>
> You are quoting out of context. Get a clue by finishing off "a syntax and a
> processor's instruction set does not" with the topic that it was refering to.
Feel free to refresh our memory.
AFAIKT, the comment ended right there.
Are you backtracking and now saying that a processor's instruction set
does have a syntax? Are you willing to go rewrite your post with this
new information?
> You are an idiot Randall, so don't even bother trying or I will have to embarass
> you again
One thing's for sure - you embarass me a lot :-)
You wouldn't believe how many emails I get along the lines
of "why do you even bother with that idiot!" (their name calling, not mine).
Trust me, you're not even close to embarassing me. Rene did a much
better job than you'll ever do (unless you grow up at some point) and
that didn't phase me. So do your damndest...
> like I did with your inablity to post an efficient pure ASM version of
> a pure C++ program, and your complete inability to post ASM code for a regular
> expression engine, which you obviously don't and haven't ever created since the
> C version is all you have. You preach ASM and then post C and that tells us all
> we need to really know about what you really believe.
Remember me asking you to repost this "mythical" C that I supposedly put up?
I've yet to see you do that. You can easily prove you're right and I'm wrong
by simply copying that C code to a message and following up that one with
this code.
It's one thing to make up some line that's ambigious, pure opinion, etc.,
and then argue about it until your blue in the face. OTOH, when you
you post something that's obviously false and anyone can check for
themselves, you look pretty stupid. I'd say you lose a lot of credibility
by doing that, but you have no credibility to lose at this point...
>
> The Sage
>
> =============================================================
> My Home Page : http://members.cox.net/the.sage
>
> "The men that American people admire most extravagantly are
> most daring liars; the men they detest the most violently are
> those who try to tell them the truth" -- H. L. Mencken
> =============================================================
I think you believe your .sig a bit too much.
It pretty much explains your thought process.
Cheers,
Randy Hyde
Andreas Schmitz
> That is what makes the language *efficient*. There is no hidden C++ code there.
> Try again.
So I guess my understanding of the word "efficient" and the word "code"
in the English language differ quite a lot from your's.
>>> void main() { cout << "Hello, World!" }
>>
>> ^^
>>You know what that is? Yep, This is like calling a function. Didn't
>>know?
> Wrong again, it is a C++ keyword, not a function. Obviously you don't know much
> about higher level languages.
So my understanding of one of the words "keyword", "wrong" or "know"
differ from your's.
This is stupid man.
[insert your new public embarassement here]
> english? There is no C++ code that is being hidden. Not one. The "cout" keyword
> is a standardized keyword for the C++ language,
Just hope Bjarne Stroustrup never reads this.
> Get a
> clue please, that way I won't have to embarass you in public like this anymore.
Oh please, don't hold back.
Regards, Andreas
C
[snip]
> ;---------------------------------
> ; nasm -f bin -o hwnoint.com hwnoint.asm
>
> org 100h
>
> push word 0B800h ; segment of video memory
> pop es ; (because stosw uses es:di)
> mov di, (10 * 80 + 30) * 2 ; offset into screen
> ; (row * width + column) * 2 bytes/character
> mov si, msg ; offset of our string
> mov ah, 0B0h ; color (blinking black on cyan)
> top:
> lodsb ; get byte from [ds:si] into al
> ; and increment si for next one
> or al, al ; this doesn't change al, but sets
> jz depart ; the flags - if zero, we're done
> stosw ; stores ax (char & color) to [es:si]
> ; and add 2 to di for next one
> jmp short top ; do more
> depart:
> ret ; return to dos (or other caller)
>
> msg db " Look, Ma! No ints! ",0 ; note 0, not '$', terminated
> ; '$' is just for int 21h/9
> ;------------------------------------
>
> 26 lines, counting blanks.
[snip]
Nice example, but we can do better than that...
org 100h
push word 0b800h ; 3 init ES
pop es ; 1
mov di, (10*80 + 30) *2 ; 3 set DI ptr to scr
mov si, msg ; 3 set SI ptr to msg
mov ax, 0b000 + ' ' ; 3 ld first char & colour
.lp:
stosw ; 1 wr to scr
lodsb ; 1 ld next char
test al, al ; 2 loop while not '\0'
jnz .lp ; 2
ret ; 1 => 20
msg db "Look, Ma! No ints! ",0 ; 19
=> 39 bytes (com)
...That shaves off some bytes and a couple
of LOC; plus the loop is more efficient. :-)
C
2003/9/11
Johannes Kroll
The_Sage <thee...@azrmci.net> wrote:
> >Reply to article by: Andreas Schmitz <vstr...@arcor.de>
> >Date written: 10 Sep 2003 02:14:22 GMT
> >MsgID:<slrnblt21j.r...@sammael.tabu.stw-bonn.de>
>
> [...]
>
> >> Now let's compare that to one written in C++:
>
> >> #include <iostream.h>
> > ^^^^^^^
>
> >So much for hidden code.
>
> It's a header, not code.
You're probably right. So try linking your program without any libraries
(see your compiler's manual on how to do that) and see what you get.
> >> #include <iostream.h>
> ^^
> >So you don't even know "standardized" C++...
>
> So you don't even know what a *header* is. At least you got the C++ part right,
> finally.
iostream.h isn't a standard C++ header. You're not using any namespace either,
so you're example shouldn't compile with any C++ standards compliant compiler.
> [...]
> >> void main() { cout << "Hello, World!" }
> >
> > ^^
>
> >You know what that is? Yep, This is like calling a function. Didn't
> >know?
>
> Wrong again, it is a C++ keyword, not a function. Obviously you don't know much
> about higher level languages.
This is a bitshift operator, which is overloaded for the basic_ostream class.
It's translated to a call to a method of the cout object by the compiler.
> [...]
> Your questions are stupid since they have absolutely nothing to do with any
> HIDDEN CODE. Unless you can "unravel" the hidden C++ code in any of your
> examples above, you've failed the challenge. If there is any hidden C++ code, as
> Randall hid his code in a library that was precompiled with ASM code, show it.
> Not a single one of your points demonstrated any hidden C++ code. Did you take
> one of Randall's classes? Then why can't you understand simple code and simple
> english? There is no C++ code that is being hidden. Not one. The "cout" keyword
> is a standardized keyword for the C++ language, it isn't a non-standardized
cout isn't a C++ keyword at all. It's an object of basic_ostream.
Phil Carmody
> Now let's compare that to one written in C++:
>
> #include <iostream.h>
Ah, now I know why I killfiled you. (I've just changed newsreader, so I have to go through teh tedium of nonsense like yours again. Briefly.)
Phil
Frank Kotler
> Nice example, but we can do better than that...
>
> org 100h
> push word 0b800h ; 3 init ES
> pop es ; 1
> mov di, (10*80 + 30) *2 ; 3 set DI ptr to scr
> mov si, msg ; 3 set SI ptr to msg
> mov ax, 0b000 + ' ' ; 3 ld first char & colour
> .lp:
> stosw ; 1 wr to scr
> lodsb ; 1 ld next char
> test al, al ; 2 loop while not '\0'
> jnz .lp ; 2
> ret ; 1 => 20
>
> msg db "Look, Ma! No ints! ",0 ; 19
>
> => 39 bytes (com)
>
> ...That shaves off some bytes and a couple
> of LOC; plus the loop is more efficient. :-)
Good one! Now C++ is 2888 times more productive! :)
Best,
Frank
White Wolf
Phil! Please (usually) do not repost his nonsenses. :-) I have also
killfiled him. But I am thinking making this into a T-shirt. Think about
it. It will detect any decent C++ programmer without a need to say a word.
:-)
- .h
- void main (I guess that seems to be an attribute of the poster as well)
- No \n or endl so nothing is guaranteed to be printed
- Missing semicolon (Pascal residue)
- Nonexisting indentation
This should make anyone knowing C++ at least laugh. But I am still afraid
that in such a T-shirt I might get attacked...
--
WW aka Attila
Phil Carmody
> The_Sage wrote:
> > Its definition should be independent of any particular hardware or
> operating
> > system.
>
> So how do you write device drivers or efficient GUI code? One is
> implicitly tied to the hardware by its nature and the second can't be
> done while there exists no GUI standardisation
Oh, so that explains why my serial driver can't control my network
card. Surely they're both 0s and 1s over a piece of wire?
And I can't pick up BBC5 on my microwave either :-|
Phil
The_Sage
>Date written: Thu, 11 Sep 2003 03:12:43 GMT
>MsgID:<LKR7b.415679$uu5.75839@sccrnsc04>
>Hi Sage,
>Okay, you've convinced me. Asm is bad. "How bad is it?"...
>>>>So here it is again.
>Again?
Obviously you haven't been following this thread. This is about the fifth time I
asked Randall to give us an example -- and he has still failed to respond in a
intelligent manner to this reasonable request.
>26 lines, counting blanks.
>2 lines.
Correction: ASM is 13 times less efficient that C++ as a language. For every
function you need, your ASM program will require at least 13 times more lines of
code than C++. In fact, the organization that has standardized function points
has determined that your ASM program, on average, is 320/53 = 6 time less
efficient than C++. Your example pretty much confirms that. But if you would
like even more conclusive proof, we can compare an ASM program written for a
highly graphical Windows application to one written in C++.
>So how much more productive was I in C++?
>hwnoint.com - 42 bytes.
>hwcpp.exe - 112,640 bytes.
You are obviously are an amatuer C++ programmer -- assuming you know how to
program in C++ at all. You create a com file and an exe file and then expect
that to be a one-for-one comparison? Is this because you don't know the
difference between a com file and an exe file, or is it because you don't know
how to set your C++ compiler options to output a com file?
>Almost 2682 times more productive!
Since when is the number of bytes how productivity is measured? Haha! Get real!
That isn't how anyone in the whole world measures productivity. That obviously
does not fit the definition for "productive" and obviously you haven't been
paying attention to any of this thread. The issue was *EFFICIENCY*, not
productivity and it most certainly was not executable size. Are you going to go
off on wild tangents or are you going to stick to the subject?
>had no idea C++ was *that* much
>better. Of course, the two programs do slightly different things. The
>C++ program can be re-directed, and mine can't. Mine puts the text at a
>specified place on the screen, in a specified color, the C++ just does
>black and white at the current cursor position...
You wrote a more versatile program but you still couldn't prove it was more
efficient, so you wasted your time by going beyond what was called for in the
assignment. Then you compared apples to oranges anyway by comparing an exe to a
com file. Sorry but you still get an F-. Go to the back of the class and start
all over.
>Which leads me to an odd observation. My program, by default, produces
>blinking text. Running hwcpp.exe turns my damn blink off, and leaves it
>that way! (until I turn it back on, or reset video mode) Pretty
>astonishing for a program with no hidden code! What would I change in
>the C++ code to get it to *not* do that?
Better ask an expert because you are obviously not one.
The_Sage
>MsgID:<QaT7b.7612$Yt....@newsread4.news.pas.earthlink.net>
>>Your questions are stupid since they have absolutely nothing to do with any
>>HIDDEN CODE. Unless you can "unravel" the hidden C++ code in any of your
>>examples above, you've failed the challenge. If there is any hidden C++ code, as
>>Randall hid his code in a library that was precompiled with ASM code, show it.
>>Not a single one of your points demonstrated any hidden C++ code. Did you take
>>one of Randall's classes? Then why can't you understand simple code and simple
>>english? There is no C++ code that is being hidden. Not one. The "cout" keyword
>>is a standardized keyword for the C++ language, it isn't a non-standardized
>>macro or a non-standardized function that hides a bunch of other C++ code. Get a
>>clue please, that way I won't have to embarass you in public like this anymore.
>I can see why you'd flunk me as a teacher :-)
>You are incapble of learning!
Wrong again! I would flunk you because you are a total idiot. You don't know
anything much about software engineering and you certainly don't know anything
about how to write an efficient ASM program. You just keep rambling on and on,
but you are all mouth and no demonstration. I posted the code and you didn't
appear competent enough to counter my example. I rest my case, you have no clue
and I doubt you ever will because you base everything you say on your
overinflated ego feelings instead of demonstrable facts. Too bad, because I
heave never seen an efficient regular expression engine written in ASM and
obviously neither have you.
The_Sage
>MsgID:<0mT7b.7629$Yt....@newsread4.news.pas.earthlink.net>
>One thing's for sure - you embarass me a lot :-)
No I don't, you embarass yourself everytime you open your mouth.
And once again, all you did was post small talk and no code, no logical and
intelligent counter-argument, no ASM code that corresponds to your C regular
expression engine, and no ASM code more efficient than the C++
#include <iostream.h>
void main() { cout << "Hello, World!" }
Like I said, Randall, get a clue please!
sinewave
> But I am still afraid that in such a T-shirt I might get attacked...
try this version...
cout << "I have five dollars for each of you punks."
regards,
phil
sinewave
why no cld? mov cx,19 ; rep movsb [agner?] msg is 20 bytes.
regards,
phil
Beth
> also, development in forth is usually some orders of magnitude
faster than
> almost any other language, you no longer have an "edit,
compile/assemble,
> link, debug" development cycle, what you have is an "edit, debug"
cycle.
the
> ability to easilly test each function as its defined. You could do
this
> but there would be a hell of alot of juggling to do that would make
the
> whole effort a waste of time :)
Indeed; This is why I've hinted at Forth influence about all the stuff
I go on about with "seamless" development...because, as you rightly
note, Forth can often be "orders of magnitude faster than any other
language"...and that's not "syntax" or "levelness" or any other thing
that people usually prattle on about in this context...it's all to do
with the correct "seamless" development attitude...
I'll say it again; "More haste, less speed"...there's many who go on
and on about how crucial development speed is but then use and / or
write tools that have absolutely no consideration shown to the
mechanics of interacting with those tools for speeding development...
If you like, I do find some of the "development speed" arguments
slightly ironically stated...you know, it's a bit like saying "the
choice of colour is crucially important for interior design and
decorating of a home"...and then when someone asks "so, what colours
do you advise?", the answer then goes and contradicts the earlier
advice: "oh, we'll just use whatever spare paint we can find left over
in these old tins of paint, regardless of what colour it is"...
For instance, for all those who say "assemble / compile speed" as
being really important, I've already stated the method by which you
can make it so fast that it becomes so negligable, you could call it
"instant"...just use incremental compilation with an IDE that feeds
only the changes to the tool...it could even be incredibly poorly
written but it would still outcompete even the fastest non-incremental
tools hands down...
So (effectively) "fast", in fact, that we can not only do the whole
Forth thing of testing functions in isolation to speed up development
(BASIC can do this too, ordinarily, as well :)...there can be
continuous instant feedback on what you're typing...you don't even
need to be _finished_ for the tool to be letting you know where you
made your syntax errors...
Heck, we could at least tokenise as we're going (many BASICs do this,
not just to speed things up but to save memory, in Ye Olde Dayes when
you'd type your programs direct into RAM and type "RUN" to make it go
:)...you'd keep ASCII, of course, for passing around your source code
to different machines and stuff...but, otherwise, you could even save
some disk space by using an editor that loads and saves tokenised
programs, converting them to plain text you can read in the
editor...sure, we've got tons of RAM and hard disk these days, but the
first rule still applies and always will apply: "If you don't need it,
then don't take it because something else could make far better use of
it"...plus, the space saved could be filled up by, say, adding on the
symbol table or debug information or whatever onto the end of a file
so that, in the same space, you've got yourself a program that doesn't
waste time recalculating things it's already worked out before...
I mean, if people are _serious_ about this whole "development speed"
thing, then why does there appear to be _NO EFFORT_ made to improve it
whatsoever in the "traditional" tool paradigm? But, of course, there's
the joke for you...pre-PC stuff on other machines was doing this all
routinely...Randy mentions doing some of this stuff I mention on an
Apple and, sure, I don't hide that my influences here (including using
Forth, many moons ago :) are from Olden Times...
That's the even bigger reason why I can't accept the continual excuse
of "development time is so important, that's why, regrettably,
software is full of bugs and crap"...it _sounds_ like a legitimate
excuse until you realise that things have actually gone very much
_backwards_ in many ways on numerous fronts...in relative terms,
software is getting _worse_, not better...
Things are getting bigger and more complex? Then, could someone please
explain why tools should revert and undo developments back into the
1960s? Surely, if things are getting bigger and more complex, you
improve your tools to cope with that...not revert them to older
paradigms and wasteful means of going about things...
And, truth be told, the whole language issue is not really all that
significant against the background of inexperienced programmers (as
said to Phil in another post, "the right tool for the right job" is
_insignificant_ if the programmer does not have the skills to use the
right tool properly and productively...after all, it's quite true that
computerisation can do miracles to someone's productivity by taking on
a lot of the burdens...yet, in the hands of a clueless newbies who has
no idea which way round the mouse should go, all that power is
_useless_ and _insignificant_..."It's not what you use, it's the way
that you use it", to distort the popular song :)...
It's why I show little sympathy to "this tool compiles slower"
arguments...who cares? That is, it _would_ be important, perhaps, if
preventative debugging, seamless tool development, concrete
pre-planning and other things were being employed...then, sure, I can
see the tool's slowness being an important factor...but, currently,
the infinitely more crucial factors are being _completely neglected_
that ignoring them and focusing on speeding up a process that rare
indeed actually causes any problems (the difference here is
_psychological_, you see...when you're sitting there waiting for the
tool to work, then an extra few seconds seems terrible...yet, happily,
that same person will wander off for a half hour to make a cup of
coffee and have a chat, as leisurely as you like...the unimportant -
which strangely gets all the attention -is being paled into
insignificance by the truely important)...
"Things which matter most must never be at the mercy of things which
matter least"
[ Goethe ]
"Sometimes when I consider what tremendous consequences come from
little things...
I am tempted to think...
There _are_ NO little things"
[ Bruce Barton ]
Beth :)
Mark I Manning IV
<BethS...@hotmail.NOSPICEDHAM.com> wrote:
>
> Indeed; This is why I've hinted at Forth influence about all the stuff
> I go on about with "seamless" development...because, as you rightly
> note, Forth can often be "orders of magnitude faster than any other
> language"...and that's not "syntax" or "levelness" or any other thing
> that people usually prattle on about in this context...it's all to do
> with the correct "seamless" development attitude...
wow you know forth too!!
> I'll say it again; "More haste, less speed"
actually, go slow - youll be faster in the end - when your finished delete
all your sources and start over (dont tell you boss :) - when your
finished for the second time you'll have a better solution than your
initial attempt. i do this sometimes.
...there's many who go on
> For instance, for all those who say "assemble / compile speed" as
> being really important, I've already stated the method by which you
or you can do semi compilation at edit time. isforth does none of this
yet can compile 800k of forth source per second on my k6-3/500 laptop.
> can make it so fast that it becomes so negligable, you could call it
> "instant"...just use incremental compilation with an IDE that feeds
> only the changes to the tool...it could even be incredibly poorly
> written but it would still outcompete even the fastest non-incremental
> tools hands down...
no doubt. and i do think that having to wait even 30 seconds for the
"download to the target" or "the compile" etc is a huge waste of time in
the long run but the usual attitude is "its just someone elses money im
idling away so..." :/
>
> So (effectively) "fast", in fact, that we can not only do the whole
> Forth thing of testing functions in isolation to speed up development
> (BASIC can do this too, ordinarily, as well :)...there can be
> continuous instant feedback on what you're typing...you don't even
> need to be _finished_ for the tool to be letting you know where you
> made your syntax errors...
>
kinda like that realy annoying option in ms word where it keeps telling
you your crap at spelling as you edit :/ lol
>
> I mean, if people are _serious_ about this whole "development speed"
> thing, then why does there appear to be _NO EFFORT_ made to improve it
> whatsoever in the "traditional" tool paradigm? But, of course, there's
> the joke for you...pre-PC stuff on other machines was doing this all
> routinely...Randy mentions doing some of this stuff I mention on an
> Apple and, sure, I don't hide that my influences here (including using
> Forth, many moons ago :) are from Olden Times...
forth is far from dead though, tho i dont like what the ans comittee has
done with it, i think "ans forth" is worse than "c++ on an 8051" but shhhh
- dont tell my boss i said that :)
> That's the even bigger reason why I can't accept the continual excuse
> of "development time is so important, that's why, regrettably,
> software is full of bugs and crap"...it _sounds_ like a legitimate
> excuse until you realise that things have actually gone very much
> _backwards_ in many ways on numerous fronts...in relative terms,
> software is getting _worse_, not better...
only main-stream software is getting worse, there are still a few die-hard
REAL coders out there and some of them have influence on the newbies
(sometimes).
"do you want it right now - or right?"
"if we cant find the time to do it right the first time, where in the hell
are we going to find the time to do it over?".
are a couple of my fave things not to say to a micro-manager (i dont have
any of those at my present job).
> Things are getting bigger and more complex? Then, could someone please
> explain why tools should revert and undo developments back into the
> 1960s? Surely, if things are getting bigger and more complex, you
> improve your tools to cope with that...not revert them to older
> paradigms and wasteful means of going about things...
like JSP you mean ??? :)
(no guys that has nothing to do with java... or does it ?) lol
> And, truth be told, the whole language issue is not really all that
> significant against the background of inexperienced programmers (as
> said to Phil in another post, "the right tool for the right job" is
> _insignificant_ if the programmer does not have the skills to use the
> right tool properly and productively...after all, it's quite true that
> computerisation can do miracles to someone's productivity by taking on
> a lot of the burdens...yet, in the hands of a clueless newbies who has
> no idea which way round the mouse should go, all that power is
actually, if you look at the number of hours of "house work" the modern
housewife does during the week with all of those modern conveniences etc
you will see that she isnt realy doing much more than she would have done
200 years ago without them. the problem hasnt changed, theres till the
same ammount of work to do in a given time, its just the tools that have
changed -
coders cant produce more than 6 lines of bug free coder per day in ANY
language - good coders dont produce any more than 2 or 3 per day.
> _useless_ and _insignificant_..."It's not what you use, it's the way
> that you use it", to distort the popular song :)...
lol :)
>
> _psychological_, you see...when you're sitting there waiting for the
> tool to work, then an extra few seconds seems terrible...yet, happily,
> that same person will wander off for a half hour to make a cup of
> coffee and have a chat, as leisurely as you like...the unimportant -
> which strangely gets all the attention -is being paled into
> insignificance by the truely important)...
well i think that someone who can get up and wander and chat and have a
coffee any time he wants can still be a very productive engineer, this
seeming wastfulness gives his mind a chance to digest the problems at
hand. once he gets back to his desk however he should be on the stick,
not the net.
> "Things which matter most must never be at the mercy of things which
> matter least"
> [ Goethe ]
!
> "Sometimes when I consider what tremendous consequences come from
> little things...
> I am tempted to think...
> There _are_ NO little things"
> [ Bruce Barton ]
>
> Beth :)
>
are those from memory or from /usr/games/fortune ??? :)
Beth
> > [ Not being able to see the original postings due to the flood of
Hyde vs
> > Sage posts -- my poor newsreader has indigestion -- please excuse
the bad
> > protocol of replying to both messages in one ]
>
> forgiven - and agreed, all that bullshit spam is uncalled for - it
would
> be better if some people took their wars elsewhere!
Agreed; So, now, before anyone complains about my posts being long and
straying off-topic...consider how, if I split them off into multiple
posts to make each one short and on-topic, you'd have a constant
spamming like that nonsense...I think my long post method is better
than that, as at least you can ignore me rambling away in one easy
convenient skip over my post when it starts to bore you ;)
Beth :)