move this Forum somewhere else?

Anybody got any ideas on bringing this Forum back to dsicussions on
ASM, without the bilge?

Rod Pemberton

2009-02-15 07:36:09 UTC

Post by Terence
Anybody got any ideas on bringing this Forum back to dsicussions on
ASM, without the bilge?

"White tea" recently posted an asm related post that nobody, including you,
responded to...

Ok, I'll humor you. What's the smallest set of general (i.e., no fpu, no
SSE, no XMM, etc) x86 assembly instructions needed to program general x86
assembly? There, that's asm related... Yes? Is it lodsb, stosb, push,
pop, xchg, loop, jcxz and arithmetic instructions? Or, can you think up any
other use for "rep lodsb" other than that posted by Jim Leonard on
comp.lang.asm.x86 recently?

--
You know, people come and go. alt.* is/was for stuff that's less
controlled. comp.*, e.g., comp.lang.asm, is for assembly "without the
bilge". If you want to see a "dead" group, try that one... And,
comp.lang.asm.x86, which is moderated, is for x86 assembly - at the
discretion of Chuck... But, moderated groups are a pain in the rear. You
can't read what others posted until they clear the moderator, so there might
be 10 or most posts saying the same thing. And, when you reply, there might
be 10 or more posts that say the same thing... And, you have to wait and
wait and wait for the moderator to see if anyone replied, who replied, and
what they said. And, you're never quite sure why some posts "go missing".
Were they "moderated", i.e., censored by deletion? The moderators always
claim they never got the post... Moderated groups loose the "immediacy" of
non-moderated groups.

Well, I haven't seen a post here from the "KKK" in a while (Kotler,
Kleebauer, or Kern). They were contributing much "pure" assembly content.
Actually, over the few years that I've been reading this newsgroup, it's
never been 100% assembly, although there was much more traffic and a bit
more assembly. Except for the past two years, 40% seemed to be Hyde
promoting HLA and Betov insulting him or promoting RosAsm, with another 20%
unrelated Delphi stuff from Skybuck or "hutch--" lying (at least that's what
I believe) about his MASM licensing agreements... So, for now, we've got
some "silence." Enjoy it.

I think the fact that there is some non-assembly is a nice thing as long as
you aren't bombarded with hundreds of posts on the same thing or with
constant arguments, ala Hyde/Betov/Skybuck/hutch-- etc. We finally got Hyde
to stop arguing with Betov. He left. That's unfortunate, since he knew
assembly, but some people just don't have a purpose, or aren't willing to
contribute, without arguing. I attempted to engage Hyde in many assembly
and non-assembly topics, especially energy. He almost never responded.
But, a few words from Betov, would produce 100+ posts. I even attempted to
help him see that HLA could be much more than what it is with some minor
changes. He seemed to fail to comprehend. That stunned me. Perhaps, he
was just rejecting the idea, but had some psychological inability to say so
politely. Anyway, I like the fact we can discuss assembly on a broader
scope: as MASM, as NASM, as GAS, for OS development, for algorithms, for
applications, etc.

--
Individuals posting to comp.lang.c are so mean and hostile to anything
outside an excessively narrow range of C topics that you can't even post a C
only related question without 100+ insult posts. The entire newsgroup is
"spammed" by these "insult and control" posts. If you ask anything outside
ISO C99 or the N1256 draft on c.l.c, you'll have a small clique of "ISO C
only!" people who will vehemently lambast you to enforce their perspective
on what should or shouldn't be discussed in comp.lang.c. Plus, you'll have
another twenty or so posts from idiots, I call "parrots," who you'd never
even know were there since they *never* post anything C related. But, as
soon as the "parrots" think you've attacked the clique, the "parrots" will
post insults, attempt to enforce their perspective of group control, and
blather idiocy and unworthy acclaim for members of the clique. Except for
one member of the clique, this group of individuals seems to be closely
related to a book on C, "C Unleashed," which was a market failure since it
is an exceptionally thin on content and an insignificant piece of trash
compared to other more complete and accurate books on C. Since the authors
were all from c.l.c., they apparently still have a vested interest in
pushing their worthless and frequently inaccurate beliefs about C onto
everyone interested in C who posts to c.l.c. Perhaps they believe if they
continue pushing their beliefs on C long enough, their beliefs will come
true or they'll be validated somehow. (Unlikely, since their beliefs aren't
based in fact. This c.l.c. aggression has been going on for almost a decade
now...)

Rod Pemberton

s***@yahoo.com

2009-02-15 20:06:59 UTC

Post by Terence
Anybody got any ideas on bringing this Forum back to dsicussions on
ASM, without the bilge?

[snip]

Anyway, I like the fact we can discuss assembly on a broader
scope: as MASM, as NASM, as GAS, for OS development, for algorithms, for
applications, etc.

While thinking of the subject of polluting asm with c, I've put up
release 1.0 of small-c with nasm code generation.
http://project-fbin.890m.com/index.htm

As to pure asm and the winders pain, cmd.exe, the Project Flop_See is
there as well. It uses only the RomBios interrupt service routines,
so it may be a somewhat useful basis of a like utility for someone's
hobby OS development (real mode).

-just a 'heads up'.

Steve
[snip]

Rod Pemberton

2009-02-15 22:22:25 UTC

Post by s***@yahoo.com
While thinking of the subject of polluting asm with c, I've put up
release 1.0 of small-c with nasm code generation.
http://project-fbin.890m.com/index.htm

Although I think there is a problem in the code I'm working on, I'll give
your new version a whirl and see if that works. The Evgueniy Vitchev
version might save you some work. For example, it has the dodo() and
dofor() routines that'll should almost drop right in:

http://www.physics.rutgers.edu/~vitchev/smallc-i386.html

Last night, for the first time since we last talked about it, I worked on
"my" port of Small C (Evgueniy Vitchev version) I was trying to get it
bootstrapped with your Small C port NCC. I found outdec() wasn't working
properly in "my" port. They actually had two routines: outdec() calling
outint(). Something was wrong with that code. Anyway, it wouldn't output
the numbers. It was using recursion... I rewrote it without recursion.
But, it would still fail, but only sometimes... As a .com that almost
consumes 64k, I wasn't sure if this was a memory issue or coding issue. So,
I replaced it with Bob White's version of outdec() in Small C for CP-M/86
(the same as in NCC). That works. However, something still isn't correct.
It looses the labels used in assembly and complains about not being able to
subscript arrays (2nd error) in hier11(), as a side effect. I suspect that
one of the numerous "pointer as integer" conversions in this version of
Small C isn't correct. It also has a few more routines that weren't part of
NCC or Small C CP-M/86, so maybe they weren't written compatibly with the
original source. Anyway, I'm planning on looking at it some more today.
I've had problems debugging it. Everytime I try to output any information
via the internal error() or pl() etc. print routines, it goes "off into the
weeds" and causes a hard lockup with Win98SE...

Rod Pemberton

Alexei A. Frounze

2009-02-15 23:47:42 UTC

Post by s***@yahoo.com
While thinking of the subject of polluting asm with c, I've put up
release 1.0 of small-c with nasm code generation.
http://project-fbin.890m.com/index.htm

Although I think there is a problem in the code I'm working on, I'll give
your new version a whirl and see if that works. The Evgueniy Vitchev
version might save you some work. For example, it has the dodo() and
http://www.physics.rutgers.edu/~vitchev/smallc-i386.html
Last night, for the first time since we last talked about it, I worked on
"my" port of Small C (Evgueniy Vitchev version) I was trying to get it
bootstrapped with your Small C port NCC. I found outdec() wasn't working
properly in "my" port. They actually had two routines: outdec() calling
outint(). Something was wrong with that code. Anyway, it wouldn't output
the numbers. It was using recursion... I rewrote it without recursion.
But, it would still fail, but only sometimes... As a .com that almost
consumes 64k, I wasn't sure if this was a memory issue or coding issue. So,
I replaced it with Bob White's version of outdec() in Small C for CP-M/86
(the same as in NCC). That works. However, something still isn't correct.
It looses the labels used in assembly and complains about not being able to
subscript arrays (2nd error) in hier11(), as a side effect. I suspect that
one of the numerous "pointer as integer" conversions in this version of
Small C isn't correct. It also has a few more routines that weren't part of
NCC or Small C CP-M/86, so maybe they weren't written compatibly with the
original source. Anyway, I'm planning on looking at it some more today.
I've had problems debugging it. Everytime I try to output any information
via the internal error() or pl() etc. print routines, it goes "off into the
weeds" and causes a hard lockup with Win98SE...
Rod Pemberton

I wonder if it was easier, more fun and more fruitful to implement a
subset of Forth or Lisp than C. C is primitive and yet very wordy and
nonuniform syntactically.

Alex

s***@yahoo.com

2009-02-16 02:53:06 UTC

Post by Alexei A. Frounze

Post by s***@yahoo.com
While thinking of the subject of polluting asm with c, I've put up
release 1.0 of small-c with nasm code generation.
http://project-fbin.890m.com/index.htm

Although I think there is a problem in the code I'm working on, I'll give
your new version a whirl and see if that works. The Evgueniy Vitchev
version might save you some work. For example, it has the dodo() and
http://www.physics.rutgers.edu/~vitchev/smallc-i386.html
Last night, for the first time since we last talked about it, I worked on
"my" port of Small C (Evgueniy Vitchev version) I was trying to get it
bootstrapped with your Small C port NCC. I found outdec() wasn't working
properly in "my" port. They actually had two routines: outdec() calling
outint(). Something was wrong with that code. Anyway, it wouldn't output
the numbers. It was using recursion... I rewrote it without recursion.
But, it would still fail, but only sometimes... As a .com that almost
consumes 64k, I wasn't sure if this was a memory issue or coding issue. So,
I replaced it with Bob White's version of outdec() in Small C for CP-M/86
(the same as in NCC). That works. However, something still isn't correct.
It looses the labels used in assembly and complains about not being able to
subscript arrays (2nd error) in hier11(), as a side effect. I suspect that
one of the numerous "pointer as integer" conversions in this version of
Small C isn't correct. It also has a few more routines that weren't part of
NCC or Small C CP-M/86, so maybe they weren't written compatibly with the
original source. Anyway, I'm planning on looking at it some more today.
I've had problems debugging it. Everytime I try to output any information
via the internal error() or pl() etc. print routines, it goes "off into the
weeds" and causes a hard lockup with Win98SE...
Rod Pemberton

I wonder if it was easier, more fun and more fruitful to implement a
subset of Forth or Lisp than C. C is primitive and yet very wordy and
nonuniform syntactically.

I've been mulling over that very idea, for the last 6 months,
something closer to Lisp as it turns out..
.dotted_operator.['operand_list', ... ] {; ...}

It turns out that John McCarthy used square brackets for code S-
functions and parenthesis for data S-expressions when he moved the
language description from the Fortran pseudo-code M-Expressions, to S-
expressions. See 'Recursive Functions of Symbolic Expressions and
Their Computation by Machine' AIM-008.pdf I just ran across this
document in the last two weeks.
ftp://publications.ai.mit.edu/ai-publications/pdf/

Steve

Post by Alexei A. Frounze
Alex- Hide quoted text -
- Show quoted text -

Rod Pemberton

2009-02-16 06:47:24 UTC

Post by Alexei A. Frounze
I wonder if it was easier, more fun and more fruitful to implement a
subset of Forth or Lisp than C. C is primitive and yet very wordy and
nonuniform syntactically.

(Repost...)

The backend of my most developed (none are completed yet) C compiler *was* a
FORTH interpreter in C. The method I used was very similar to really early
FORTH, which you won't find a working example of. The C code basically
mimics what is done in assembly once compiled. This is radically different
from the way FORTH interpreters are normally written in C today. I've since
modified it to work better with the C compiler, so it won't handle FORTH
anymore, and it's not a perfect match with the C compiler yet. So, it's
FORTH-ish. Unlike modern FORTH where each word has different actions or
behaviors for different "modes", this one has single behaviors for each
FORTH word like early FORTH prototypes by Moore in HLL's. FORTH words have
different actions for compile time and run time. But, you can't (or can't
do so easily) implement the dual nature of FORTH words in C when compiling
FORTH words as static values. So, I implemented (a subset of) FORTH much as
Charles Moore probably did originally with additional code to detect and
implement the additional run time behaviors of words, especially control
flow words like FOR, IF, etc. Implementing the backend was definately
easier than the first three C parsers. Just the main parser code of the
last one, which I used some different techniques from the other ones, I'd
say was comparable. The main parser code of this one is also much simpler
than the earlier ones. But, although I'ved added quite a bit of
functionality to this parser to turn it into a compiler, it's not fully
functional yet either... I've got some issues with a hash function to
resolve, some 32-bit C code that needs reworked for 16-bit C, I need to
write a register allocator, code de/re-blocking routines, stuff I'm
forgetting, etc.

Post by Alexei A. Frounze
subset of Forth or Lisp than C.

The smallest realistic LISP's have eight to fourteen required "primitive
operations". Other than that, I'm unfamiliar with LISP except that it uses
many parenthesis.

The smallest realistic FORTH's have nine to sixteen "primitives".
"Primitives" in FORTH are "words" ("words" are basically FORTH subroutines)
that aren't written in FORTH itself as most "words" are, but are coded in
assembly. They are the lowest level operations in a FORTH interpreter,
besides the interpreter itself.

FYI, more on counts of and lists of minimal sets for FORTH and LISP, see my
post here:
http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526

From my own research into C, C can be reduced to approximately 16 actions
and 20 arithmetic operations. But, the arithmetic operations need to
support multiple types... So, if you wanted a C that just supports integer,
e.g., without float. It'd be simpler. Or, if you only wanted a C that
supports unsigned integers, even simpler: ~36 small assembly routines.
That may be overly simplistic as cr88192 on comp.lang.misc tries to point
out to me... :-) But, it'll capture the "essence" of C even if trivially
incomplete. In fact, the set is small enough, that I'd think one could
implement a C-ish language in assembler using assembler macro's... With
enough work, one even make the assembler look like C, instead of just
functioning like C. Kleebauer seems good with assembler macro's and C. So,
I once asked him where his C in assembler macro's was. Although, I'm fairly
sure it's not that difficult for him, I'm still waiting for a response. ;-)

Post by Alexei A. Frounze
C is ...
nonuniform syntactically.

It's also nonuniform in structure. It appears to be block structured, but
it's not fully. At least, it's not as block structured as something like
FORTH, and probably COBOL. However, C can be converted fairly easily into
fully block structured code by undoing or separating the C code by scope
and/or nesting level. A FORTH-ish back end like I've done basically
requires block structured code since it doesn't have a way to represent the
nesting or scope of C code. That's one of the things on my to do list, but
it's not that hard.

Rod Pemberton
PS. Sorry, Terence!

s***@yahoo.com

2009-02-16 02:10:24 UTC

Post by s***@yahoo.com
While thinking of the subject of polluting asm with c, I've put up
release 1.0 of small-c with nasm code generation.
http://project-fbin.890m.com/index.htm

AT&T syntax, hmm. I thought I had this already, but ... I'll have to
check again what I thought I had...

Post by Rod Pemberton
Last night, for the first time since we last talked about it, I worked on
"my" port of Small C (Evgueniy Vitchev version) I was trying to get it
bootstrapped with your Small C port NCC. I found outdec() wasn't working
properly in "my" port. They actually had two routines: outdec() calling
outint(). Something was wrong with that code. Anyway, it wouldn't output
the numbers. It was using recursion... I rewrote it without recursion.
But, it would still fail, but only sometimes... As a .com that almost
consumes 64k, I wasn't sure if this was a memory issue or coding issue. So,
I replaced it with Bob White's version of outdec() in Small C for CP-M/86
(the same as in NCC). That works. However, something still isn't correct.
It looses the labels used in assembly and complains about not being able to
subscript arrays (2nd error) in hier11(), as a side effect. I suspect that
one of the numerous "pointer as integer" conversions in this version of
Small C isn't correct. It also has a few more routines that weren't part of
NCC or Small C CP-M/86, so maybe they weren't written compatibly with the
original source. Anyway, I'm planning on looking at it some more today.
I've had problems debugging it. Everytime I try to output any information
via the internal error() or pl() etc. print routines, it goes "off into the
weeds" and causes a hard lockup with Win98SE...
Rod Pemberton

I took a quick look at Vitchev's, at&t syntax is alittle foreign to
me, compare his divide routine with what I did.. you can get a divide
overflow that sends you off into the weeds, if the extention register
(e)dx), of (e)dx):(e)ax isn't preset to zero. But the intermittent
problems you describe also can be caused by the stack over running the
data area.

For .com, the dpmi server sets SP == FFF0h. Since I'm working small-c
in .com, I can also run small-c under a debugger. I happen to use
sid.exe, but debug should work as well. Running small-c under sid.exe
allowed me to find the issue in div(). Sure, the debuggers don't
understand all the instructions, but at least you can find at what
call things go bad.

hth.

Steve

Rod Pemberton

2009-02-16 06:47:32 UTC

Post by Rod Pemberton
Although I think there is a problem in the code I'm working on, I'll give
your new version a whirl and see if that works. The Evgueniy Vitchev
version might save you some work. For example, it has the dodo() and
http://www.physics.rutgers.edu/~vitchev/smallc-i386.html

AT&T syntax, hmm. I thought I had this already, but ... I'll have to
check again what I thought I had...

(Repost...)

Ha! Yeah, sorry, I ported mine to NASM... Then, I attempted porting it to
Small C.

In dodo() this 32-bit GAS:

ol("testl %eax, %eax");
ot("jne");tab();

becomes 16-bit NASM:

ol("test ax, ax");
ot("jne ");

For 32-bits, that'd be "eax, eax". The registers actually get reversed, but
since they're the same... It appears I converted tab() to a space. I don't
see any assembly in dofor(), although he used printf() instead of pl(),
which I corrected. Is there other assembly code you need in NASM, or parts
of the port you'd like posted? I think dodo() and dofor() were the new
additions.

Post by s***@yahoo.com
I took a quick look at Vitchev's, at&t syntax is alittle foreign to
me, compare his divide routine with what I did.. you can get a divide
overflow that sends you off into the weeds, if the extention register
(e)dx), of (e)dx):(e)ax isn't preset to zero. But the intermittent
problems you describe also can be caused by the stack over running the
data area.

Thanks. I'll make a note of that.

Post by s***@yahoo.com
For .com, the dpmi server sets SP == FFF0h. Since I'm working small-c
in .com, I can also run small-c under a debugger. I happen to use
sid.exe, but debug should work as well. Running small-c under sid.exe
allowed me to find the issue in div(). Sure, the debuggers don't
understand all the instructions, but at least you can find at what
call things go bad.

Basically, I don't use debuggers. I have in a few very rare circumstances.
In this case, if I don't make any progress outputting info I want to look
at, I may need to track down sid.exe.

Rod Pemberton

Rod Pemberton

2009-02-16 10:14:57 UTC

Thanks. I'll make a note of that.

Maybe you mentioned that previously. It seems I had already reworked his
divide routine. I also noted from your code that I may have made a couple
of mistakes in my GAS to NASM conversion... :-( I'm not 100% sure yet
though. All I know is there are a couple routines where we didn't come up
with similar assembly code. That might've been due to his changes or mine.
And, I haven't reviewed all of the assembly yet. Since, you've done more
work on Small C than I have and I'm still trying to bootstrap it, I'm
assuming your code is correct. Anyway, I'll look at the differences another
day...

Basically, I don't use debuggers. I have in a few very rare

circumstances.

Post by Rod Pemberton
In this case, if I don't make any progress outputting info I want to look
at, I may need to track down sid.exe.

Well, I found it - without a debugger. Previously, I recall only seeing the
issue when I used NCC to attempt a bootstrap. However, I noticed now that
when I compiled one of "my" versions with GCC it had the problem too. When
converting from GCC ANSI C to Small C, I missed removing two pointer
dereferences... Well, I said I thought it was a problem with "integer as
pointer" coding everywhere. I must've done the same thing the last time
too. I backtracked the code a bit before I restarted this time.
(Predictable?...) Anyhow, I still haven't got it bootstrapped though! So,
I'm going to sleep next...

Maybe you can give me a hint on the following. It complains about being
unable to open the include file C5LIB.C with this error:

... : Open failure on include file
#include C5LIB.C
No Available IOD
fopen STATE_ER error.

I'm not sure what that means other than perhaps the C5LIB.C fopen() routine
might've run out of file handles (?). I'm opening one additional file that
NCC doesn't to write out error messages since I don't like them mixed with
the code. Am I opening too many?...?

Oh, yeah, I tried the new version. Compiling smc386c.c with it put it way
over 64k... It's much larger than what the earlier version generates. I
haven't tried any smaller test programs.

Rod Pemberton

s***@yahoo.com

2009-02-16 15:36:06 UTC

Thanks. I'll make a note of that.

Basically, I don't use debuggers. I have in a few very rare

circumstances.

In this case, if I don't make any progress outputting info I want to look
at, I may need to track down sid.exe.

Well, I found it - without a debugger. Previously, I recall only seeing the
issue when I used NCC to attempt a bootstrap. However, I noticed now that
when I compiled one of "my" versions with GCC it had the problem too. When
converting from GCC ANSI C to Small C, I missed removing two pointer
dereferences... Well, I said I thought it was a problem with "integer as
pointer" coding everywhere. I must've done the same thing the last time
too. I backtracked the code a bit before I restarted this time.
(Predictable?...) Anyhow, I still haven't got it bootstrapped though! So,
I'm going to sleep next...
Maybe you can give me a hint on the following. It complains about being
... : Open failure on include file
#include C5LIB.C
No Available IOD
fopen STATE_ER error.
I'm not sure what that means other than perhaps the C5LIB.C fopen() routine
might've run out of file handles (?). I'm opening one additional file that
NCC doesn't to write out error messages since I don't like them mixed with
the code. Am I opening too many?...?

Yes, sounds like too many opens..
Since space is a primary issue, c5lib has just enough implemented to
self compile NCC.C, alot to be done before fleshing out the io lib,
like getting out of the 64k collar first... -no fseek() for example,
the file io is sequential only, text only.
There's stdin, stdout, stderr, a nasm_out, a c_in, an include_in. -
although the include_in is recycled for multiple includes, but one at
a time.

I wonder if you could try writing your error messages to stderr, and
at the cmd.exe level redirect console output to a file.

Oh, yeah, I tried the new version. Compiling smc386c.c with it put it way
over 64k... It's much larger than what the earlier version generates. I
haven't tried any smaller test programs.

That's alittle mystifying, I see alittle size reduction, which is what
I expect since the code generation of instruction groups has been
improved to shorter forms, in a couple of places. You might try
deleting the generated nasm file between runs, and checking the end of
the generated nasm file for errors reported or corrupted output.

Steve

Rod Pemberton

2009-02-17 11:00:09 UTC

Post by s***@yahoo.com
Since space is a primary issue, c5lib has just enough implemented to
self compile NCC.C, alot to be done before fleshing out the io lib,
...
There's stdin, stdout, stderr, a nasm_out, a c_in, an include_in. -
although the include_in is recycled for multiple includes, but one at
a time.

Ok... NCC is using 3 and C requires 3 which is 6 and C5LIB implements only
6. So, you can't open any more files without "stealing" or "blocking" one
of the others...

Post by s***@yahoo.com
I wonder if you could try writing your error messages to stderr, and
at the cmd.exe level redirect console output to a file.

Since I had already worked out where to redirect "output" to the error
file's filepointer, I just removed the fopen() and fclose() for the error
file and set it's filepointer to 2, aka stderr value in C5LIBC. DJGPP has a
utility to redirect stderr to a file, but I haven't tried that yet. It ran
without me seeing an error message. That doesn't mean there isn't one. I'm
just not going to check today.

-
The good news is it looks like it's about to bootstrap. Although, it failed
to flush the last few lines included from C5LIBC from "fdta" on, but
otherwise *seems* complete and accurate. In addition to redirecting the
error info to stderr, I also adjusted the sizes of the larger tables to
match NCC. Most of these settings were substantially smaller than
smc386c.c. I had to reduce some of smc386c's to get under 64k, but they
were nowhere near as small as yours. The macro table was larger in NCC. I
did this because I was still close to the 64k boundary and it complained
about being out of macro space. The good news here is that it compiled with
the much smaller settings! Nice job tweaking! I'll probably boost these
back up once bootstrapped while leaving the larger macro buffer. Some of
the assembly differences were just instruction choice, e.g. cbw vs. movzx,
but two appear to be errors on EV's part. putmem() and getmem() have
brackets for memory references in your code. In GAS, IIRC, these need an
asterisk (?) for these to be memory references. Since I don't see any, I
think he made the mistake... Hopefully, a few more minutes tomorrow or the
day after, and it'll be up and running, likely with some bugs, from your
original NCC.

Rod Pemberton

s***@yahoo.com

2009-02-17 20:14:40 UTC

Ok... NCC is using 3 and C requires 3 which is 6 and C5LIB implements only
6. So, you can't open any more files without "stealing" or "blocking" one
of the others...

Yes, or adding more stream structure to C5LIB...

Post by s***@yahoo.com
I wonder if you could try writing your error messages to stderr, and
at the cmd.exe level redirect console output to a file.

Since I had already worked out where to redirect "output" to the error
file's filepointer, I just removed the fopen() and fclose() for the error
file and set it's filepointer to 2, aka stderr value in C5LIBC. DJGPP has a
utility to redirect stderr to a file, but I haven't tried that yet. It ran
without me seeing an error message. That doesn't mean there isn't one. I'm
just not going to check today.
-
The good news is it looks like it's about to bootstrap. Although, it failed
to flush the last few lines included from C5LIBC from "fdta" on, but
otherwise *seems* complete and accurate. In addition to redirecting the
error info to stderr, I also adjusted the sizes of the larger tables to
match NCC. Most of these settings were substantially smaller than
smc386c.c. I had to reduce some of smc386c's to get under 64k, but they
were nowhere near as small as yours. The macro table was larger in NCC. I
did this because I was still close to the 64k boundary and it complained
about being out of macro space. The good news here is that it compiled with
the much smaller settings! Nice job tweaking! I'll probably boost these
back up once bootstrapped while leaving the larger macro buffer. Some of
the assembly differences were just instruction choice, e.g. cbw vs. movzx,
but two appear to be errors on EV's part. putmem() and getmem() have
brackets for memory references in your code. In GAS, IIRC, these need an
asterisk (?) for these to be memory references. Since I don't see any, I
think he made the mistake... Hopefully, a few more minutes tomorrow or the
day after, and it'll be up and running, likely with some bugs, from your
original NCC.

Last I checked the memory usage for ncc.c to compile itself, there was
14k of space yet left between the end of the statics and the greatest
depth of the stack. The actual amount of stack depth used was less
than 1k, 970d bytes - I thought it would've been much more considering
the recursive descent parser. I ran it in a debugger to find this
out, trapping at exit to check depth of stack.

Steve

Rod Pemberton

2009-02-19 10:58:23 UTC

Post by Rod Pemberton
Although, it failed
to flush the last few lines included from C5LIBC from "fdta" on, but
otherwise *seems* complete and accurate.

This seems to be due to a bug causing an invalid instruction crash on input
of the next filename to process, thereby not flushing. It happens when
compiled with GCC, without C5LIBC, so it's in smc386c.c somewhere. I'll get
back to this, hopefully, soon.

Rod Pemberton

Rod Pemberton

2009-02-19 17:15:31 UTC

Post by Rod Pemberton
Although, it failed
to flush the last few lines included from C5LIBC from "fdta" on, but
otherwise *seems* complete and accurate.

This had something to do with the remaining code I had added to redirect the
errors to a file, and then just set to stderr. But, I'm still seeing an
"invalid instruction" error when smc386c completes, but only the version
compiled by original NCC, not the version compiled by GCC. The good news is
it writes the entire assembly file. But, I'm still not bootstrapped due to
57 NASM "error: short jump out of range". I also noticed the emitted
assembly file has a line of ctrl-Z's at the end, odd... Anyway, getting
closer, slowly.

Rod Pemberton

s***@yahoo.com

2009-02-19 19:27:28 UTC

Post by Rod Pemberton
Although, it failed
to flush the last few lines included from C5LIBC from "fdta" on, but
otherwise *seems* complete and accurate.

This seems to be due to a bug causing an invalid instruction crash on

input

Post by Rod Pemberton
of the next filename to process, thereby not flushing. It happens when
compiled with GCC, without C5LIBC, so it's in smc386c.c somewhere. I'll

get

Post by Rod Pemberton
back to this, hopefully, soon.

"invalid instruction" might check for labels that are instruction
nmemonics...
ex. test(); -iirc.

<ot> btw, I want to bring this Bernanke speech to your attn:
http://www.federalreserve.gov/newsevents/speech/bernanke20090218a.htm

There are a number of insightful gems in there...but this one proves
my prior discussion point:

"
The liability side of the Federal Reserve's balance sheet is
relatively simple, consisting primarily of currency issuance (Federal
Reserve notes) and reserves held by the banking system on deposit with
the Federal Reserve.
"
One should ask himself; in what way is the Fed liable to holders of
currency in circulation. -only in the sense of a future payoff in
statutory dollars.

Steve

Rod Pemberton

2009-02-20 07:34:06 UTC

I'm still not bootstrapped due to 57 NASM "error: short jump out of

range".
Well, I fixed the out of range errors. Simple.

However, I was still having some issues with the multi-stage bootstrap. So,
I decided to start checking the accuracy of the compiled assembly code, in
case errors in the assembly were or are preventing the bootstrap. They are.

Anyway, I chose to try a something I figured should've worked "out of the
box": a "simple" "Hello world!" ("simple" is not so simple because the
compiler is so primitive. Was "out of the box" immense "faith" on my part?
That's a word I don't normally use...) So, I tried the "Hello world!"
program with both NCC and my port smc386c. NCC works. smc386c doesn't.

I compared the assembly for the main program and part of the C5LIBC code for
funtionally equivalent code, I found a few differences that were introduced
by EV that I was unsure of (stack alignments, dword vs. word size changes),
so I backed them out. Although I fixed or modified them in a way I think
should've worked, I haven't gotten the "Hello world!" to work on my port.
Although, it does run without crashing... If I don't find any other issues
when I check the remaining emitted assembly code, I may have to back out
more of his changes until the code is closer to yours or older versions of
Small C to get it to work and then reintroduce the changes since I think
they are useful (or should be if working properly...).

http://www.federalreserve.gov/newsevents/speech/bernanke20090218a.htm

Ok. Maybe I'll read later... I haven't really been strongly interested in
banking in probably decade.

There are a number of insightful gems in there...but this one proves
"
The liability side of the Federal Reserve's balance sheet is
relatively simple, consisting primarily of currency issuance (Federal
Reserve notes) and reserves held by the banking system on deposit with
the Federal Reserve.
"
One should ask himself; in what way is the Fed liable to holders of
currency in circulation. -only in the sense of a future payoff in
statutory dollars.

Well, (could you guess?) I understand his quote, by itself, a bit
differently.

The liability side of the Federal Reserve's balance sheet is
relatively simple, consisting primarily of currency issuance (Federal
Reserve notes) ...

I take "currency issuance" to mean the single entry bookkeeping performed
when they create and destroy money. I.e., they have a bookkeeping entry
where they created money (either electronically or by printing more money)
at the present date and are required to record a bookkeeping entry in the
future to extinquish money (either electronically or by burning it). The
period the money is in existence, between issuance and destruction, is their
liability since it's not their money. It's their authority to create and
destroy money. And, since it's not their money but they're authorized to
create it and loan it out, they have to get that money back in an orderly
manner, with interest, and with full principle prior to it's destruction.

The liability side of the Federal Reserve's balance sheet is
relatively simple, ...
reserves held by the banking system on deposit with
the Federal Reserve.

I take "reserves held" to mean the "gold bullion" held at Fort Knox, and
other depository banks, e.g., Fed. Res. NY, on behalf of the American
government, and indirectly the "confiscated" wealth, i.e., "forced exchange"
for dollars, of a generation of American people. They hold this physical
wealth on behalf of the government. It's not theirs to do with as they
please. They are a fiduciary for the wealth they hold. That's their
liability.

Rod Pemberton

Rod Pemberton

2009-02-22 11:01:16 UTC

[SmallC]

Anyway, I chose to try a something I figured should've worked "out of the
box": a "simple" "Hello world!" ("simple" is not so simple because the
compiler is so primitive. Was "out of the box" immense "faith" on my part?
That's a word I don't normally use...) So, I tried the "Hello world!"
program with both NCC and my port smc386c. NCC works. smc386c doesn't.

I'm not too sure now that EV's version of SmallC for Linux actually worked
or works. I'm getting the impression it was "in progress," with a ways to
go. It seems he also eliminated code to adjust the stack, assuming the
prolog and epilog code he added would correct things. I think he's also
reversed the stack argument passing order, but didn't correct the function's
stack usage order. NCC uses a left-to-right argument order. EV's uses a
right-to-left. EV's is more inline with C practice. Maybe I missed
something, but the compiled functions for EV's seem to access the arguments
in the exact same order as NCC. Sigh... Anyway, I'm going to keep working
the code toward what yours generates, and hopefully I will get it to work.
Then, I can figure out what he did and whether it's needed or useful.

Rod Pemberton

Rod Pemberton

2009-02-22 12:12:22 UTC

[SmallC]

part?

Post by Rod Pemberton
That's a word I don't normally use...) So, I tried the "Hello world!"
program with both NCC and my port smc386c. NCC works. smc386c doesn't.

WooHoo! Got me a "Hello World!"... Yes, it seems he didn't match up the
arg order. Apparently, he was using getlitstk() and dumpltstk() to reverse
some or all of the arguments. Anyway, more attempts at bootstrapping left
for another day.

Later,

RP

s***@yahoo.com

2009-02-22 16:34:44 UTC

[SmallC]

Anyway, I chose to try a something I figured should've worked "out of

the

Post by Rod Pemberton
box": a "simple" "Hello world!" ("simple" is not so simple because the
compiler is so primitive. Was "out of the box" immense "faith" on my

part?

Post by Rod Pemberton
That's a word I don't normally use...) So, I tried the "Hello world!"
program with both NCC and my port smc386c. NCC works. smc386c doesn't.

function's

Post by Rod Pemberton
stack usage order. NCC uses a left-to-right argument order. EV's uses a
right-to-left. EV's is more inline with C practice. Maybe I missed
something, but the compiled functions for EV's seem to access the

arguments

Post by Rod Pemberton
in the exact same order as NCC. Sigh... Anyway, I'm going to keep

working

Post by Rod Pemberton
the code toward what yours generates, and hopefully I will get it to work.
Then, I can figure out what he did and whether it's needed or useful.

Good deal!

When you turn your attention to the preprocessor, you might want to
take a look at:

http://kernel.org/pub/linux/kernel/people/josh/sparse/dist/sparse-0.2.tar.gz

There are some preprocessor tests in there.. the couple I've tried
sends small-c into the weeds.
/*
* This one we happen to get right.
*
* It should result in a simple
*
* a + b
*
* for a proper preprocessor.
*/
#define TWO a, b

#define UNARY(x) BINARY(x)
#define BINARY(x, y) x + y

UNARY(TWO)

I'll have to get around to doing an errata list, as the items needing
attention is growing. The parser goes down evaluating certain
constructs; *(px++); --that it doesn't recover from an internal error
(a construct it can't yet handle) is a big issue.

Steve

Rod Pemberton

2009-02-23 09:15:23 UTC

WooHoo! Got me a "Hello World!"... Yes, it seems he didn't match up the
arg order. Apparently, he was using getlitstk() and dumpltstk() to

reverse

some or all of the arguments. Anyway, more attempts at bootstrapping

left

for another day.

Good deal!

Well, I tried a bootstrap. It's a no go. (expected) So, there are some
other code generation problems.

In the mean time, I was "working"... ok, playing with compiling the "Hello
World!" app. I attempted to add EV's (or my variatons of) prolog and epilog
code back in. I was hoping for a code reduction since it eliminated one
frequently used instruction. But, what a mess... Have to convert
everything to be relative to bp not sp, keeping bp synched with changes to
sp (hmm, problem?...), push and pops needs to add code to update bp
(undesired...), and, well, something still isn't correct. I might play with
this a bit more, and then if I don't stumble upon progress, either back it
out, or save the changes for later when I can look at it more thoroughly.
This is a bit reminiscent of other changes I previously tried to make to
SmallC. It's not always so easy to modify is it?

Post by s***@yahoo.com
When you turn your attention to the preprocessor,

I thought I'd notice much more missing from the preprocessor, but so far I
haven't. The two things I've noticed the most are the "" or <> quotes on
include files and the following, which I use frequently:

#if 0
/* code to exclude */
#endif

#if 1
/* code to include */
#endif

#if #else #endif sequence and #ifdef #endif sequence would be nice too. I
don't frequently use, although I do use them, the preprocessor "defined()"
or many other preprocessor features.

Post by s***@yahoo.com
you might want to

http://kernel.org/pub/linux/kernel/people/josh/sparse/dist/sparse-0.2.tar.gz
Thanks for that. I didn't have that one. I've actually been collecting C
compiler tests for some time. I was planning to use them way into the
future if a C compiler by me (or one improved by me) ever becomes that
advanced. Or, maybe just to test a C library someday. I've got 41 or so
packages and 13 or so C "snippets" from the 'net that test various things.
I also have some small C and preprocessor tests I either copied out of the
spec.'s or constructed for an older abandoned bison/flex based C compiler
with which I attempted to integrate the preprocessor...

Post by s***@yahoo.com
There are some preprocessor tests in there.. the couple I've tried
sends small-c into the weeds.

As for the preprocessor, I'm not sure what you think or feel about it, but
from my experience with the bison/flex based C compiler, I think it is much
easier to implement it as a separate application from the C compiler. IMO,
this is because the preprocessor needs to parse various size text pieces
including very small ones and much of the C language needs to be done as
largest pieces first. This creates a conflict in the way text is parsed.
Anyway, there are a number of abandoned preprocessor packages that might be
worth a look. I have 3 versions of the DECUS C pp, one called the
"selective" C pp, and another called "der Mouse". I haven't checked in a
while as to their copyright and license status but the preprocessors are all
in my collection of Public Domain code, so they're probably PD or mostly so.
I looks like I also have one called JSCPP which is GPL'd.

There's also one called UCPP (dead link) that you can enter into the Wayback
archive, but I wasn't able to get the files from them. Sometimes, you have
to try a few times or different dated pages:

enter http://pornin.nerim.net/ucpp/ into the search box at
http://www.archive.org/web/web.php

Or, you can search for "ucpp-1.3.tar.gz" or other files listed on their
archive of his pages.

If you'd like me to .zip etc. up either the tests or the preprocessors and
put the file(s) up on say Rapidshare where you can download them. Just say
so.

Rod Pemberton

s***@yahoo.com

2009-02-23 23:48:21 UTC

WooHoo! Got me a "Hello World!"... Yes, it seems he didn't match up the
arg order. Apparently, he was using getlitstk() and dumpltstk() to

reverse

some or all of the arguments. Anyway, more attempts at bootstrapping

left

for another day.

Good deal!

Well, I tried a bootstrap. It's a no go. (expected) So, there are some
other code generation problems.

:-/

Post by Rod Pemberton
In the mean time, I was "working"... ok, playing with compiling the "Hello
World!" app. I attempted to add EV's (or my variatons of) prolog and epilog
code back in. I was hoping for a code reduction since it eliminated one
frequently used instruction. But, what a mess... Have to convert
everything to be relative to bp not sp, keeping bp synched with changes to
sp (hmm, problem?...), push and pops needs to add code to update bp
(undesired...), and, well, something still isn't correct. I might play with

nccr1 does the [bp] route for example, with the restriction that .data
holds the stack as well... there's still an issue in the parse of
passing a pointer to a function on the stack I have to look into, it
seems.

Post by Rod Pemberton
this a bit more, and then if I don't stumble upon progress, either back it
out, or save the changes for later when I can look at it more thoroughly.
This is a bit reminiscent of other changes I previously tried to make to
SmallC. It's not always so easy to modify is it?

No it isn't easy, I would have thought it would be much easier with a
block structured language, to make any changes without such side
effects. But even block structured code can be written to obscure
program flow.

Post by s***@yahoo.com
When you turn your attention to the preprocessor,

I pulled; preprocess(); out of the source to test it as a stand alone
preprocessor. This shows what functions it depends on, the common
functions needed. etc. -And took all those and made a test app out of
the to read directive statements, build the symbol table, the added
code to dump the table. addmac() filters leading whitespace, but not
trailing whitespace. Adding code to filter trailing whitespace saves
about 16% of macro pool space of the ncc directives. That works fine
for the directive expressions to compact macro table space.

Post by Rod Pemberton
I thought I'd notice much more missing from the preprocessor, but so far I
haven't. The two things I've noticed the most are the "" or <> quotes on
#if 0
/* code to exclude */
#endif
#if 1
/* code to include */
#endif
#if #else #endif sequence and #ifdef #endif sequence would be nice too. I
don't frequently use, although I do use them, the preprocessor "defined()"
or many other preprocessor features.

Post by s***@yahoo.com
you might want to

http://kernel.org/pub/linux/kernel/people/josh/sparse/dist/sparse-0.2...
Thanks for that. I didn't have that one. I've actually been collecting C
compiler tests for some time. I was planning to use them way into the
future if a C compiler by me (or one improved by me) ever becomes that
advanced. Or, maybe just to test a C library someday. I've got 41 or so
packages and 13 or so C "snippets" from the 'net that test various things.
I also have some small C and preprocessor tests I either copied out of the
spec.'s or constructed for an older abandoned bison/flex based C compiler
with which I attempted to integrate the preprocessor...

Post by s***@yahoo.com
There are some preprocessor tests in there.. the couple I've tried
sends small-c into the weeds.

Well, multiple passes, or separate program, just makes sense. However
smallc is a different beast, as a bootstrap of C to a new (os) target,
its paradigm is single pass. I rather bring new features up from
within it, it has to be able to build itself as a key concept of its
paradigm. At the least, compiler version 'waypoints' should be kept
to keep the lineage and traceability intact. This paradigm, to my
mind, _is_ small-c.

For another project, or fork of smallc, anything goes of course. I
don't have alot of confidence in small-c's parser, for what it does it
is just ok. What it doesn't do I can't quantify, that's bothersome.
What its recursive descent parser seems to do is evaluate an
expression; {operand, operator, operand}. But it needs to handle
{prefix operator, operand, postfix operator} as well; i.e. *(x++);
with all the precedence and L<->R bindings per the lang.
specification. I don't know of/ don't have/ a test to test these.
Alexei mentioned Lisp. I think S-Expressions of patterns of C syntax
is an idea worth exploring for validating the parser..

Post by Rod Pemberton
Anyway, there are a number of abandoned preprocessor packages that might be
worth a look. I have 3 versions of the DECUS C pp, one called the
"selective" C pp, and another called "der Mouse". I haven't checked in a
while as to their copyright and license status but the preprocessors are all
in my collection of Public Domain code, so they're probably PD or mostly so.
I looks like I also have one called JSCPP which is GPL'd.
There's also one called UCPP (dead link) that you can enter into the Wayback
archive, but I wasn't able to get the files from them. Sometimes, you have
enterhttp://pornin.nerim.net/ucpp/ into the search box athttp://www.archive.org/web/web.php
Or, you can search for "ucpp-1.3.tar.gz" or other files listed on their
archive of his pages.
If you'd like me to .zip etc. up either the tests or the preprocessors and
put the file(s) up on say Rapidshare where you can download them. Just say
so.

Thanks for the offer, I'll let you know if I decide to do that, but my
leading candidate is a project out of 'functional programming'..

http://www.ross.net/funnelweb/

.if. I were to tackle it.

Steve

Post by Rod Pemberton
Rod Pemberton

Rod Pemberton

2009-02-24 10:17:26 UTC

Post by s***@yahoo.com
When you turn your attention to the preprocessor,

Cool. It'd be nice as a separate app.

Also, given you'd rather not have the preprocessor as a separate app, this
suggests you might put your space fix back into Small C..., yes? :)

Post by s***@yahoo.com
Well, multiple passes, or separate program, just makes sense. However
smallc is a different beast, as a bootstrap of C to a new (os) target,
its paradigm is single pass. I rather bring new features up from
within it, it has to be able to build itself as a key concept of its
paradigm. At the least, compiler version 'waypoints' should be kept
to keep the lineage and traceability intact. This paradigm, to my
mind, _is_ small-c.

There's nothing wrong with that. A few tweaks here, a few more there, and
the next thing you know it's far more functional than you ever thought
possible... It'd be good to take Small C's preprocessor as far as it can go
internally. I'm just not sure due to my experiences that a full C compiler
and a full C preprocessor can co-exist. Maybe they can.

Post by s***@yahoo.com
What it doesn't do I can't quantify, that's bothersome.

Yeah, I haven't thoroughly read the code. By just looking at it, it's not
so easy to tell what some of the code is doing. Other than the low level
routines to emit assembly, I really haven't looked at it much. EV seemed to
have mucked some stuff up. That reminds me. I could've sworn I worked on
another version of Small C... What does "heir" mean here anyway? I'm not a
fan of recursion except when blatantly obvious, which it seems these parser
routines are using. Well, that's one way to allocate more memory without
malloc(), alloca(), or knowing the size needed for local variables... New
stackframe anyone?

Post by s***@yahoo.com
What its recursive descent parser seems to do

Well, I'm not sure exactly what a "recursive descent parser" (RDP) is
supposed to do... Well, I could go to Wikipedia I guess, maybe later... I
can guess from the name that it's 1) a parser, 2) it is "descending"
something, like a binary tree or more likely a defined grammar in a tree
like manner and 3) it's likely using recursion or some repetitive method due
to use of "recursive". I think I have a solid understanding of what LALR(1)
is supposed to do. Except for the bison/flex ones, my parsers aren't
LALR(1), AFAIK...

Post by s***@yahoo.com
What its recursive descent parser seems to do is evaluate an
expression; {operand, operator, operand}.

I'd say that fits two register operations in reversed order...: store,
action, load. It probably works well with early load-store cpu's like what
Small C was written for.

Post by s***@yahoo.com
But it needs to handle
{prefix operator, operand, postfix operator} as well; i.e. *(x++);

Let's take the *(x++). Are the parenthesis yours to indicate the preferred
order in this case, i.e., {prefix operator, operand, postfix operator}, or
are the parenthesis part of the C code? I.e., of the following, what do you
understand *(x++) to mean?

a) due to the post-increment being delayed until afterwards, the parenthesis
are ignored and so x is dereferenced first, then x is incremented afterwards
b) due to ++ having higher precedence than * as indirection, x is
incremented first and afterwards x is dereferenced
c) due to ++ having higher precedence than * as indirection but ++ being a
post-increment, x is dereferenced first then x is incremented
d) even though ++ is post-increment and should be incremented afterwards,
due to the parenthesis the associativity and precedence are nullified and x
is incremented first and afterwards x is dereferenced
e) due to the parenthesis the associativity and precedence are nullified,
but due to ++ being a post-increment x is effectively dereferenced first
then x is incremented
f) this is a partial statement, and * represent multiplication instead of
indirection
g) this is a partial statement, and () somehow represents a function call or
cast...

My point being: How does Small C handle parenthesis within statements using
{operand, operator, operand}? Isn't there a parenthesis rule? In ANSI C
(which doesn't really apply to Small C), parenthesis have highest priority
except as function calls and casts. And, it's possible the operations of
post-inc/decrement may be delayed until after the rest of the line of code
is processed... I usually expect post ++ to be effected completely after
the line of C code much like early C, perhaps like K&R C, but for ANSI C the
parenthesis might make it occur first.

My expectation (which may not match any C standard...) is "a)", i.e., that
the post-increment is essentially an extra separate statement as in: *x;
x++; which comes afterwards because it's a post-increment. My expectation
is the "pre" and "post" accurately represent when the operations are
effected. Of course, we're talking about Small C which predates ANSI C, so
I'm not too clear on what should be done... Without other code to indicate
what to be done, I'd rewrite it as *x; x++; given my expectation that the
post-increment operator occurs afterwards. Of course, it might actually be
x++; *x; since parens (in ANSI C) usually have precedence over other
operators and operations...

What about *(++x)?... {prefix operator, prefix operator, operand} or
recursion of {prefix operator, operand}...?

The pre/post-inc/decrements, can be "unrolled" into separate additional
statements of plus/minus one. Of course, you still need to determine the
effect of parens on evaluation order. The "unary" operators (which are also
placed in front or prefixed but aren't called "prefix" operators according
to H&S ANSI C...) probably requires adding the form {unary operator,
operand}.

Post by s***@yahoo.com
But it needs to handle
{prefix operator, operand, postfix operator} as well; i.e. *(x++);
with all the precedence and L<->R bindings per the lang.
specification. I don't know of/ don't have/ a test to test these.

Hmm... Well, I started to say I'd look for one. But, if I found one,
they'd likely be for ANSI C, or ISO C99, not K&R C or earlier.

Post by s***@yahoo.com
Alexei mentioned Lisp. I think S-Expressions of patterns of C syntax
is an idea worth exploring for validating the parser..

I'm not sure where the precedences and associativities are in the spec. I
usually use extra parens if I suspect an issue. You could refer to H&S 3rd.
(ANSI C) table 7-1 (which has one error...) which tells both precedence and
associativity. Of course, you probably want K&R C or earlier...

Rod Pemberton

s***@yahoo.com

2009-02-25 14:54:00 UTC

Post by s***@yahoo.com
When you turn your attention to the preprocessor,

Cool. It'd be nice as a separate app.
Also, given you'd rather not have the preprocessor as a separate app, this
suggests you might put your space fix back into Small C..., yes? :)

Yes, I'll put in errata, but here it is now, no big deal..

**--------------------------------------------**/
/** matches "#define" **/

addmac()
{
char sname[namesize], chr; int k;

if (symbform(sname)==0)
{
illname();
kill_ln();
return;
}
k = 0;
/** name to match and replace **/
while (putmac(sname[k++]));
/** rest; macro replacement **/
/** filter leading whitespace **/
while (ck_chr()==' ' | ck_chr()==9) gchr();
/** replacement string **/
/** while (putmac(gchr())); chg, filter trailing whitesp **/
while (chr = gchr())
{ /** filter out trailing sps, tabs **/
if (chr == ' ') continue;
if (chr == 9) continue;
putmac(chr);
}
putmac(0); /** append null termination **/
if (macptr >= macmax) error("macro table full");
}

Yeah, well the proof is in the pudding..

Post by s***@yahoo.com
What it doesn't do I can't quantify, that's bothersome.

It's a misstyping of the word: hierarchy.. each 'heir' is a precedence
level of the operators smallc supports. Somewhat follows the K&R
table in 2.12, each heir_n calls the next higher heir_n before
handling its own level. recursive descent. Together, they are the
heart of the parser, and the syntatic actions to produce the backend
output. It seems to recurse twice; once for the left operand, once
for the right operand (there are two results arrays, one for each
operand).

fan of recursion except when blatantly obvious, which it seems these parser
routines are using. Well, that's one way to allocate more memory without
malloc(), alloca(), or knowing the size needed for local variables... New
stackframe anyone?

Yes, a stack frame is a generic malloc in a way..

Post by s***@yahoo.com
What its recursive descent parser seems to do

Post by s***@yahoo.com
What its recursive descent parser seems to do is evaluate an
expression; {operand, operator, operand}.

I'd say that fits two register operations in reversed order...: store,
action, load. It probably works well with early load-store cpu's like what
Small C was written for.

Post by s***@yahoo.com
But it needs to handle
{prefix operator, operand, postfix operator} as well; i.e. *(x++);

It is the default evaluation, right to left of uniary operators, ==> *x
++, meaning incrementing x, not what x point to. Addressed in K&R
5.1. It is an expression until terminated with ';' wherewith it
becomes a statement. (*x)++, here the parenthesis is required to
indicate the increment of what x points to.

a) due to the post-increment being delayed until afterwards, the parenthesis
are ignored and so x is dereferenced first, then x is incremented afterwards
b) due to ++ having higher precedence than * as indirection, x is
incremented first and afterwards x is dereferenced
c) due to ++ having higher precedence than * as indirection but ++ being a
post-increment, x is dereferenced first then x is incremented
d) even though ++ is post-increment and should be incremented afterwards,
due to the parenthesis the associativity and precedence are nullified and x
is incremented first and afterwards x is dereferenced
e) due to the parenthesis the associativity and precedence are nullified,
but due to ++ being a post-increment x is effectively dereferenced first
then x is incremented
f) this is a partial statement, and * represent multiplication instead of
indirection
g) this is a partial statement, and () somehow represents a function call or
cast...

Gee, 7 notions for the notation! N(asm) rules!!

My point being: How does Small C handle parenthesis within statements using
{operand, operator, operand}? Isn't there a parenthesis rule? In ANSI C
(which doesn't really apply to Small C), parenthesis have highest priority
except as function calls and casts. And, it's possible the operations of
post-inc/decrement may be delayed until after the rest of the line of code
is processed... I usually expect post ++ to be effected completely after
the line of C code much like early C, perhaps like K&R C, but for ANSI C the
parenthesis might make it occur first.

I don't have my notes handy, but iirc the expression breaks
smallc...like I said, what it (the parser) doesn't do I can't
quantify, that's bothersome. (not without heavy exhaustive
testing..the parser is non-obvious to my eyes.)

Steve

My expectation (which may not match any C standard...) is "a)", i.e., that
the post-increment is essentially an extra separate statement as in: *x;
x++; which comes afterwards because it's a post-increment. My expectation
is the "pre" and "post" accurately represent when the operations are
effected. Of course, we're talking about Small C which predates ANSI C, so
I'm not too clear on what should be done... Without other code to indicate
what to be done, I'd rewrite it as *x; x++; given my expectation that the
post-increment operator occurs afterwards. Of course, it might actually be
x++; *x; since parens (in ANSI C) usually have precedence over other
operators and operations...
What about *(++x)?... {prefix operator, prefix operator, operand} or
recursion of {prefix operator, operand}...?
The pre/post-inc/decrements, can be "unrolled" into separate additional
statements of plus/minus one. Of course, you still need to determine the
effect of parens on evaluation order. The "unary" operators (which are also
placed in front or prefixed but aren't called "prefix" operators according
to H&S ANSI C...) probably requires adding the form {unary operator,
operand}.

Hmm... Well, I started to say I'd look for one. But, if I found one,
they'd likely be for ANSI C, or ISO C99, not K&R C or earlier.

Post by s***@yahoo.com
Alexei mentioned Lisp. I think S-Expressions of patterns of C syntax
is an idea worth exploring for validating the parser..

Rod Pemberton

2009-02-26 08:32:42 UTC

... each 'heir' is a precedence
level of the operators smallc supports. Somewhat follows the K&R
table in 2.12, each heir_n calls the next higher heir_n before
handling its own level. recursive descent. Together, they are the
heart of the parser, and the syntatic actions to produce the backend
output. It seems to recurse twice; once for the left operand, once
for the right operand (there are two results arrays, one for each
operand).
...
I don't have my notes handy, but iirc the expression breaks
smallc...like I said, what it (the parser) doesn't do I can't
quantify, that's bothersome. (not without heavy exhaustive
testing..the parser is non-obvious to my eyes.)

Well, I know you don't need direction, but all I can do at this point in
time is state what I would try to do. I wouldn't add the indirection
operator, address-of operator, or any other prefix or unary operators
immediately. I'd add postfix operators...

First, I'd attempt to add other postifx operators into the existing heirXX
routines. My choice would be something such as logical-and && and
logical-or ||. I'd start by "cutting and pasting" the bitwise-and & and
bitwise-or |. Since Small C uses bitwise-and and bitwise-or as logical-and
and logical-or, I could "cut-n-paste" all other related code all the way to
the low-level code. Then, when time permitted, I could rework the bitwise
and logical operations so they work properly.

Second, now that I know all the steps of inserting a new recursive descent
level into the hierarchy, I'd add a few more *postfix* operator hierarchies.
These would be "dummy" operators that uses some character or combination
that isn't used by C or at least Small C. I'd then implement the remaining
necessary code down to the low-level code. I'd then implement low-level
code for the "dummy" operators with functionality for something I wanted
such as prefix or unary operators like the indirection operator or
address-of operator. Once I know that the "dummy" postfix indirection
operator or address-of operator worked properly, then I'd go about trying to
modify the parser syntax from the "dummy" postfix syntax to correct C prefix
syntax. E.g., I'd need to rewrite *x++; as postfixed with some "dummy"
operator I created and test that repeatedly until it works. I.e., if the
"dummy" indirection operator is tilde-tilde ~~ , then *x++ becomes x++; x~~;
. Once it works, then I'd attempt to convert that specific heirXX to
indirection * as prefix.

Rod Pemberton

s***@yahoo.com

2009-02-28 19:12:14 UTC

Well, I know you don't need direction, but all I can do at this point in
time is state what I would try to do. I wouldn't add the indirection
operator, address-of operator, or any other prefix or unary operators
immediately. I'd add postfix operators...
First, I'd attempt to add other postifx operators into the existing heirXX
routines. My choice would be something such as logical-and && and
logical-or ||. I'd start by "cutting and pasting" the bitwise-and & and
bitwise-or |. Since Small C uses bitwise-and and bitwise-or as logical-and
and logical-or, I could "cut-n-paste" all other related code all the way to
the low-level code. Then, when time permitted, I could rework the bitwise
and logical operations so they work properly.
Second, now that I know all the steps of inserting a new recursive descent
level into the hierarchy, I'd add a few more *postfix* operator hierarchies.
These would be "dummy" operators that uses some character or combination
that isn't used by C or at least Small C. I'd then implement the remaining
necessary code down to the low-level code. I'd then implement low-level
code for the "dummy" operators with functionality for something I wanted
such as prefix or unary operators like the indirection operator or
address-of operator. Once I know that the "dummy" postfix indirection
operator or address-of operator worked properly, then I'd go about trying to
modify the parser syntax from the "dummy" postfix syntax to correct C prefix
syntax. E.g., I'd need to rewrite *x++; as postfixed with some "dummy"
operator I created and test that repeatedly until it works. I.e., if the
"dummy" indirection operator is tilde-tilde ~~ , then *x++ becomes x++; x~~;
. Once it works, then I'd attempt to convert that specific heirXX to
indirection * as prefix.
Rod Pemberton

Yes, something like that... I've been digging thru my reference
library and found the 2nd Ed. of 'A Book on C' by Al Kelly and Ira
Pohl. covering ANSI C. Appendix B covers the BNF for the C Language
Syntax, and Appendix C covers the Differences: ANSI C Compared to
Traditional C
(major changes, not exhaustive). Both have a subsection on the
Preprocessor as well. These, in BNF, echo somewhat the Appendix A,
Section 18 Syntax Summary of K&R 'The C Programming Language'. -fyi.

Steve

Rod Pemberton

2009-03-01 07:24:09 UTC

Post by s***@yahoo.com
Yes, something like that...

If you could have only one of the two, what is most important: functionality
or syntax? :)

Post by s***@yahoo.com
[BNF grammars from various books]

I'm sure the authors intended for people who bought the books to use the
grammars. And, I don't want to stir up copyright arguments again. But, if
they didn't explicity say the book purchaser has usage rights so somewhere,
I think copyrights might be an issue preventing copying, usage,
preservation, distribution, etc. of said grammars. There are situations
where parts of a copyrighted work aren't protected by copyright law. "Fair
use" is one. Also, portions of copyrighted "standards" which must be used
for an implementation to comply with the "standard" aren't protected by USA
copyright law. As I see it, this would be things like grammars, headers,
includes, code, definitions, etc. in regards to a programming "standards"
like those for C, but only the parts that are necessary to implement the
standard. But, I don't believe these books would qualify as a "standard" or
"fair use" or one of the various and numerous other USA copyright
exceptions.

Rod Pemberton

s***@yahoo.com

2009-03-01 23:01:32 UTC

Post by s***@yahoo.com
Yes, something like that...

If you could have only one of the two, what is most important: functionality
or syntax? :)

Now there's a rabbit hole, Alice!

I'm inclined to say the later, syntax. You can build functionality if
the syntax is on your side.

Post by s***@yahoo.com
[BNF grammars from various books]

So, assuming your premise.. If I checkout such a book from the
library, and run the BNF thru lex to see if something useful comes out
the other side, I am ...?

Do you allow me the alpha-numerics to be in the common domain or need
I pay tribute to some caliph or ANSI?

Steve

Post by Rod Pemberton
Rod Pemberton

Rod Pemberton

2009-03-02 01:07:35 UTC

Post by s***@yahoo.com
So, assuming your premise.. If I checkout such a book from the
library, and run the BNF thru lex to see if something useful comes out
the other side, I am ...?

Well, as I said it might fall under "fair use" since it was likely intended
by the author to be used by those who own the book either individually or
collectively (e.g., library)... But, I see the lexer's grammar specific
output as a derivative of the original grammar which is copyrighted. IMO
(consult your attorney...), the lexer's emitted output comprises two parts:
1) "stuff" generated from the grammar 2) "stuff" generated by the lexer that
is specific to the lexer and not the grammar, e.g., interface code. "Stuff"
generated from the grammar falls under the grammar's copyright. "Stuff"
generated by the lexer that is specific to it falls under the lexer's
copyright. Anyway, that's where I believe the divisions lay.

Post by s***@yahoo.com
Do you allow me the alpha-numerics to be in the common domain or need
I pay tribute to some caliph or ANSI?

Alpha-numerics predate copyright law. (Wikipedia indicates 500's for
numerics & 1500's for English vs. 1700's for copyright law). And, ASCII and
Unicode are standards documents. (I.e., you can use what's required to
comply without infringement for the US.) Now, TTF's are somebody's design,
likely copyrighted.

Rod Pemberton

Robert Redelmeier

2009-03-02 03:56:44 UTC

Post by Rod Pemberton
Well, as I said it might fall under "fair use" since it was
likely intended by the author to be used by those who own the
book either individually or collectively (e.g., library)...
But, I see the lexer's grammar specific output as a derivative
of the original grammar which is copyrighted.

I think you are confusing copyright with patents. You can
copyright a book or program, but not "similar" non-derivative
books or pgms. For that kind of protection, you need a patent.

Copyright merely prohibits the making of copies and derivative
works, not any other use. Of course, you could properly
licence the thing and permit or forbid just about anything
by contract. One of the reasons publishers try to make
shrink-wrap and click-wrap "agreements" recognized as valid.
The legislative attempt (UCITA) flopped.

You can certainly copyright a compiler but not a language.
In jurisdictions that allow software patents, you might be able
to patent a language. Or maybe not, because most patent laws do
not allow you to patent an idea, only the specific expressions
of it. A computer language is an idea about expressing ideas,
quite possibly too far removed for valid patent protection.

Post by Rod Pemberton
IMO (consult your attorney...), the lexer's emitted output

Always good advice.

Post by Rod Pemberton
Alpha-numerics predate copyright law. (Wikipedia indicates
500's for numerics & 1500's for English vs. 1700's for
copyright law).

In any case, the protection would be via patents, which have
shorter terms (17-20yr).

Post by Rod Pemberton
And, ASCII and Unicode are standards documents. (I.e.,
you can use what's required to comply without infringement
for the US.)

Sorry, the "necessity" defense does not fly. The US Supremes
let stand a ruling that RAMBUS could enforce its' submarine
patents against JEDEC RAM.

-- Robert

Rod Pemberton

2009-03-02 19:21:53 UTC

Post by Robert Redelmeier

I think you are confusing copyright with patents.

I'm quite sure that isn't the case...

Post by Robert Redelmeier
You can
copyright a book or program,

Yes.

Post by Robert Redelmeier
You can
copyright a book or program, but not "similar" non-derivative
books or pgms.

No. Highly "similar" non-derivative works are copyrightable. (case listed
below) Highly "similar" non-derivative works aren't copyrightable when
there are other valid expressions available. E.g., for low-level software
routines with limited expression and high similarity, these are
copyrightable. But, for a work of fiction where an infinite range of
expression is available, a highly similar work would likely be an
infringement.

Post by Robert Redelmeier
You can
copyright a book or program, but not "similar" non-derivative
books or pgms.

You can't copyright "similar" derivative works. (cases listed below) A
derivative work contains "original expression" of the author.

Post by Robert Redelmeier
For that kind of protection, you need a patent.

In general, patent's protect processes, while copyrights protect expression
of ideas. Still don't know why you think I mixed the two up...

Post by Robert Redelmeier
Copyright merely prohibits the making of copies and derivative
works, not any other use.

What did I just say above in the last sentence of mine that you accurately
quoted, if not exactly this?...

The transformation of a grammar in a copyrighted book into code is, IMO, a
derivative work, but might be allowed under "fair use" for private personal
use. But, I think copyrights are preserved, so I wouldn't post or
distribute anything publicly.

BTW, did you not see where Amazon got into trouble for creating "derivative"
works by implementing text-to-speech in Kindle? I.e, the copyright holder
of text also holds the copyright to audio, a derivative work.

Post by Robert Redelmeier

Post by Rod Pemberton
And, ASCII and Unicode are standards documents. (I.e.,
you can use what's required to comply without infringement
for the US.)

Sorry, the "necessity" defense does not fly. The US Supremes
let stand a ruling that RAMBUS could enforce its' submarine
patents against JEDEC RAM.

Ok, you just used a patent decision to say the various US court rulings on
copyright usage of standards documents is invalid?... (cases listed below)
Is what you meant to say?

Earlier, you stated that you thought I was confusing copyrights and patents.
I think you failed to separate a patentable process from copyrighted work.
E.g., Amazon's text-to-speech process might be patented by their software
supplier, but the resulting computer generated speech is a derivative work.
This is no different from a lexer operating on a grammar. The lexer's code
both internal and emitted may be copyrighted. The lexer's process might be
patented. But, the transformation on the input grammar is a derivative
work which would be covered by the grammar's copyright.

FYI, related cases or law:

0) Only the owner of a copyright has the right to prepare derivative works
based upon the copyrighted work:
section 106 b. of Copyright Act
1) trivially "similar" derivative works aren't copyrightable:
Nichols v. Universal Pictures Corp
Sheldon v. Metro-Goldwyn Pictures Corp
Steinberg v. Columbia Pictures
Durham Industries, Inc. v. Tomy Corp.
US Copyright Registration for Derivative Works (Circular 14)
2) trivial changes to Public Domain works aren't copyrightable:
Walker & Zanger, Inc. v. Paragon Indus
3) a derivative work with major changes that doesn't qualify as a unique
work can't be copyrighted as a whole, but the changes can be copyrighted:
Durham Industries vs. Tomy Corp
Section 103 of Copyright Act (17 USC)
3) Substantial similiarity required for infringement:
Computer Associates v. Altai
4) Portions of a technical standards document which are required to be used
to comply with the standard aren't copyrightable:
Feist Publications, Inc. v. Rural Tel. Serv. Co
Computer Associates v. Altai
Baystate v. Bentley
Section 102 b of Copyright Act
"Scènes à faire doctrine"
5) A derivative work must be sufficiently different to prevent copyright
entanglement:
Gracen v. Bradford Exchange
6) Substantially similar works are copyrightable when expression is limited:
NEC Corp. v Intel Corp.
7) Facts are not copyrightable:
Feist Publications, Inc. v. Rural Tel. Svc.
8) Copyright does not protect process, or reexpression of ideas is
copyrightable, or ideas are not protected by copyright:
Baker v. Selden
9) Originality and independent creation required for copyright:
Feist Publications, Inc. v. Rural Tel. Svc.
10) Private documents required to implement public law are public:
Veeck v. Southern Building Code Congress International, Inc.
11) Works written by the U.S. government are not copyrightable (Public
Domain):
section 105 of Copyright Act
12) Copying Public Domain material from a copyrighted work is a
constitutional right:
Feist Publications, Inc. v. Rural Tel. Serv. Co
Section 107 6 of Copyright Act
13) Created right of "fair use":
Folsom v. Marsh
14) Personal use constitutes "fair use":
Sony Corp. v. Universal City Studios
15) Defeating "fair use" requires proof harmful or if widespread would hurt
market potential of copyrighted work:
Sony Corp. v. Universal City Studios
16) Reverse engineering is "fair use" sometimes:
Sony v. Connectix
Sega v. Accolade
17) Object code isn't copyrightable:
Apple Computer v. Franklin Computer
18) Individuals have the right to modify code for their own use:
Lewis Galoob Toys v. Nintendo of America
19) Technical interfaces, e.g., data structure names, data structure
organization or ordering, menu's, etc. aren't copyrightable:
Baystate v. Bentley
Mitel Inc. v. Iqtel
Sega Enterprises Ltd. v. Accolade
Lotus v. Borland
Apple Computer v. Microsoft
Synercom v. University Computing
20) System interfaces, e.g., ability to execute an application, aren't
copyrightable:
Bateman v. Mnemonics
21) Copyright is to serve the public interest:
Fogerty v. Fantasy, Inc
Feist Publications, Inc. v. Rural Tel. Serv. Co

Rod Pemberton

Robert Redelmeier

2009-03-03 04:32:28 UTC

Post by Rod Pemberton
BTW, did you not see where Amazon got into trouble for creating
"derivative" works by implementing text-to-speech in Kindle?
I.e, the copyright holder of text also holds the copyright to
audio, a derivative work.

Of course I saw Amazon cave. I suspect that was a
commercially-driven position since they want to profit
from Kindle. I don't consider this to be settled law.
Please note Amazon is not creating the derivative work,
the user is by running the copyrighted work through a pgm.
This might well be "fair use", or even protected under the ADA.

Post by Rod Pemberton
Earlier, you stated that you thought I was confusing copyrights and patents.
I think you failed to separate a patentable process from copyrighted work.
E.g., Amazon's text-to-speech process might be patented by their software
supplier, but the resulting computer generated speech is a derivative work.
This is no different from a lexer operating on a grammar. The lexer's code
both internal and emitted may be copyrighted. The lexer's process might be
patented. But, the transformation on the input grammar is a derivative
work which would be covered by the grammar's copyright.

I am no sure what you mean by lexer and grammar. If "compiler"
and "computer language", only a few of your cases are close, and
none are direct. A shame that COMIT vs SNOBOL didn't go to court.

Post by Rod Pemberton
NEC Corp. v Intel Corp.
8) Copyright does not protect process, or reexpression of ideas is
Baker v. Selden
19) Technical interfaces, e.g., data structure names, data structure
Baystate v. Bentley
Mitel Inc. v. Iqtel
Sega Enterprises Ltd. v. Accolade
Lotus v. Borland
Apple Computer v. Microsoft
Synercom v. University Computing
20) System interfaces, e.g., ability to execute an application, aren't
Bateman v. Mnemonics

Please note that I'm not saying a language cannot be copyrighted.
I am saying that such claim is far from legally certain. It
is very unclear, and courts could find either way until it is
clarified by legislation or a hgh-court precedent.

-- Robert

Rod Pemberton

2009-03-03 17:57:04 UTC

Post by Robert Redelmeier
I am no sure what you mean by lexer and grammar. If "compiler"
and "computer language",

We aren't discussing the copyrighting the language itself. We were
discussing the copyrights on a set of rules that define how to implement the
language, and derivatives that come from that copyrighted set of rules.

A grammar is a set of rules that defines how to construct a language. It's
basically a "program" which describes the programming language itself. The
"program" is written in another language (e.g., BNF) suited to describing
numerous languages. It's much like a text version of diagramming sentences.
But, instead of a visual drawing with lines showing where the adverbs,
adjectives, verbs, nouns, phrases go, you have a set of rules (grammar) that
describe where they are allowed to be and how they relate to each other.

A lexer and parser are the first two stages of some compilers. The lexer
and parser each take a grammar or part of a grammar as input, i.e., each
needs a set of rules. A lexer is a program which converts sequences of
characters into larger groups called tokens based on the (or some of the)
rules from a grammar, e.g., for English this is like describing how to
construct words from letters or numbers from digits. A parser is a program
which takes tokens and converts them into larger sequences based on the (or
some of the) rules from a grammar, e.g., for English this is like describing
how to contruct sentences from words.

Post by Robert Redelmeier
Please note that I'm not saying a language cannot be copyrighted.
I am saying that such claim is far from legally certain. It
is very unclear, and courts could find either way until it is
clarified by legislation or a hgh-court precedent.

Ok, well we weren't talking about copyrighting a language. We were talking
about copyrighting the "program" or "rules" (grammar) that describe how a
language is constructed. One example of this is the C++ grammar by Roskind
who (supposedly) accurately implemented C++ using a predominantly different
set of rules from the grammar that's in the C++ spec. He has a right to
copyright his set of rules, grammar, or "language program." Yes? It's a
substantial and unique work created by him... Derivatives created from that
set of rules, even by program, are copyrightable if they still reflect the
authors original content - with some exceptions like object code, "fair
use", and disabilities. As I see things, in the case of the lexer and
parser, everything they input, everything they do, and the majority of what
they typically emit, is based upon that original content.

Rod Pemberton

Robert Redelmeier

2009-03-04 03:48:59 UTC

Post by Rod Pemberton
Ok, well we weren't talking about copyrighting a language.
We were talking about copyrighting the "program" or "rules"
(grammar) that describe how a language is constructed. One
example of this is the C++ grammar by Roskind who (supposedly)
accurately implemented C++ using a predominantly different
set of rules from the grammar that's in the C++ spec.

This sounds very complex and I hardly expect lawyers
or judges to see it as other than mechanical.

Post by Rod Pemberton
He has a right to copyright his set of rules, grammar, or
"language program." Yes? It's a substantial and unique
work created by him...

The specific expressions of the rules, grammar and compiler
can certainly be copyrighted. But not the ideas contained
therein. Those could only be protected by patent.

Sir Arthur Conan Doyle did not hold the copyright on all
detective novels, or even those that start with a murder
and feature a detective with a sidekick, just his particular
"Sherlock Holmes" characters and stories.

Post by Rod Pemberton
Derivatives created from that set of rules, even
by program, are copyrightable if they still reflect
the authors original content -

... but arguably only if non-essential [non-functional] stylistic
elements are duplicated. If the idea takes "X" (murder or building
a symbol table) to implement, that part is not copyrightable.

Post by Rod Pemberton
with some exceptions like object code, "fair use", and disabilities.
As I see things, in the case of the lexer and parser, everything
they input, everything they do, and the majority of what they
typically emit, is based upon that original content.

Perhaps, but input and output look nothing at all like the
copyrighted work. While they might be derivitive in a work
process sense, they probably fail the definition of derivitive in
the sense of a copy. They are in no senses substitutes for the
copyrighted work. And that is what copyright protects. Not use.

This sounds very much like IBM PC clone BIOS generation.
Chinese walls with the analysis team separate from the writing team.

-- Robert

Wolfgang Kern

2009-03-03 15:21:50 UTC

Rod Pemberton posted:

[...]

good to know that none of my code may ever be in daubt about
copyright infringement, ...well, as far as yet :)

__
wolfgang

Post by Rod Pemberton
0) Only the owner of a copyright has the right to prepare derivative works
section 106 b. of Copyright Act
Nichols v. Universal Pictures Corp
Sheldon v. Metro-Goldwyn Pictures Corp
Steinberg v. Columbia Pictures
Durham Industries, Inc. v. Tomy Corp.
US Copyright Registration for Derivative Works (Circular 14)
Walker & Zanger, Inc. v. Paragon Indus
3) a derivative work with major changes that doesn't qualify as a unique
Durham Industries vs. Tomy Corp
Section 103 of Copyright Act (17 USC)
Computer Associates v. Altai
4) Portions of a technical standards document which are required to be used
Feist Publications, Inc. v. Rural Tel. Serv. Co
Computer Associates v. Altai
Baystate v. Bentley
Section 102 b of Copyright Act
"Scènes à faire doctrine"
5) A derivative work must be sufficiently different to prevent copyright
Gracen v. Bradford Exchange
NEC Corp. v Intel Corp.
Feist Publications, Inc. v. Rural Tel. Svc.
8) Copyright does not protect process, or reexpression of ideas is
Baker v. Selden
Feist Publications, Inc. v. Rural Tel. Svc.
Veeck v. Southern Building Code Congress International, Inc.
11) Works written by the U.S. government are not copyrightable (Public
section 105 of Copyright Act
12) Copying Public Domain material from a copyrighted work is a
Feist Publications, Inc. v. Rural Tel. Serv. Co
Section 107 6 of Copyright Act
Folsom v. Marsh
Sony Corp. v. Universal City Studios
15) Defeating "fair use" requires proof harmful or if widespread would hurt
Sony Corp. v. Universal City Studios
Sony v. Connectix
Sega v. Accolade
Apple Computer v. Franklin Computer
Lewis Galoob Toys v. Nintendo of America
19) Technical interfaces, e.g., data structure names, data structure
Baystate v. Bentley
Mitel Inc. v. Iqtel
Sega Enterprises Ltd. v. Accolade
Lotus v. Borland
Apple Computer v. Microsoft
Synercom v. University Computing
20) System interfaces, e.g., ability to execute an application, aren't
Bateman v. Mnemonics
Fogerty v. Fantasy, Inc
Feist Publications, Inc. v. Rural Tel. Serv. Co
Rod Pemberton

alex

2009-03-17 23:15:22 UTC

Post by Wolfgang Kern
good to know that none of my code may ever be in daubt about
copyright infringement, ...well, as far as yet :)
__
wolfgang

yep

Rod Pemberton

2009-03-04 00:29:46 UTC

WooHoo! Got me a "Hello World!"... Yes, it seems he didn't match up the
arg order. Apparently, he was using getlitstk() and dumpltstk() to

reverse

some or all of the arguments. Anyway, more attempts at bootstrapping

left

for another day.

Good deal!

Well, I tried a bootstrap. It's a no go. (expected) So, there are some
other code generation problems.

:-/

Ok, I got to work on it again today. It's much closer now. I'm happy.
But, it's not quite bootstrapped properly.

Unfortunately, I'd made a backup prior to it working and after my
not-working bp register modifications. But, I failed to make a backup of
the version that generated the "Hello World!"... Fortunately, working
backwards, I think I eliminated a few more bugs!

I'd call the current version "bootstrapped with many bugs" since the third
stage compile actually executes, but fails to open the output file. But, it
emits code which is nearly the same as the prior stage. It's got 35 very
similar bugs and maybe 20 or so, er... WTF bugs.

The similar bugs fail into three forms: a "jmp cc0" - an invalid label, an
extra "add sp, value", or both together. It seems some labels are loosing
the numeric used to construct them. I'm hoping the "add sp, value" is
related to the same issue. The extreme bugs are generating some really
wierd, but syntactically correct code, for parts of C5LIB.

By really wierd, I mean like AI wierd... I'm hoping part of the app didn't
overwrite itself. I really should try to locate a small C functionality
test app...

Rod Pemberton

s***@yahoo.com

2009-03-04 03:38:15 UTC

WooHoo! Got me a "Hello World!"... Yes, it seems he didn't match up

the

arg order. Apparently, he was using getlitstk() and dumpltstk() to

reverse

some or all of the arguments. Anyway, more attempts at bootstrapping

left

for another day.

Good deal!

Well, I tried a bootstrap. It's a no go. (expected) So, there are some
other code generation problems.

:-/

Ok, I got to work on it again today. It's much closer now. I'm happy.
But, it's not quite bootstrapped properly.
Unfortunately, I'd made a backup prior to it working and after my
not-working bp register modifications. But, I failed to make a backup of
the version that generated the "Hello World!"... Fortunately, working
backwards, I think I eliminated a few more bugs!
I'd call the current version "bootstrapped with many bugs" since the third
stage compile actually executes, but fails to open the output file. But, it
emits code which is nearly the same as the prior stage. It's got 35 very
similar bugs and maybe 20 or so, er... WTF bugs.
The similar bugs fail into three forms: a "jmp cc0" - an invalid label, an
extra "add sp, value", or both together. It seems some labels are loosing
the numeric used to construct them. I'm hoping the "add sp, value" is
related to the same issue. The extreme bugs are generating some really
wierd, but syntactically correct code, for parts of C5LIB.

Are you certain that the register usage is synchronized? AX primary,
BX secondary - mostly - is how I have it. DX is affected by divide,
memory model is small, CS=DS=SS.

Steve

By really wierd, I mean like AI wierd... I'm hoping part of the app didn't
overwrite itself. I really should try to locate a small C functionality
test app...
Rod Pemberton- Hide quoted text -
- Show quoted text -

Rod Pemberton

2009-02-21 08:55:58 UTC

Post by s***@yahoo.com
http://www.federalreserve.gov/newsevents/speech/bernanke20090218a.htm
There are a number of insightful gems in there...but this one proves
"
The liability side of the Federal Reserve's balance sheet is
relatively simple, consisting primarily of currency issuance (Federal
Reserve notes) and reserves held by the banking system on deposit with
the Federal Reserve.
"
One should ask himself; in what way is the Fed liable to holders of
currency in circulation. -only in the sense of a future payoff in
statutory dollars.

Well, I responded to this in my prior post. You brought up more on our past
conversation on banking, so I'll bring up more on our past conversations on
"Big Brother"... The following came across today. The Federal going is
going to want to pass a Federal law to track all road vehicles *EVERYWHERE*
via GPS after a major study recommended it:
http://news.yahoo.com/s/ap/20090221/ap_on_go_ca_st_pe/lahood_vehicle_milea
ge_tax

It's all for road taxataion purposes, of course, which is total BS... Why
do you need GPS to tally mileage for taxation? The device that does that is
called an odometer. It seems "Big Brother" just never ends when "Big
Government" exists.

First the banking for tax purposes, then the phones for fighting crime, then
the email for, well, nobody still knows, then American outrage changes the
law, then the phones and email without American consent, then public air
transportation... now, personal travel is going to be monitored. Has anyone
here begun to see the parallels to totalitarianism or Nazi-ism where
*EVERYONE* is monitored *ALL THE TIME* by an *OUT OF CONTROL* government due
to it's *PARANOIA*?

I'd really like our new President to answer a tough question:

What do you feel about the Federal government attempting to surreptiously
"enslave" and "chain" citizens, including minorities, to the US gov't. via
technology such as GPS, rfid, tax and child support databases, phone and
email wiretaps, etc.? As a minority, aren't you *EXTREMELY* offended?
Don't you see currently separate "Big Brother" citizen monitoring systems
becoming a singular cohesive "entity" due to some valid rationalization:
terrorism, protectionism, protect our children, our future, our jobs, our
country, etc.?

The illegal drug trade is based almost entirely on pricing. Our laws set
the outrageous pricing. If we legalized drugs for only his term, the drug
companies would put all the drug criminals responding to US pricing out of
business within the first year. It'd also be interesting to have Obama
answer how he feels about the US destroying numerous other countries, and
economically forcing minorities of other countries into drug production
around the world because of our pricing of illicit drugs due to our laws.
Democrats elected him because they thought he'd support minority causes and
change. I already believe he'll be mostly a "dud" of a President due to
conflicts between supporting minority rights or restitution, and ensuring
lawfulness or safety... Helping retrieve Geronimo's bones for his
ancestors, for another minority group, from Skull and Bones et. al. is just
one of dozens of such issues that'll come up over his term. Guantanamo,
freeing of other minorities, deemed "terrorists", is another one... And, I
for one, will be judging him on what got him elected. I'll especially be
judging him on his ability to put an end to US pricing driven illegal drug
trade that has destroyed lives of minorities around the world and in US
cities.

It's interesting how many 80's and early 90's Heavy Metal songs still today
accurately characterize politics, society, religion, war, etc. Songs by
Metallica, Megadeath, Metal Church, Queensryche, etc. Prescient? In this
case, we could take the song "Empire" from Queensryche's 1990 album
"Empire":

"...
Gotta hustle if he wants an education
he's got a long way to go.
Now he's out on the street all day
selling Crack to the people who pay.
Got an AK-47 for his best friend
business the American way.
...
Black man, trapped again. hold his chain in his hand.
Brother killing brother for the profit of another,
Game point, nobody wins. Decline, right on time.
...
"

I doubt our President has even heard that song... Almost two decades after
it was written inner city minority black and hispanic drug gangs are as rife
as they were when the song was written. He should cry, and then do
something or be seen as a "dud".

Rod Pemberton

James Harris

2009-02-15 22:53:57 UTC

On 15 Feb, 07:36, "Rod Pemberton" <***@nohavenot.cmm> wrote:

...

Post by Terence
Anybody got any ideas on bringing this Forum back to dsicussions on
ASM, without the bilge?

...

Post by Rod Pemberton
Individuals posting to comp.lang.c are so mean and hostile to anything
outside an excessively narrow range of C topics that you can't even post a C
only related question without 100+ insult posts. The entire newsgroup is
"spammed" by these "insult and control" posts. If you ask anything outside
ISO C99 or the N1256 draft on c.l.c, you'll have a small clique of "ISO C
only!" people who will vehemently lambast you to enforce their perspective
on what should or shouldn't be discussed in comp.lang.c. Plus, you'll have
another twenty or so posts from idiots, I call "parrots," who you'd never
even know were there since they *never* post anything C related. But, as
soon as the "parrots" think you've attacked the clique, the "parrots" will
post insults, attempt to enforce their perspective of group control, and
blather idiocy and unworthy acclaim for members of the clique. Except for
one member of the clique, this group of individuals seems to be closely
related to a book on C, "C Unleashed," which was a market failure since it
is an exceptionally thin on content and an insignificant piece of trash
compared to other more complete and accurate books on C. Since the authors
were all from c.l.c., they apparently still have a vested interest in
pushing their worthless and frequently inaccurate beliefs about C onto
everyone interested in C who posts to c.l.c. Perhaps they believe if they
continue pushing their beliefs on C long enough, their beliefs will come
true or they'll be validated somehow. (Unlikely, since their beliefs aren't
based in fact. This c.l.c. aggression has been going on for almost a decade
now...)

I just wanted to say that I disagree about C Unleashed. I thought it
was a great book. For example the early parts were very readable and
covered basic questions of approach that other books I'd read had
missed. Much of the rest is good for reference.

On the other hand that's a great description you've given of the
attitude of the sharks on comp.lang.c. The group is seriously caustic.

Of course, speaking of C, Terence asked about getting this group back
to asm discussions....

Sorry Terence!

James

n***@gmail.com

2009-02-16 06:23:37 UTC

Ok, I'll humor you. What's the smallest set of general (i.e., no fpu, no
SSE, no XMM, etc) x86 assembly instructions needed to program general x86
assembly? There, that's asm related... Yes? Is it lodsb, stosb, push,
pop, xchg, loop, jcxz and arithmetic instructions? Or, can you think up any
other use for "rep lodsb" other than that posted by Jim Leonard on
comp.lang.asm.x86 recently?

You still at least need 'ret' 'call' or 'int' in there somewhere! :)

--
Moderated groups loose the "immediacy" of
non-moderated groups.

There is always a sacrifice for every gain.

But, a few words from Betov, would produce 100+ posts. I even attempted to
help him see that HLA could be much more than what it is with some minor
changes. He seemed to fail to comprehend. That stunned me. Perhaps, he

http://web.mac.com/randyhyde/HighLevelAsm/index.html

Now supports cross-platform multi-threaded applications with a thread-
safe library. *That* what you had in mind??

--
Individuals posting to comp.lang.c are so mean and hostile to anything
outside an excessively narrow range of C topics that you can't even post a C
only related question without 100+ insult posts. The entire newsgroup is
"spammed" by these "insult and control" posts. If you ask anything outside
ISO C99 or the N1256 draft on c.l.c, you'll have a small clique of "ISO C
only!" people who will vehemently lambast you to enforce their perspective

I always assumed this clique's behavior ensured that MSVC kiddies
would be dis-abused of any myths about Microsoft's "authority" over
what constitutes the C language. This is a "good thing" (TM) isn't
it??

Nathan.

Rod Pemberton

2009-02-16 06:56:30 UTC

I always assumed this clique's behavior ensured that MSVC kiddies
would be dis-abused of any myths about Microsoft's "authority" over
what constitutes the C language.

Any use or mention of GCC extensions will produce irate responses too. GCC
has a number of C extensions that fit very well with the original spirit of
C, such as being able to take the address of labels, etc.

Rod Pemberton

fbkotler

2009-02-16 18:33:02 UTC

Post by Terence
Anybody got any ideas on bringing this Forum back to dsicussions on
ASM, without the bilge?

"White tea" recently posted an asm related post that nobody, including you,
responded to...

It has come to my attention that I'm not seeing all posts. The thieves
at Verizon have sold me to Fairpoint. A ping to news.fairpoint.net
suggests that it's redirected to Giganews... but they won't accept my
login. Maybe need the "primary account" username and password. I'll have
to beat that out of my roommate when he gets home... although he
frequently doesn't remember his password... The situation *may* improve
(not really counting on it)...

Post by Rod Pemberton
Ok, I'll humor you. What's the smallest set of general (i.e., no fpu, no
SSE, no XMM, etc) x86 assembly instructions needed to program general x86
assembly? There, that's asm related... Yes? Is it lodsb, stosb, push,
pop, xchg, loop, jcxz and arithmetic instructions? Or, can you think up any
other use for "rep lodsb" other than that posted by Jim Leonard on
comp.lang.asm.x86 recently?

I've seen just "lodsb" used as a replacement for "inc esi" (Fasm code
uses it, IIRC)... Does that count?

Post by Rod Pemberton
--

Why isn't this killing the "quote"? Didn't want it to, but expected it
to... Maybe my newsreader's broken...

Post by Rod Pemberton
You know, people come and go. alt.* is/was for stuff that's less
controlled. comp.*, e.g., comp.lang.asm, is for assembly "without the
bilge". If you want to see a "dead" group, try that one...

My understanding is that the creation of c.l.a.x. (per vote of c.l.a.
denizens, on account of the "bilge") was supposed to "kill" c.l.a. Last
I tried it, it *did* work... although not carried on all servers, I guess...

Post by Rod Pemberton
And,
comp.lang.asm.x86, which is moderated, is for x86 assembly - at the
discretion of Chuck... But, moderated groups are a pain in the rear. You
can't read what others posted until they clear the moderator, so there might
be 10 or most posts saying the same thing. And, when you reply, there might
be 10 or more posts that say the same thing... And, you have to wait and
wait and wait for the moderator to see if anyone replied, who replied, and
what they said. And, you're never quite sure why some posts "go missing".
Were they "moderated", i.e., censored by deletion? The moderators always
claim they never got the post... Moderated groups loose the "immediacy" of
non-moderated groups.

My understanding is that most moderated groups are far slower than
c.l.a.x. If your post is rejected by the moderator, you *should* get a
rejection message... provided that you're using a valid "From" address,
which I understand you don't...

Post by Rod Pemberton
Well, I haven't seen a post here from the "KKK" in a while (Kotler,
Kleebauer, or Kern).

Hadn't thought of us quite that way. :) I'm still around. I think
Herbert's still with us. I fear Wolfgang may have "gone missing".

Post by Rod Pemberton
They were contributing much "pure" assembly content.
Actually, over the few years that I've been reading this newsgroup, it's
never been 100% assembly, although there was much more traffic and a bit
more assembly. Except for the past two years, 40% seemed to be Hyde
promoting HLA and Betov insulting him or promoting RosAsm, with another 20%
unrelated Delphi stuff from Skybuck or "hutch--" lying (at least that's what
I believe) about his MASM licensing agreements...

Any reason to think he's lying?

Post by Rod Pemberton
So, for now, we've got
some "silence." Enjoy it.

Hell, if I wanted silence, I'd unsubscribe! :)

Post by Rod Pemberton
I think the fact that there is some non-assembly is a nice thing as long as
you aren't bombarded with hundreds of posts on the same thing or with
constant arguments, ala Hyde/Betov/Skybuck/hutch-- etc. We finally got Hyde
to stop arguing with Betov. He left. That's unfortunate, since he knew
assembly, but some people just don't have a purpose, or aren't willing to
contribute, without arguing. I attempted to engage Hyde in many assembly
and non-assembly topics, especially energy. He almost never responded.
But, a few words from Betov, would produce 100+ posts. I even attempted to
help him see that HLA could be much more than what it is with some minor
changes. He seemed to fail to comprehend.

I think Randy "wants to do it *his* way". (I've observed that tendency
in asm-heads) He completely ignored a patch Chuck submitted, too - fixed
a real bug, but noooo...

Post by Rod Pemberton
That stunned me. Perhaps, he
was just rejecting the idea, but had some psychological inability to say so
politely.

I read a review from one of Randy's former students - claimed he was
lacking in social skills. I don't think the guy had met Betov! :)

Post by Rod Pemberton
Anyway, I like the fact we can discuss assembly on a broader
scope: as MASM, as NASM, as GAS, for OS development, for algorithms, for
applications, etc.
--
Individuals posting to comp.lang.c are so mean and hostile to anything
outside an excessively narrow range of C topics that you can't even post a C
only related question without 100+ insult posts. The entire newsgroup is
"spammed" by these "insult and control" posts. If you ask anything outside
ISO C99 or the N1256 draft on c.l.c, you'll have a small clique of "ISO C
only!" people who will vehemently lambast you to enforce their perspective
on what should or shouldn't be discussed in comp.lang.c. Plus, you'll have
another twenty or so posts from idiots, I call "parrots," who you'd never
even know were there since they *never* post anything C related. But, as
soon as the "parrots" think you've attacked the clique, the "parrots" will
post insults, attempt to enforce their perspective of group control, and
blather idiocy and unworthy acclaim for members of the clique. Except for
one member of the clique, this group of individuals seems to be closely
related to a book on C, "C Unleashed," which was a market failure since it
is an exceptionally thin on content and an insignificant piece of trash
compared to other more complete and accurate books on C. Since the authors
were all from c.l.c., they apparently still have a vested interest in
pushing their worthless and frequently inaccurate beliefs about C onto
everyone interested in C who posts to c.l.c. Perhaps they believe if they
continue pushing their beliefs on C long enough, their beliefs will come
true or they'll be validated somehow. (Unlikely, since their beliefs aren't
based in fact. This c.l.c. aggression has been going on for almost a decade
now...)

I don't *think* that's the reason I don't "like" C... but it might be a
factor... :)

I'll try to get back to ya on that "Nasm philosophy" question - or
something asm-related - RSN... Just haven't been "in the mood" lately...

Curiously, when I type "alt.lang.asm" into google groups, the next hit
after the group itself is "How many here think we should close down
alt.lang.asm?" from 2004, so it ain't a new idea. I like Terrence's
approach better! Hijack it back!!!

Best,
Frank

Herbert Kleebauer

2009-02-16 23:21:55 UTC

Post by fbkotler
It has come to my attention that I'm not seeing all posts. The thieves
at Verizon have sold me to Fairpoint. A ping to news.fairpoint.net
suggests that it's redirected to Giganews... but they won't accept my
login.

A text based communication system like newsgroups is dead as assembly
programming is. The new generation of computer users don't want to
see ascii characters but at least flash movies on the computer screen.

I've seen just "lodsb" used as a replacement for "inc esi" (Fasm code
uses it, IIRC)... Does that count?

The minimal necessary instruction subset is the "sub" instruction and
nothing else. Here a simple "hello world" program:

@=$100

0100: 29 f6 sub.w r5,r5
0102: 81 ee feeb sub.w #$feeb,r5
0106: 81 2c 9cd6 sub.w #$9cd6,(r5.w)
010a: 29 d2 sub.w r1,r1
010c: 81 ea fee5 sub.w #-text,r1
0110: 29 c0 sub.w r0,r0
0112: 80 ec f7 sub.b #-$09,m0
0115: 66 2d 00c321cd sub.l #$c321cd,r0

011b: text: dc.b 10,13,"hello world",10,13,"$"

Post by fbkotler
I don't *think* that's the reason I don't "like" C... but it might be a
factor... :)

You should hurry up and start to like C before it's also dead like
assembly. You should take a look at the AVR32 instruction set, then
would know why people prefer to use embedded Linux and gcc instead
of writing a stand alone assembly program.

Post by fbkotler
Curiously, when I type "alt.lang.asm" into google groups, the next hit
after the group itself is "How many here think we should close down
alt.lang.asm?" from 2004, so it ain't a new idea.

Somehow alt.lang.asm was closed down in 2005 by Beth.

n***@gmail.com

2009-02-17 19:09:40 UTC

Post by Herbert Kleebauer
A text based communication system like newsgroups is dead as assembly
programming is. The new generation of computer users don't want to
see ascii characters but at least flash movies on the computer screen.

All the "eye candy" of the "social" sites is meant to enhance and
extend the interactivity. My small survey of { youtube, facebook,
orkut, linkedin, etc. } reveals that they definitely serve as a small
"time sink" and I'm still waiting to see what, if any, "value" is
returned. The big question is: Which technology will survive the
world's economic meltdown?

Post by Herbert Kleebauer
The minimal necessary instruction subset is the "sub" instruction and
0100: 29 f6 sub.w r5,r5
0102: 81 ee feeb sub.w #$feeb,r5
0106: 81 2c 9cd6 sub.w #$9cd6,(r5.w)
010a: 29 d2 sub.w r1,r1
010c: 81 ea fee5 sub.w #-text,r1
0110: 29 c0 sub.w r0,r0
0112: 80 ec f7 sub.b #-$09,m0
0115: 66 2d 00c321cd sub.l #$c321cd,r0
011b: text: dc.b 10,13,"hello world",10,13,"$"

There is a hidden "int 21h" in the last line. "Assembly is the
language that shows!" unless the author's name is Kleebauer. :)

Post by Herbert Kleebauer
Somehow alt.lang.asm was closed down in 2005 by Beth.

About 60% of her posts were off-topic. But they certainly were
interesting.

Nathan.

Rod Pemberton

2009-02-17 23:55:06 UTC

Post by Herbert Kleebauer

I've seen just "lodsb" used as a replacement for "inc esi" (Fasm code
uses it, IIRC)... Does that count?

The minimal necessary instruction subset is the "sub" instruction and

[code snip]

Post by Herbert Kleebauer
... the "sub" instruction and nothing else

I'll won't give you that due to the self-modifying code which executes
instructions other than sub once modified.

Post by Herbert Kleebauer
The minimal necessary instruction subset is the "sub" instruction

I'd say that's almost, but not quite, true. While "sub" allows you to
create an constants in registers, memory, and stack, it'll take three
operations to do a move between any of them. Of course, as Nathan pointed
out "call", "ret", "int", can't be done with "sub". Of course, you can't
loop or branch without self-modifying code using "sub" either. So, I agree
that "sub" can be used to replace some of the mentioned instructions so far,
to create a minimal set. But, it's definately not an optimal minimal set...

Rod Pemberton

rio

2009-02-19 07:00:42 UTC

Post by Herbert Kleebauer
You should hurry up and start to like C before it's also dead like
assembly. You should take a look at the AVR32 instruction set, then
would know why people prefer to use embedded Linux and gcc instead
of writing a stand alone assembly program.

Assembly never dead because there are programs can be written
only in assembly, and there are programs where asm is the right language
(for time to write, easy to read and write, few bug)
than i don't know why, some macro assembly that preserve
1-1["some subset of symbol"->"CpuInstruction"] can be easier to write than C.

Rod Pemberton

2009-02-17 01:29:48 UTC

Post by Terence
Anybody got any ideas on bringing this Forum back to dsicussions on
ASM, without the bilge?

"White tea" recently posted an asm related post that nobody, including you,
responded to...

It has come to my attention that I'm not seeing all posts.

You could try these free services:

1) Google Groups (Seems to get pick up almost everything, even from the
remotest junk servers.)
2) textnews.cambrium.nl (I've only seen a very few posts not make it here.)
3) www.aioe.org or nntp.aioe.org (Was good before their last hardware
and/or ISP shutdown issues.)

None of them require authentication. I've noticed that although AIOE is
back online, it's not carrying alt.lang.asm for read... Or, at least, I'm
not getting any messages to read for a.l.a when I connect. Maybe I need to
purge my messages so it resynchonizes. But, AIOE does post messages to
a.l.a.

Post by fbkotler
... roommate ... he ...

Roomate? He? :-o
Sigh... There's only a few situations I know of where you'd have a male
roommate, and most of them are (usually considered) undesirable. :-D Think
about it...

I've seen just "lodsb" used as a replacement for "inc esi" (Fasm code
uses it, IIRC)... Does that count?

The only thing other than for string use that I've used "lodsb" for was with
"xchg" for space: 2 byte register loads with lodsb/w to al/ax, xchg to move
to other register.

Post by Rod Pemberton
--

Why isn't this killing the "quote"? Didn't want it to, but expected it
to... Maybe my newsreader's broken...

Sorry, didn't know it was supposed to... Is it?

Post by Rod Pemberton
Well, I haven't seen a post here from the "KKK" in a while (Kotler,
Kleebauer, or Kern).

Hadn't thought of us quite that way. :)

:-) Hopefully, no undeserved negative connotations will stick. I just
noticed a bunch of lastnames with K... Thought it'd be funny.

Post by fbkotler
I'm still around. I think
Herbert's still with us. I fear Wolfgang may have "gone missing".

Well, it seemed he thought he'd be back online after a move in his last post
a number of months ago. He mentioned health issues a few times... We
aren't family, but it'd still be nice to know his status.

Post by fbkotler
I read a review from one of Randy's former students - claimed he was
lacking in social skills.

*I'm* lacking in social skills...

Post by fbkotler
I'll try to get back to ya on that "Nasm philosophy" question

IIRC, I didn't post a philosophy question. ;-) Even if I should've or
could've or might've under certain circumstances or at a different point in
time stated it more politely, that's why I use NASM. I want simplicity.
Extra details, RTFM, "it's in there," etc. doesn't make things easier for
me. "It's in there" with MASM too. If NDISASM always disassembled
correctly, so one could use it to determine correct syntax from constructed
byte sequences, it wouldn't be as significant to me. But, NDISASM hasn't
been keeping pace with NASM, IMO.

Post by fbkotler
Just haven't been "in the mood" lately...

Coming out of the "winter blues" here too... Yeah, it was the end of
another long, cold one here, at same time parts of OZ were ablaze. Did you
see the videos of OZ's firestorms? Unreal! (I've been using AU for OZ, but
noticed the media uses AU for African Union... I probably PO'd all of
Africa in some old post!) Fortunately, other areas of the US that don't
usually get severe winters got blasted pretty hard too! That warms the
heart a bit and provides a small tear of perverse joy. :)

Rod Pemberton

Alexei A. Frounze

2009-02-17 04:02:53 UTC

...

Post by fbkotler
... roommate ... he ...

Roomate? He? :-o
Sigh... There's only a few situations I know of where you'd have a male
roommate, and most of them are (usually considered) undesirable. :-D Think
about it...

Would sharing an apt/house to save some green be undesirable too?

Alex

n***@gmail.com

2009-02-17 19:34:47 UTC

Post by Alexei A. Frounze
...

Post by fbkotler
... roommate ... he ...

Roomate? He? :-o
Sigh... There's only a few situations I know of where you'd have a male
roommate, and most of them are (usually considered) undesirable. :-D Think
about it...

Would sharing an apt/house to save some green be undesirable too?

Almost mandatory in today's economy! :)

I've always pictured Frank "pulling his hair out" at a convalescent
home while attempting to train an army of geriatrics to build an All-
ASM OS to rival Windows. :)

I believe Rod was joking about a "cell mate" being undesirable. Just
picture Frank locked-away at a secret Area-51 maximum security
facility. He is secretly recruiting *us* to help him escape. So far,
my 3733T hacking abilities have netted me the secret blueprints and
I've turned-on the Xmas lights and beacon to distract the guard.

http://www.drivemeinsane.com/

We need to keep a 24 hr/day watch on that cam -- when the guard
enters, open cell door 42 and gate 7. He'll still need to craw
through the sewers, but... freedom is freedom! :)

Nathan.

Rod Pemberton

2009-02-17 23:23:13 UTC

Post by n***@gmail.com
I believe Rod was joking about a "cell mate" being undesirable. Just
picture Frank locked-away at a secret Area-51 maximum security
facility. He is secretly recruiting *us* to help him escape. So far,
my 3733T hacking abilities have netted me the secret blueprints and
I've turned-on the Xmas lights and beacon to distract the guard.
http://www.drivemeinsane.com/

If you're looking for ways to waste time, you could try obtaining and
playing Penn & Teller's "Desert Bus." An eight hour realtime at 45mph bus
route set in the desert with a bus that pulls slightly to the right...
Various videos on Youtube.

http://www.lostlevels.org/wordpress/2006/03/02/penn-jillette-on-smoke-mirrors-for-sega-cd/

Or, you could play "Aqua Team Hunger Force's "Go Right" aka "Worst Game
Ever":

"Worse Game Ever"
http://www.adultswim.com/games/game/index.html?game=goright

Rod Pemberton

n***@gmail.com

2009-02-18 04:28:40 UTC

Post by Rod Pemberton
If you're looking for ways to waste time,

It appears as though this is becoming a C forum. So I guess I could
learn the proper tongue:

,---
| waste.c
,---
#include <stdio.h>
#include <time.h>

int main( void )
{
long tstart, tend, tdiff;
tstart = clock();
mylabel:
tend = clock();
tdiff = tend - tstart;
if ( tdiff > 500 )
{
printf( "%d\n", tend );
tstart = clock();
}
goto mylabel;
}
`---

Nathan.

Rod Pemberton

2009-02-18 07:40:30 UTC

Post by Rod Pemberton
If you're looking for ways to waste time,

[C source displaying time difference]

Sigh... Nathan, were you one of those students who didn't follow the test
directions? :-)

I said "waste time", not "watch time"... One implies user action. User
inaction suffices in the other.

Post by n***@gmail.com
#include <stdio.h>
#include <time.h>
int main( void )
{
long tstart, tend, tdiff;
tstart = clock();
tend = clock();
tdiff = tend - tstart;
if ( tdiff > 500 )
{
printf( "%d\n", tend );
tstart = clock();
}
goto mylabel;
}

0) You want %ld, not %d. tend is a long.
1) clock() actually usually returns a generic integer type in ANSI C
environments which is always an "unsigned long" even thought it's pre-ANSI
type is officially "long"... (So much for C's type system...)
2) You probably want greater or equal to 500, not greater. It's running
tdiff=505 here...
3) clock() is the process time. So, it should start at zero... (Despite
anything the spec.'s say.) The point is there is no reason to init tstart.
4) A return() or exit() from main() are implicit in some C standards,
required in other(s), and optional in recent standards.
5) FYI, I haven't seen much use of clock() in C. time() seems to be
preferred...
6) goto isn't generally used in C since most C programmers learned
structured programming concepts. So, "mylabel" and "goto mylabel" can be
implemented with a for(;;) or while(1)

While I'm sure you were probably "just joking" with the C issue. Here is my
take on your program anyway. It does have a potential accuracy error due to
equal or greater, but isn't likely to occur in general use. You could
rewrite it for equal, but then you'd need an else-if() error case.

#include <stdio.h>
#include <time.h>

#define TDIFFMAX 500
int main(void)
{
unsigned long tstart=0;

while(1)
{
if((clock()-tstart)>=TDIFFMAX)
{
tstart+=TDIFFMAX;
printf("%lu\n",tstart);
}
}
return(0);
}

You could also throw the "tstart+=TDIFFMAX" into the printf() statement and
eliminate the if() body, but that'll get some ISO C99 spec. guy screaming
"bloody murder" about "sequence points" on the += operator. But, if your
compiler compiles K&R C too, it'll work properly.

HTH,

Rod Pemberton

n***@gmail.com

2009-02-18 12:39:12 UTC

Sigh... Nathan, were you one of those students who didn't follow the test
directions? :-)

Yes. If I thought the answer was C, I always colored-in the A, B, and
D ovals and left the C oval blank.

I said "waste time", not "watch time"... One implies user action. User
inaction suffices in the other.

Wrong. The first implies the value displayed on the junkyard clock;
the second can typically be obtained by looking at one's wrist.

3) clock() is the process time. So, it should start at zero... (Despite
anything the spec.'s say.) The point is there is no reason to init tstart.

I beg to differ. The simple act of declaring a variable's type does
NOT also automatically assign a known value to that variable.

#include <stdio.h>

int main(int argc, char *argv[])
{
int myvar;
printf( "myvar = %d\n", myvar );
return 0;
}

In Windows, this always gives 2 as the result.
In Linux, it always gives a large negative number.

HTH,

I appreciate you time.

Nathan.

Rod Pemberton

2009-02-18 23:27:56 UTC

3) clock() is the process time. So, it should start at zero... (Despite
anything the spec.'s say.) The point is there is no reason to init

tstart.

Post by n***@gmail.com
The simple act of declaring a variable's type does
NOT also automatically assign a known value to that variable.

True. But, assigning a initial value to an unitialized variable and initing
tstart to clock(), are two similar but unrelated things. One is to ensure a
variable has a defined starting value. The other is used in the computation
of some algorithm.

Rod Pemberton

n***@gmail.com

2009-02-18 17:05:58 UTC

Post by n***@gmail.com
#include <stdio.h>
#include <time.h>
#define TDIFFMAX 500
int main(void)
{
unsigned long tstart=0;
while(1)
{
if((clock()-tstart)>=TDIFFMAX)
{
tstart+=TDIFFMAX;
printf("%lu\n",tstart);
}
}
return(0);
}

I've spotted a couple of bugs. First, you should be testing for a
minimum -- not a maximum. Second, you should add the real, elapsed
difference -- not the value the difference was test against.

Here are the corrections:

#include <stdio.h>
#include <time.h>

#define TDIFFMIN 500
int main(void)
{
unsigned long tstart=0, tend, tdiff;

while(1)
{
tdiff = clock()-tstart;
if ( tdiff > TDIFFMIN )
{
tstart+=tdiff;
printf("%lu\n",tstart);
}
}
return(0);

}

*Closer* to the original, but still not quite the same output.

Nathan.

Rod Pemberton

2009-02-18 23:28:06 UTC

Post by n***@gmail.com
I've spotted a couple of bugs. First, you should be testing for a
minimum -- not a maximum.

Do you mean you should've been testing for a minimum originally, and not a
maximum?... Well, you'd be wrong.

The comparison of "tdiff > 500" clearly indicates it's a maximum threshold
which when exceeded prints. The computation of "tend = clock(); tdiff =
tend - tstart" with a delayed update to tstart clearly indicates that tdiff
is a increasing value. Therefore comparison with it also checks for a
maximum, not a minimum. I also used an increasing difference, therefore
maximum.

Post by n***@gmail.com
Second, you should add the real, elapsed
difference -- not the value the difference was test against.

I already discussed this. It's non-issue. This is why:

How slow does a process have to be to underflow the resolution of clock()?
The resolution of clock is compiler platform dependent. clock() is
typically in seconds or microseconds but could have any resolution. If
it's in the typical resolutions of seconds or microseconds, you'll need an
unbelievably slow microprocessor. Basically, you'd need one of the first
generation of successful microprocessors, sub 1Mhz...

Post by n***@gmail.com
*Closer* to the original, but still not quite the same output.

The original was flawed, increasing by 505 per display, not 500. clock() is
compiler platform dependent.

Rod Pemberton

n***@gmail.com

2009-02-19 01:34:11 UTC

I've spotted a couple of bugs. First, you should be testing for a
minimum -- not a maximum.

Do you mean you should've been testing for a minimum originally, and not a
maximum?... Well, you'd be wrong.
The comparison of "tdiff > 500" clearly indicates it's a maximum threshold

Mr. Seesky Fraidofheights recently became a multi-trillianare. To
better manage his interplanetary commercial interests, he plans to
move his headquarters to our esteemed city. So that we may choose the
correct building that will house his office, the eccentric moneybags
gives us two rules that must not be broken:

First, the office *MUST* be located on the very top floor of the
building because it must have a large window in the ceiling so he can
watch[verb] the clouds drift by.

Second, he has made some progress in overcoming his fear of heights,
however these calm sensibilities only allow him to reach a *MAXIMUM*
of the 5th floor.

I have located a nice 128-story building. Let us plug this into our
test condition:

Is 128 greater than the MAXIMUM value allowed?

( 128 > 5 ) => true

Therefore, I conclude that Mr. Seesky Fraidofheights will be quite
happy in his new digs! :)

Nathan.

n***@gmail.com

2009-02-19 01:57:19 UTC

Post by n***@gmail.com
*Closer* to the original, but still not quite the same output.

The original was flawed, increasing by 505 per display, not 500. clock() is
compiler platform dependent.

No. The imitation is flawed because it failed to accurately re-create
the output characteristics of the original. If it cannot correctly
reproduce the behavior of the original, then it certainly is incapable
of standing-in as substitute for the original -- no matter how much
better-designed the source code may be.

Nathan.

Rod Pemberton

2009-02-19 10:46:40 UTC

Post by n***@gmail.com
The imitation is flawed because it failed to accurately re-create
the output characteristics of the original.

This presumes:
1) that the intent of the imitation is to accurately recreate the
original.
2) that the intent of the imitation isn't something else of perceived
value, such as to correct, or simplify the original.
3) that the preconditions stated in your sentence above were stated at the
onset in order to select between 1 and 2.

Post by n***@gmail.com
If it cannot correctly
reproduce the behavior of the original, then it certainly is incapable
of standing-in as substitute for the original -- no matter how much
better-designed the source code may be.

This presumes that some "behavior" external to the application is
*dependent* on preserving the original faulty behavior of the application.
To what "behavior" are you referring?

Rod Pemberton

n***@gmail.com

2009-02-19 21:14:17 UTC

Post by n***@gmail.com
The imitation is flawed because it failed to accurately re-create
the output characteristics of the original.

1) that the intent of the imitation is to accurately recreate the
original.

Isn't it a coder's *duty* to comply to the specs?

2) that the intent of the imitation isn't something else of perceived
value, such as to correct, or simplify the original.

Granted, the imitation has value. But this attribute does not
automatically imply that the output of the original code is "not
correct" or otherwise not the intended behavior.

This presumes that some "behavior" external to the application is
*dependent* on preserving the original faulty behavior of the application.
To what "behavior" are you referring?

Since the behavior of the original code is not faulty, then it follows
that "something" external to the imitation/substitute application is
causing it to be perform *dissimilar* to what is expected.

Nathan.

Rod Pemberton

2009-02-20 07:33:19 UTC

Post by n***@gmail.com
Since the behavior of the original code is not faulty,

Says who? You provided nothing in the way of expected output. When I see
the following, am I supposed to assume it's correct? What about when I look
at the code and see it compares to 500, not 505? Am I supposed to assume
it's correct then?

505
1010
1515
2020
2525
3030
...

I don't have lizard vision designed to split these stereo numbers in half...
;) Since clock() is platform dependent, you could be seeing something
completely different, and perhaps it's even accurate.

Rod Pemberton

n***@gmail.com

2009-02-20 09:15:35 UTC

505
1010
1515
2020
2525
3030
...

Is ( 505 - 0 ) greater than 500? Yes. Therefore, the output of "505"
is correct.
Is ( 1010 - 505 ) greater than 500? Yes. Therefore, the output of
"1010" is correct.
Is ( 1515 - 1010 ) greater than 500? Yes. Therefore, the output of
"1515" is correct.
Is ( 2020 - 1515 ) greater than 500? Yes. Therefore, the output of
"2020" is correct.
Is ( 2525 - 2020 ) greater than 500? Yes. Therefore, the output of
"2525" is correct.
Is ( 3030 - 2525 ) greater than 500? Yes. Therefore, the output of
"3030" is correct.

The calculated difference is allowed to be any value at all -- with
the condition that it can be no smaller than the non-inclusive
*minimum* of 500. I thought this would have been obvious by reading
the code. Apparently, I should have commented it liberally. When I
posted the original, I assumed that you, and a few others of this
forum, were capable of reading C code. I see now that I was wrong
about those expectations. Sorry.

I happen to notice that this is the "alt.lang.asm" newsgroup. Does
anyone happen to know if the ".asm" part stands for "assembly
language", perhaps?? Does anyone in here know how to read ASM code?
Would that be a better choice for our code postings?

Nathan.

Nathan.

Rod Pemberton

2009-02-21 08:56:16 UTC

Would [assembly code] be a better choice for our code postings?

Sure. But, why would you ask? No offense intended, but I don't ever recall
you posting x86 assembly code. AFAIR, you've only posted C code... Maybe
you did post assembly sometime. I know it's been quite a while since I've
posted assembly. However, I have responded to assembly posts with assembly,
and to C posts with C.

Rod Pemberton

n***@gmail.com

2009-02-22 03:40:41 UTC

Would [assembly code] be a better choice for our code postings?

It is your poor "bedside manner" that I take issue with. Maybe you
don't realize it, but it appears that your modus operandi is
approximately:

o Whine about Nasm.
o Be caustic toward Nasm supporters.
o Post off-topic.
o Whine about Nasm.
o Be caustic toward Nasm supporters.
o ...

I don't really mind the off-topic content. But I object to the fact
that it comes with a price tag.

Nathan.

Rod Pemberton

2009-02-22 07:02:02 UTC

Post by n***@gmail.com
It is your poor "bedside manner" that I take issue with.

First, you take issue with everything by everyone no matter how silly.
Second, my poor "bedside manner"? Coming from the crap you've said to
people over the years, do you honestly believe you have a right to talk?...
While the blatantly distorted and mispercieved "modus operandi" you posted
about me could apply for about one month worth of posts in regards to NASM.
It doesn't apply to the several years of positive NASM posts by me. And, in
case you haven't noticed, your "modus operandi" over the past few years is:

1) Post something unrelated to anything in the conversation
2) Ignore anything in the conversation, even if it was posted by you
3) Post something else unrelated to anything in the conversation
4) If no one responds, post useless C code
5) If someone respectfully responds to useless C code, whine about others
not posting assembly
6) Insult person when problems in your code or logic are out pointed out to
you
7) Attempt to divert conversion away from your poor code using faulty logic
8) Repeat

You complaining about me reporting about legitimate NASM issues is
ludicrous. As for my "off-topic" posts, the off-topic threads are always
started by someone else, and in quite a few cases that's been by *you*...
So, it's not as ludicrous as an "off-topic" complaint coming from Skybuck,
but it's real close. As I stated before, AFAIR, I've not seen one
"on-topic", or assembly related post by you *ever*. So, until you
contribute something topical, as I have done for years, what right do you
have to complain?

Rod Pemberton

Frank Kotler

2009-02-22 09:54:16 UTC

Rod Pemberton wrote:
[snip]
[snip]

You guys auditioning for the Randy and Betov roles, or what? :)

Best,
Frank

Rod Pemberton

2009-02-22 11:01:36 UTC

Post by s***@yahoo.com
[snip]
[snip]
You guys auditioning for the Randy and Betov roles, or what? :)

Yes. ;)

Well, I know what HLA looks like because it gets posted here occasionally.
How about posting some RosAsm disassembly source (SpAsm) of say a "Hello
World!" program originally coded in NASM so I can see the differences.
Then, I'll decide who I'm auditioning as. :-) Supposedly, SpAsm is
simplified NASM syntax? Is that correct? A simpler version of NASM
syntax?...

Rod Pemberton

Frank Kotler

2009-02-22 20:25:21 UTC

Rod Pemberton wrote:

...

Post by Rod Pemberton
Well, I know what HLA looks like because it gets posted here occasionally.
How about posting some RosAsm disassembly source (SpAsm) of say a "Hello
World!" program originally coded in NASM so I can see the differences.
Then, I'll decide who I'm auditioning as. :-) Supposedly, SpAsm is
simplified NASM syntax? Is that correct? A simpler version of NASM
syntax?...

Betov claims it's "improved". I claim he's completely fucked it up. One
of these days I'll write a "source code extractor" for Linux (shouldn't
be hard), and save trying to pick the text out of executables. The
"correct" way would be just to load the sucker into RosAsm, of course.
This is "base1.exe" - more or less "hello world" (a pretty extensive
one) - but not originally written in Nasm. I *think* that much of it is
"boilerplate" inserted by RosAsm - you wouldn't have to type all this...
(that true, Wolfgang?)

Read it and... well it makes *me* weep...

Best,
Frank

___________________________________________________________________________________________

; Base exemple with standard menu.
;
; Full low level style version.
___________________________________________________________________________________________
___________________________________________________________________________________________
; Data:

[FirstMessage: 0 #7] ; For
"GetMessage"

[WindowClass: ; Window
Class Structure
style: 3 lpfnWndProc: MainWindowProc cbClsExtra: 0 cbWndExtra: 0
hInstance: 0 hIcon: 0 hCursor: 0 hbrBackground: 6
lpszMenuName: 0 lpszClassName: WindowClassName]

[WindowHandle: 0 MenuHandle: 0]

[WindowClassName: B$ 'Anything' 0 WindowCaption: 'Base App' 0]

[WindowX: 50 WindowY: 50 WindowW: 650 WindowH: 450]

___________________________________________________________________________________________

Main:
push 0
call 'Kernel32.GetModuleHandleA'
mov D$hInstance eax

push 1
push D$hInstance
call 'User32.LoadIconA'
mov D$hIcon eax

push &IDC_ARROW
push 0
call 'User32.LoadCursorA'
mov D$hCursor eax

push WindowClass
call 'User32.RegisterClassA'

push M00_Menu
push D$hInstance
call 'User32.LoadMenuA'
mov D$MenuHandle eax

push 0
push D$hInstance
push D$MenuHandle
push 0
push D$WindowH
push D$WindowW
push D$WindowY
push D$WindowX
push &WS_OVERLAPPEDWINDOW__&WS_VISIBLE
push WindowCaption
push WindowClassName
push &WS_EX_CLIENTEDGE
call 'User32.CreateWindowExA'
mov D$WindowHandle eax

push &SW_SHOW
push D$WindowHandle
call 'User32.ShowWindow'

push D$WindowHandle
call 'User32.UpdateWindow'

L1: push 0
push 0
push 0
push FirstMessage

call 'User32.GetMessageA'
cmp eax 0
je L9>

push FirstMessage
call 'User32.TranslateMessage'

push FirstMessage
call 'User32.DispatchMessageA'
jmp L1<

L9: push 0
call 'Kernel32.ExitProcess'

___________________________________________________________________________________________

; These menu equates are given by the menu editor ([ClipBoard]):

[M00_Menu 2000 M00_New 2001
M00_Open 2002
M00_Save 2003 M00_Save_As 2004
M00_Exit 2005
M00_Undo 2006 M00_Cut 2007
M00_Copy 2008
M00_Paste 2009 M00_Delete 2010
M00_Select_All 2011
M00_About 2012]
___________________________________________________________________________________________

MainWindowProc:

push ebp
mov ebp esp

pushad

cmp D$ebp+12 &WM_CLOSE ; test Message:
jne L1>
push D$ebp+8
call 'USER32.DestroyWindow'
jmp L9>>

L1: cmp D$ebp+12 &WM_DESTROY
jne L1>
push 0
call 'User32.PostQuitMessage'
jmp L9>>

L1: cmp D$ebp+12 &WM_COMMAND
jne L1>
cmp D$ebp+16 M00_Exit ; test wParam:
jne L2>
push 0
push 0
push &WM_CLOSE
push D$ebp+8
call 'User32.SendMessageA'
jmp L9>>

L2: cmp D$ebp+16 M00_Menu
jne L2>
; ...
jmp L9>>

L2: cmp D$ebp+16 M00_About
jne L2>
; ...
jmp L9>>

L2: push &MB_OK__&MB_SYSTEMMODAL
push InfoTitle
push InfoString
push 0
call 'USER32.MessageBoxA'
jmp L9>>

L1: popad ; Don't Care default:
push D$ebp+20
push D$ebp+16
push D$ebp+12
push D$ebp+8
call 'User32.DefWindowProcA'
mov esp ebp
pop ebp
ret 16

L9: popad ; Normal exit:
mov eax &FALSE
mov esp ebp
pop ebp
ret 16

[InfoString: "
This file is not a Demo. It is a 'StartUp'
Base you can use to develop your own work. ", 0

InfoTitle: 'Application Base', 0]

______________________________________________________________________________________

; little message routine for values tests (dWords only) to be called with:
; > Hexprint D$esi, for exemple:

[HexprintString: B$ ' h' 0
MessageTitle: 'HihoHiho' 0
argh: 'AAAaarrrgh!...', 0]

HexPrn:
mov ebx eax
mov edi HexPrintString
add edi 7
std
mov ecx 8
L1: mov al bl
and al 0F
cmp al 0A
jb L2>
add al 7
L2: add al '0'
stosb
shr ebx 4
loop L1<
cld
push &MB_OK__&MB_SYSTEMMODAL
push MessageTitle
push HexPrintString
push 0
call 'USER32.MessageBoxA'
ret

[HexPrint
pushad
push #1
pop eax
call hexprn
popad]

[ShowMe
pushad
push &MB_OK__&MB_SYSTEMMODAL
push argh
push #1
push 0
call 'USER32.MessageBoxA'
popad]

; To be used, for exemple, as:
;
; Hexprint D$esi
;
; Showme MessageTitle
;
; Avoid using inside the Message loop (MainWindowProc); Win doesn't
always like...
_______________________________________________________________________________________

Rod Pemberton

2009-02-23 09:22:55 UTC

Post by Rod Pemberton
Supposedly, SpAsm is
simplified NASM syntax?

Betov claims it's "improved". I claim he's completely fucked it up.

:-)

Post by Frank Kotler
Read it and... well it makes *me* weep...

[Windows junk...]

Post by Frank Kotler
push 0
call 'Kernel32.GetModuleHandleA'

I'm not familiar with Windows, is eax the return?

Post by Frank Kotler
mov D$hInstance eax

I.e., is this moving D$hInstance to eax, or eax into D$hInstance? Without
the "visual impediment" of a comma or percent, I *really* thought it was
AT&T order...

Post by Frank Kotler
call 'User32.LoadIconA'
mov D$hIcon eax

Ok, I've seen hInstance, hIcon, like text in Windows code, so I'll assume
these are Windows types. I'll take it the D$ it's "Betovsian" for "dword".

Post by Frank Kotler
push &IDC_ARROW

Not sure what the & is for, but I'll could guess it's an address operator
like C. Or, from other snipped code that was further down, perhaps it's a
bit field or a flag value.

Post by Frank Kotler
call 'User32.LoadCursorA'

The names of Windows functions are obviously quoted.

Post by Frank Kotler
push M00_Menu

Ok, another strange one...

Post by Frank Kotler
cmp eax 0

Odd, the code above seemed "register reversed". This isn't. It is also
missing comma's.

Post by Frank Kotler
je L9>

Not sure what the '>" on L9 could be for...

Post by Frank Kotler
jmp L1<

Not sure what the '<" on L1 could be for...
Ok, he lost the brackets for memory references, yes? Hmm, I thought that
caused some instruction conflicts...

Post by Frank Kotler
jmp L9>>

Now what is '>>' ? Is this some form of nesting?

Post by Frank Kotler
L2: cmp D$ebp+16 M00_Menu

Still not sure what the Moo is all about... Value in memory?

Post by Frank Kotler
[HexprintString: B$ ' h' 0

B$ is byte...

Post by Frank Kotler
[HexPrint
pushad
push #1
pop eax
call hexprn
popad]

What is he using the brackets for? Macro's? Odd...

We'll, it's not too bad. So, maybe I'll be auditioning as Betov... ;) It
won't work with C as HLA would with some changes. But, in terms of
assembler syntaxes, it doesn't seem too bad.

I would've kept NASM's brackets for memory references since some
instructions could be confusing without. I would've also kept the comma's
between arguments on instructions, since I thought it was AT&T register
order at first.

I guess the D$, B$ stuff works for the most part, but, IIRC, there are a
handful of x86 instructions that have two and three different sizes. What
does he do then? It's the esoteric cases that disproves things. How about
prefixes?

I'm not sure what the stuff, e.g., '<', '>>' etc. on the branches and jumps
are. Hints to direction? Nesting level? Locality? If you have a
numerically based branch label, what's that stuff for? You know exactly
where the branch location is and there are no label name conflicts.

Throughout most of that code it seems that constants are in decimal. The
few hex values seem to use '0' to indicate hex. I don't like that. I'd
rather see '0x' prepended or less preferred 'h' appended with/without a
prepended '0'. Unfortunately, '0' without the 'h' is octal to me...

What does the '#' in the 'push #1' indicate? An instruction with an
immediate byte value, instead of word or dword? Shouldn't that be 'push
B$1'... ? Why the switch in syntax? Or, doesn't B$, D$, etc. work with
constants?

Post by Frank Kotler
I claim he's completely fucked it up.

I clearly prefer NASM. I see zero reasons why he couldn't have used
straight NASM syntax. But, that didn't seem to bad to understand.
Honestly, Herbert's Windela was much more confusing. It's not as cryptic
appearing as the stuff "rio" posts although SpAsm is clearly using textual
symbols more like C or BASIC. Although, some of the "decoration" of SpAsm
is cryptic at this point in time. It didn't have any "STUPID words in
STUPID places for STUPID reasons", although it definately has some oddly
located "decoration" which might qualify... But, the syntactic "decoration"
is nowhere near as bad as GNU GAS... Perhaps, this is because SpAsm was
NASM based...

Rod Pemberton

Wolfgang Kern

2009-02-23 16:21:39 UTC

...

Post by Rod Pemberton
Well, I know what HLA looks like because it gets posted here

occasionally.

Post by Rod Pemberton
How about posting some RosAsm disassembly source (SpAsm) of say a "Hello
World!" program originally coded in NASM so I can see the differences.
Then, I'll decide who I'm auditioning as. :-) Supposedly, SpAsm is
simplified NASM syntax? Is that correct? A simpler version of NASM
syntax?...

Only true if you copy paste or modify an existing example (as usual),
so if I start a new PE in RosAsm I first wipe everthing offered like
standard menus and macros, because I have my own ideas for this.

Post by Frank Kotler
Read it and... well it makes *me* weep...

after using it you may get familar with the 'fucked up sizecast' :)
Rod misses the colon between source/destination ?
we can just put it in without any troubles.

[known source snip..]

__
wolfgang

n***@gmail.com

2009-02-22 21:57:38 UTC

Post by s***@yahoo.com
[snip]
You guys auditioning for the Randy and Betov roles, or what? :)

I thought we were satiating "cabin fever" effects by chatting about
common interests. It is obvious that we had found some. Since I am
open-minded and enjoy learning new things, I am eager to explore and
analyze those subjects. It is not uncommon that friends urge one
another to "step outside" their normal experience. I attempt this by
questioning people's pre-conceptions and calling them on their obvious
logical fallacies.

Nathan.

Rod Pemberton

2009-02-22 09:37:58 UTC

Post by n***@gmail.com
But I object to the fact
that it [off-topic] comes with a price tag.

I was just thinking about that. Can you name one semi-regular poster who
hasn't been involved in a non-assembly post? Honestly, I can't think of
one. Terence has been involved in a few. I then about thought Frank, but
then I recalled a few. Then, rio, but no him too. Then Chuck, Wolfgang,
Herbert, Steve, yes, them too. Betov, Randal, hutch--, fodder, Skybuck,
yes. So, who here is it that you're referring to that is posting without "a
price tag"?... If no one here is posting without "a price tag" and you
"object to .. it" 1) why do you continue to read here and 2) why did you
choose to single me out in your complaint when there are so many others?

Rod Pemberton

n***@gmail.com

2009-02-22 17:36:44 UTC

Post by n***@gmail.com
But I object to the fact
that it [off-topic] comes with a price tag.

Wow! You totally missed the point!

Nathan.

n***@gmail.com

2009-02-23 04:59:08 UTC

Post by Rod Pemberton
why did you
choose to single me out in your complaint when there are so many others?

I guess it is a difference of perspective. "Can't see the forest for
the trees," or the thread for the posts.

You probably feel "singled out" because I have shown you at least two
acts of kindness in this thread.

First, I urged my fellow readers to give you the "benefit of the
doubt" by offering an alternative interpretation for what seemed {you
have yet to confirm either way} to be an un-called-for "slight" on
your part.

Second, because you complained about unhappy conditions in the c.l.c
group, I encouraged talk about the C language to give you *some*
indication that I "understood" your desire [ ...if a friend needs a
place to "lick his wounds" before going back to battle... ]. As I
understand it, life is not always a "bed of roses." "If it gives you
lemons, make lemonade!"

When a person gets "our" age, we've gotta keep an eye on the big
picture... "tripping on small stuff" is for the young'ns! :)

Nathan.

rio

2009-02-22 10:54:05 UTC

Post by n***@gmail.com
Since the behavior of the original code is not faulty,

they have all 505 in them

Post by Rod Pemberton
I don't have lizard vision designed to split these stereo numbers in half...
;) Since clock() is platform dependent, you could be seeing something
completely different, and perhaps it's even accurate.
Rod Pemberton

rio

2009-02-22 10:54:15 UTC

Post by Rod Pemberton
If you're looking for ways to waste time,

It appears as though this is becoming a C forum. So I guess I could
,---
| waste.c
,---
#include <stdio.h>
#include <time.h>
int main( void )
{
long tstart, tend, tdiff;
tstart = clock();
tend = clock();
tdiff = tend - tstart;
if ( tdiff > 500 )
{
printf( "%d\n", tend );
tstart = clock();
}
goto mylabel;
}

i not have understood much above, i print tdiff
i think it is for see if the variable tdiff is stable
(have always or nearly always the same value)

--------------------------------------------------
section _DATA use32 public class=DATA

global _main
extern GetTickCount
extern _printf

tstart dd 0, 0
tend dd 0, 0
time1 dd 0, 0
"%x \n" db "%x "
nl db 13, 10, 0, 0

section _TEXT use32 public class=CODE

_main:
RDTSC
*tstart=a|*tstart+4=r
*time1 =a|*time1 +4=r
.a0: RDTSC
*tend=a|r!=*tstart+4#.f
r =a|r-=*time1|r>9000000#.f
r =a|r-=*tstart
r>500!#.a0|_printf<("%x \n", r)
|RDTSC|*tstart=a|*tstart+4=r
|#.a0

.f: _printf<(nl)
a^=a
ret
------------------------------------------------
section _DATA use32 public class=DATA

global _main
extern GetTickCount
extern _printf

tstart dd 0, 0
tend dd 0, 0
time1 dd 0, 0
IIxIIIn db "%x "
nl db 13, 10, 0, 0

section _TEXT use32 public class=CODE

_main:
RDTSC
mov [tstart], eax
mov [tstart+4], edx
mov [time1], eax
mov [time1+4], edx
.a0: RDTSC
mov [tend], eax
cmp edx, [tstart+4]
jne .f
mov edx, eax
sub edx, [time1]
cmp edx, 9000000
ja .f
mov edx, eax
sub edx, [tstart]
cmp edx, 500
jbe .a0
push edx
push IIxIIIn
call _printf
add esp, 8

RDTSC
mov [tstart], eax
mov [tstart+4], edx

jmp short .a0

.f: push nl
call _printf
add esp, 4
xor eax, eax
ret

----------------------------------------
24c
2d8
268
24c
24c
24c
24c
24c
24c
24c
2a0
276
24c
24c
24c
24c
24c
24c
24c
268
276
24c
24c
24c
24c
24c
24c

rio

2009-02-24 18:07:41 UTC

i find one error

section _DATA use32 public class=DATA

global _main
extern _printf

tstart dd 0, 0
tend dd 0, 0
time1 dd 0, 0
"%x \n" db "%x "
nl db 13, 10, 0, 0

section _TEXT use32 public class=CODE

_main:
RDTSC
*tstart=a|*tstart+4=r
*time1 =a|*time1 +4=r
.a0: RDTSC
*tend=a|r!=*time1+4#.f
r =a|r-=*time1|r>10000000#.f
r =a|r-=*tstart
r>01FFh!#.a0|_printf<("%x \n", r)
|RDTSC|*tstart=a|*tstart+4=r
|#.a0

.f: _printf<(nl)
a^=a
ret

--------------------------------------
section _DATA use32 public class=DATA

global _main
extern GetTickCount
extern _printf

tstart dd 0, 0
tend dd 0, 0
time1 dd 0, 0
IIxIIIn db "%x "
nl db 13, 10, 0, 0

section _TEXT use32 public class=CODE

_main:
RDTSC
mov [tstart], eax
mov [tstart+4], edx
mov [time1], eax
mov [time1+4], edx
.a0: RDTSC
mov [tend], eax
cmp edx, [time1+4]
jne .f
mov edx, eax
sub edx, [time1]
cmp edx, 10000000
ja .f
mov edx, eax
sub edx, [tstart]
cmp edx, 01FFh
jbe .a0
push edx
push IIxIIIn
call _printf
add esp, 8

RDTSC
mov [tstart], eax
mov [tstart+4], edx

jmp short .a0

.f: push nl
call _printf
add esp, 4
xor eax, eax
ret

Terence

2009-02-25 01:16:37 UTC

Sorry about the bad news about Chuck Crayne.
Now I see why the moderation was not happening recently, that caused
my posting at the top..
Don't know what Jim wants to do, but it WAS getting hard to find
the .ASM postings among the spam, so the group really does needs a
moderator.

rio

2009-02-25 08:01:06 UTC

Post by Terence
Sorry about the bad news about Chuck Crayne.
Now I see why the moderation was not happening recently, that caused
my posting at the top..
Don't know what Jim wants to do, but it WAS getting hard to find
the .ASM postings among the spam, so the group really does needs a
moderator.

my opinion count for nothing i'm an extremist not on the average
opinion

i like NGs like alt.lang.asm
if you need of a moderator: the first moderator is who read.
if there are 100 post, i read only the ones that i like
i should say that i like to read OT too [because is not all asm
and some time it is useful to know what programmers think]

i like comp.lang.asm.x86 too, and i know if i post there, i have
to write without OTs, cross post, etc.
yes if you search only assembly language post, comp.lang.asm.x86
is faster for read [at last seems to me so]

rio

2009-03-07 18:41:10 UTC

Post by rio

my opinion count for nothing i'm an extremist not on the average
opinion
i like NGs like alt.lang.asm
if you need of a moderator: the first moderator is who read.
if there are 100 post, i read only the ones that i like
i should say that i like to read OT too [because is not all asm
and some time it is useful to know what programmers think]
i like comp.lang.asm.x86 too, and i know if i post there, i have
to write without OTs, cross post, etc.
yes if you search only assembly language post, comp.lang.asm.x86
is faster for read [at last seems to me so]

and one not has to read the post of troll (the ones that the only thing
they can do is insult other people) or the posts of persons that
one not like what they say

Steve

2009-02-17 13:13:06 UTC

<Snip>

Post by Rod Pemberton
1) Google Groups (Seems to get pick up almost everything, even from the
remotest junk servers.)
2) textnews.cambrium.nl (I've only seen a very few posts not make it here.)
3) www.aioe.org or nntp.aioe.org (Was good before their last hardware
and/or ISP shutdown issues.)
None of them require authentication. I've noticed that although AIOE is
back online, it's not carrying alt.lang.asm for read... Or, at least, I'm
not getting any messages to read for a.l.a when I connect. Maybe I need to
purge my messages so it resynchonizes. But, AIOE does post messages to
a.l.a.

I'm using AIOE, and see alt.lang.asm just fine. Some other
groups required a synch.

Steve N.

Rod Pemberton

2009-02-17 23:22:57 UTC

Post by Steve

Post by Rod Pemberton
3) www.aioe.org or nntp.aioe.org (Was good before their last hardware
and/or ISP shutdown issues.)

I'm using AIOE, and see alt.lang.asm just fine. Some other
groups required a synch.

Well, for both aioe sites, alt.os.development continued receiving "new"
messages (post hardware/ISP problems) where it left off, but alt.lang.asm
didn't and doesn't for me. I just checked again. Something must've got out
of synch on their end. I saw something similar with an OpenWatcom newsgroup
some time ago. Their server reset message numbers, below what they were at
pre-crash. Anyway, I had to unsubscribe thereby loosing the "old" messages
and headers and resubscribe to alt.lang.asm to get the "new" messages and
headers...

Rod Pemberton

Frank Kotler

2009-02-19 05:22:21 UTC

Rod Pemberton wrote:

...

Post by Rod Pemberton
None of them require authentication. I've noticed that although AIOE is
back online, it's not carrying alt.lang.asm for read...

Oh, yeah! They're back! Working okay for me. I'd given up and quit
trying them. Thanks for the tip.

...

Post by fbkotler
... roommate ... he ...

Roomate? He? :-o
Sigh... There's only a few situations I know of where you'd have a male
roommate, and most of them are (usually considered) undesirable. :-D Think
about it...

Okay, I'm thinking about it... Is this implied fag-bashing? I'd have
expected better of you.

Actually, I have two male roommates. I'm a polygamous faggot! Perhaps it
would inflame less purient interest if I'd said "housemate" - we don't
actually share a bed. They give me a good deal of help around the place
- cutting, splitting, lugging wood, keeping the driveway plowed, etc.
Seems quite desirable to me. If I in fact had a male roommate, bedmate,
lover, spouse (where it's legal), "domestic partner", whatever, I assume
I would find that desirable, also. They love each other, y'know. ("Just
like your woman loves you" - Andy Pratt)

I'm a little "sensitive" to fag-bashing. Back in '65 or '66 I told my
Draft Board I was "a queer" ("gay" mostly meant "cheerful" in those
days)... and like the song says, "they all moved away from me on the
Group W bench". Got me to thinking... if *you* want to sleep with me,
you can care whether I sleep with men or women. If you *don't* want to
sleep with me, why should you care who I sleep with? "Think about it."

Perhaps that's not what you were getting at. I *knew* I could expect
better of ya!

FWIW, his password didn't get me into Giganews... I appreciate the free
servers. Wouldn't kill me to pay for it. But when I signed up for this
deal, I *was* paying for it! Seems almost fraudulent to pull services
I'm paying for. I guess the fine print allows them to change the rules
if they want to. I'm not sure if Fairpoint is being fraudulent or just
hasn't got their shit together... yet(? one may hope)... They don't seem
very competent.

Post by Rod Pemberton
Ok, I'll humor you. What's the smallest set of general (i.e., no fpu,

Post by Rod Pemberton
SSE, no XMM, etc) x86 assembly instructions needed to program general

x86

Post by Rod Pemberton
assembly? There, that's asm related... Yes? Is it lodsb, stosb, push,
pop, xchg, loop, jcxz and arithmetic instructions? Or, can you think up

any

Post by Rod Pemberton
other use for "rep lodsb" other than that posted by Jim Leonard on
comp.lang.asm.x86 recently?

I've seen just "lodsb" used as a replacement for "inc esi" (Fasm code
uses it, IIRC)... Does that count?

The only thing other than for string use that I've used "lodsb" for was with
"xchg" for space: 2 byte register loads with lodsb/w to al/ax, xchg to move
to other register.

That's a good one. I'm thinking I may have misremembered what I saw in
the Fasm code - probably "lodsd" - I remember it was shorter, and the
load wasn't used...

Post by fbkotler
Why isn't this killing the "quote"? Didn't want it to, but expected it
to... Maybe my newsreader's broken...

Sorry, didn't know it was supposed to... Is it?

Well, I thought so... "--" on a line by itself designates the start of
the "signature", and anything after it isn't included in the "quote". I
may be thinking of FidoNet... Isn't working like that, in any case...

Post by Rod Pemberton
Well, I haven't seen a post here from the "KKK" in a while (Kotler,
Kleebauer, or Kern).

Hadn't thought of us quite that way. :)

:-) Hopefully, no undeserved negative connotations will stick. I just
noticed a bunch of lastnames with K... Thought it'd be funny.

Agreed.

Post by fbkotler
I'm still around. I think
Herbert's still with us. I fear Wolfgang may have "gone missing".

Yeah. Herbert's checked in with a one-instruction example. People come
and go, as you say, but I can't help worrying about the folks who drop
out of "sight"... I can't *believe* Beth left without saying goodbye...
at length. :)

Post by fbkotler
I read a review from one of Randy's former students - claimed he was
lacking in social skills.

*I'm* lacking in social skills...

Well, if *I* had any social skills, I suppose I'd be living with twin
blonds about eighteen instead of a couple guys. I didn't say it couldn't
be *more* desirable! (the gals that can carry their weight in firewood
scare me though...)

Post by fbkotler
I'll try to get back to ya on that "Nasm philosophy" question

You didn't post a Nasm philosophy question here, but I recall that you
used the phrase on the bugtracker. I suggested that we might discuss
Nasm philosophy, and you said "nothing bad, I hope". No nothing bad, I
just thought we could kick it around a bit. If I misremember... we can
still kick it around... if anyone wants to. I recall you saying
something like:

"No STUPID words in STUPID places!"

I like that idea, but Nasm hasn't done terribly well at it. As of 0.98,
you had to say "push word 3" or "push dword 3". Shortly thereafter, it
was decided that defaulting to the "default bitness" was a reasonable
thing to do. Still have to say "push dword [eax]" though...

I think your complaint was about "mov rax, [mem]" having to say "mov
rax, qword [mem]" if "mem" is to be taken as 64 bits. I *think* you
wanted "mov rax, [mem]" to emit the 32-bit form if "mem" would fit in 32
bits, and "automatically" use the 64-bit form if it wouldn't (I may have
this wrong).

That seems reasonable to me, and I wouldn't object to it. But it could
be considered analogous to "jcc target" - if "target" is more than 128
bytes away, you have to say "jcc near target" - or use the "-O" switch
to give Nasm "permission" to change it. So while you may be right to
gripe about "qword" being required, it's pretty much "the way Nasm's
always worked". Actually, I guess the "Nasm way" would give you the long
form, unless you said "dword" or used "-O" - as it does for "jmp" or the
various instructions with "signed byte" forms. I understand (not
familiar with 64-bit code) that the 32-bit form is what's "usually"
wanted, so this break from "default to long form" may be warranted.

Another exposition of the "Nasm philosophy" might be from the Friendly
Manual:

"So here, for your coding pleasure, is NASM. At present it's still in
prototype stage - we don't promise that it can outperform any of
these assemblers. But please, _please_ send us bug reports, fixes,
helpful information, and anything else you can get your hands on
(and thanks to the many people who've done this already! You all
know who you are), and we'll improve it out of all recognition.
Again."

This hasn't always been true... and I guess it's not true now if the
developers disagree with ya. But other than the times when Nasm has been
"placed in a medically induced coma" (aka "dead"), the development team
("people come and go") has done a pretty good job of keeping Nasm
debugged and responsive to user needs. Can't please all the people all
the time, of course. Nasm is *still* in a prototype stage - "macho64" is
languishing for lack of a maintainer, for example. A new (old) bug just
turned up on c.l.a.x. - presumably there are more And we probably don't
*want* it improved out of *all* recognition...

My own take on the "Nasm philosophy" would be something like:

"Nasm does exactly what you tell it. The corollary to this is that you
must tell Nasm exactly what you want."

In other words, "extra" keywords are better than erroneous ASSumptions.
Nasm does pretty well at this, IMO...

When it comes to Ndisasm... Nasm's red-headed step-child... it could
certainly be better. I think Ndisasm was kind of a throwaway - "while
we're at it, lets do a disassembler, too!" It has never been a
particularly "virtuous" disassembler. The current development team seems
to be paying a little more attention to it, so it might become more to
your taste as time goes by. Impossible to do a perfect disassembly in
all cases, but Ndisasm *could* be taught about headers for MZ, PE, ELF,
macho, I suppose... An interactive front-end would be nice, too.
"Portable" would be nice, but probably impossible... highly impractical,
at least. I don't anticipate any eagerness to maintain such a beast, so
don't expect much...

There are other disassemblers. One I recently discovered (it only
recently learned Nasm syntax) is Agner Fog's "objconv":

http://www.agner.org/optimize/#objconv

It even interjects comments where your code could be improved! (doesn't
catch dumb algorithms, AFAIK). As the name implies, it has utility
beyond just a disassembler - "-fnasm" is the only thing I've used.

Post by fbkotler
Just haven't been "in the mood" lately...

Coming out of the "winter blues" here too... Yeah, it was the end of
another long, cold one here,

Maybe it's the "winter blues". In the summer, I figure I should be out
puttering around instead of sitting in front of the computer. Now, I'm
sitting in front of the computer anyway, but I seem to be mostly in
read-only mode. Getting behind in my personal email, too. (for some
reason, the "techie talk" seems come easier than "blablabla how are the
kids"...)

We were just beginning to see a little bare ground... but now it's
snowing again (after about a three week break - not bad). Hunker down
and tolerate it for a while longer, I guess...

Post by Rod Pemberton
at same time parts of OZ were ablaze. Did you
see the videos of OZ's firestorms? Unreal!

Frightening!!! Not one of the species we've got around here, but I guess
Eucalyptus burns pretty good! (biofuel???) Makes you realize how much
we're at the mercy of weather. Not enough rain, or too much - disaster!
At least tornados are pretty rare around here (not completely unheard of)!

Post by Rod Pemberton
(I've been using AU for OZ, but
noticed the media uses AU for African Union... I probably PO'd all of
Africa in some old post!)

Serves 'em right for stealing Astronomical Unit for their name! When I
first heard "OZ" for Australia, I thought it was a regional affectation,
but it seems to have become common usage.

Post by Rod Pemberton
Fortunately, other areas of the US that don't
usually get severe winters got blasted pretty hard too! That warms the
heart a bit and provides a small tear of perverse joy. :)

Well... I'll admit to a little glee, seeing other people "get it" -
mostly glad it's not happening here - but a lot of sympathy, too. When I
saw the recent ice storm in Kentucky and thereabouts, it reminded me of
the ice storm we had back in December... Gets to be a drag, hauling
water from the creek to flush toilets when the power goes out! And we're
near a stream! Power's flickering a little now - not enough to knock the
computer down. I'll send this before it does...

Best,
Frank

Rod Pemberton

2009-02-19 10:46:26 UTC

Post by Frank Kotler
I can't *believe* Beth left without saying goodbye...
at length. :)

Seems Beth sure made an impression around here.

(I'll assume from female "nom dep plume" it's _actually_ a she... Given my
experience, a female in any mathematics, computer science, or engineering
related environment - like this one - is unfortunately an astronomical
improbability despite my intense desire for the opposite.)

Post by Frank Kotler
"No STUPID words in STUPID places!"

No STUPID words in STUPID places for STUPID reasons, IIRC...

Post by Frank Kotler
I like that idea, but Nasm hasn't done terribly well at it. As of 0.98,
you had to say "push word 3" or "push dword 3". Shortly thereafter, it
was decided that defaulting to the "default bitness" was a reasonable
thing to do. Still have to say "push dword [eax]" though...
I think your complaint was about "mov rax, [mem]" having to say "mov
rax, qword [mem]" if "mem" is to be taken as 64 bits. I *think* you
wanted "mov rax, [mem]" to emit the 32-bit form if "mem" would fit in 32
bits, and "automatically" use the 64-bit form if it wouldn't (I may have
this wrong).
That seems reasonable to me, and I wouldn't object to it. But it could
be considered analogous to "jcc target" - if "target" is more than 128
bytes away, you have to say "jcc near target" - or use the "-O" switch
to give Nasm "permission" to change it. So while you may be right to
gripe about "qword" being required, it's pretty much "the way Nasm's
always worked".

Well, that's not so, IIRC, the opposite is currently true. IIRC, I made
that point there too. Some instructions are "demoted" to special forms,
usually AX based. No special keyword is needed to tell NASM to use the
special, usually smaller in size, AX forms. If I accept the "it's in there"
reasoning for using "qword", why didn't NASM have say, "use_AX", to force
use of the AX form? I believe in the compiler doing what I tell it to do.
But, if I tell the NASM to use an instruction, which has an AX form, it'll
automatically ASSume I want the AX form. So, why can't NASM "promote" to
special forms without qualifiers, when sufficient information is present?
Personally, I suspect this "ideology" was lost over time due to changes in
those involved in the project. You can always override to a specific form
using a qualifier.

Post by Frank Kotler
Actually, I guess the "Nasm way" would give you the long
form, unless you said "dword" or used "-O" - as it does for "jmp" or the
various instructions with "signed byte" forms. I understand (not
familiar with 64-bit code) that the 32-bit form is what's "usually"
wanted, so this break from "default to long form" may be warranted.

Well, I haven't read up fully on 64-bits. But, it seems both a 32-bit form
and a 64-bit form would be preferred. That's not a conflict. It is
apparently dependent on the cpu mode being used. As I minimally understand
things - which might be wrong at this point in time, there are basically two
64-bit modes. One is pure 64-bit. The other is 64-bit but allows execution
of 32-bit code. In the later, 32-bit offsets would be preferred. In the
pure 64-bit, you'd want as many pure 64-bit instructions as the cpu allows.
Someone else pointed out that certain binary models in the SysV ABI also
uses 64-bit offsets, not 32-bit...

Post by Frank Kotler
This hasn't always been true... and I guess it's not true now if the
developers disagree with ya. But other than the times when Nasm has been
"placed in a medically induced coma" (aka "dead"), the development team
("people come and go") has done a pretty good job of keeping Nasm
debugged and responsive to user needs. Can't please all the people all
the time, of course. Nasm is *still* in a prototype stage - "macho64" is
languishing for lack of a maintainer, for example. A new (old) bug just
turned up on c.l.a.x. - presumably there are more And we probably don't
*want* it improved out of *all* recognition...

Well, I'm still using NASM. Mostly the 0.98.39 version, since I mainly use
it 16-bit code and testing trivial 32-bit sequences. But, I do have some
32-bit code and will likely need some 64-bit code. Most of the 32-bit
assembly I do is inlined in C, i.e., GAS for DJGPP and internal assembler
(primitive version of WASM) for OpenWatcom. For my own in progress C
compiler, I'm considering (once it's more developed) moving away from using
NASM since I can probably just emit the binary for the handful of
instructions I need. I've also been considering "compiling" for an
interpreter so I don't have to recompile the majority of my code, which
isn't performance critical, in the future.

Post by Frank Kotler
"Nasm does exactly what you tell it. The corollary to this is that you
must tell Nasm exactly what you want."

I'd probably put that 2nd:

1) No STUPID words in STUPID places for STUPID reasons.
2) Do what I tell you to do. Do no harm. Don't "think" for me. Don't
optimize without my permission. Don't make assumptions for me.
3) Assemble and disassemble identically. 1:1, if and where possible. If
duplicate encodings are available, different syntax is needed.
4) Hexadecimal. Unsigned hex is effective for encoding both numbers and
specific bit patterns.

Of course, you could point out logical conflicts exceptions, especially to
3, but they are prioritized... I suspect the "demotion" or "promotion" of
one instruction to another encodable form falls under the "do no harm" part
of 2 as a slight exception to the other parts of 2. I suspect inserting
overrides automatically would be the same. Of course, a number of my recent
complaints involved perceived or real issues with 3 and 4.

Post by Frank Kotler
In other words, "extra" keywords are better than erroneous ASSumptions.
Nasm does pretty well at this, IMO...

Yes, and no. The use of brackets for memory access eliminates many of the
"extra" keywords of other assemblers, but of course requires keywords in
other places. Fortunately, these are easy to determine. But, there are
situations where NASM choses "ASSumptions" over "extra" keywords. Overrides
are automatically inserted. It's an assumption, but everyone likes this.
No one wants to read "o32 blah ax" in 16-bit code instead of "blah eax" even
though "o32 blah ax" is technically correct for 16-bit code and "blah eax"
is technically correct only for 32-bit code. But, NASM doesn't
automatically insert overrides for all possible instructions. So, "extra"
keywords for overrides aren't "better" than "erroneous ASSumptions" in the
NASM philosophy when it comes to overrides... The problem is that for every
example you or I find, there is a counter example in NASM where they chose a
differing philosophy either out of praticality, necessity, or prior
established usage.

Post by Frank Kotler
When it comes to Ndisasm... Nasm's red-headed step-child... it could
certainly be better.

Well, I haven't looked at the NASM code much. What I did look at was far
from pleasant to view or attempt to understand... And, I got the impression
the insns.dat file wasn't being used for NDISASM too. It might be, but I
got the impression it wasn't. If it isn't, I'd think someone would want
that file to provide all the rules for both encoding and decoding so as to
not have to duplicate the work "in reverse" for NDISASM. Hint?...

Post by Frank Kotler
I think Ndisasm was kind of a throwaway - "while
we're at it, lets do a disassembler, too!"

I did some work on 2ASM (486dis_c.zip) which is GPL'd. I basically
converted it to NDISASM output. I found it very easy to modify. But, it is
a table driven disassembler. So, it'd probably have problems if someone
tried to extend it for use instructions sequences that reuse 0xF2, 0xF3,
0x66 prefixes as part of the instruction sequence (SSE? MMX?...) So, it's
probably not a good choice to replace NDISASM. I didn't manage to
completely mimick NASM. I was having problems with the code for overrides.
Specifically I had problems with mimicking NASM's way of disassembling
overrides, either override prefix, or changing the register or operand
size - but NASM doesn't change the size on all instructions, just many
instructions... So, one tweak would get say 30% correct, another tweak
would loose the first 30% but get the other 30% correct... This is part of
NASM's selective automatic emitting of overrides for some, but not all
apparently, instructions. I didn't check the fpu instructions. There are
no advanced, SSE, MMX, etc. instructions or 64-bit instructions.

Post by Frank Kotler
Ndisasm *could* be taught about headers for MZ, PE, ELF,
macho, I suppose...

The executable file headers are of no concern to me. I know where they are
for the types I'm using and how to skip over them. I can roll my own header
code if needed. I'm more concerned with correct disassembly and equivalent
reassembly of instruction sequences, the assembler doing what I tell it
instead of "thinking" or assuming or optimizing something for me and thereby
introducing a possible bug, the compiler "thinking" I need something
optimized, simple clean syntax, full support for (unsigned) hexadecimal for
encoding binary wherever values, constants, offsets, or any other bits and
bytes are at the programmers discretion.

Post by Frank Kotler
There are other disassemblers. One I recently discovered (it only
http://www.agner.org/optimize/#objconv
It even interjects comments where your code could be improved! (doesn't
catch dumb algorithms, AFAIK). As the name implies, it has utility
beyond just a disassembler - "-fnasm" is the only thing I've used.

Ok.

In general for DJGPP (GCC/GAS) if I need assembly, I'll use GCC -S instead
of objdump. There is too much lost information from disassembly of an
object versus the assembly emitted by the compiler. OpenWatcom doesn't
produce intermediate assembly at all. So, I had to use OpenWatcom's WDIS
(?) a few times. If I need to disassemble an executable or object, I'll
disassemble the code with NDISASM.

Rod Pemberton

n***@gmail.com

2009-02-22 02:31:52 UTC

Post by Frank Kotler
Well, I thought so... "--" on a line by itself designates the start of
the "signature", and anything after it isn't included in the "quote". I
may be thinking of FidoNet... Isn't working like that, in any case...

I think it needs to be followed by a non-printing character... like a
space.

I noticed that, last year, HPA mentioned applying for Google Summer of
Code(tm) help. Chuck objected that there wasn't enough time to
prepare. Well, it has been about a year and SoC2009 is just around
the corner. Perhaps a student or two would like to implement some of
the features (drawing a line that isn't a series of pixels, far jump
sans segreg, allowing the same label to point at two {or more}
locations, etc.) that potential users have been demanding lately?

Post by Frank Kotler
all cases, but Ndisasm *could* be taught about headers for MZ, PE, ELF,
macho, I suppose... An interactive front-end would be nice, too.

I've looked into this a bit. I'm leaning toward a front-end... one
types "nand myexec" and it calls ndisasm with the appropriate
parameters. ( Nasm Automatic Nice Disassembler ) Of course, it would
first display the sections and inquire which to display. Data
sections could be shown as hex/ASCII.

Post by Frank Kotler
"Portable" would be nice, but probably impossible... highly impractical,
at least. I don't anticipate any eagerness to maintain such a beast, so
don't expect much...

You must be thinking GUI?? Well, Nasm's source tarball already
contains Perl scrips and such -- I don't see why something like tcl/tk
or fltk would be hard to swallow. If it is, then C & Xlib (would be a
bit painful, but doable) would cover all the *nix platforms and just
require cygwin & Xming for Windows if one doesn't want to cross-
maintain Win32 API.

Post by Frank Kotler
Well... I'll admit to a little glee, seeing other people "get it" -
mostly glad it's not happening here - but a lot of sympathy, too. When I
saw the recent ice storm in Kentucky and thereabouts, it reminded me of
the ice storm we had back in December... Gets to be a drag, hauling
water from the creek to flush toilets when the power goes out! And we're
near a stream! Power's flickering a little now - not enough to knock the
computer down. I'll send this before it does...

We are *SO PAMPERED* by modern technology! hehe..

Nathan.

Wolfgang Kern

2009-02-21 16:46:05 UTC

Re: move this Forum somewhere else?

Post by Rod Pemberton
Well, I haven't seen a post here from the "KKK" in a while (Kotler,
Kleebauer, or Kern).

Hadn't thought of us quite that way. :) I'm still around. I think
Herbert's still with us. I fear Wolfgang may have "gone missing".

No Frank, it's perhaps too early to see me aside Beth :)

as of today I'm back online and just started to read through several
hundred newsletters (almost diagonally yet).
My new residence became finally finished and after some troubles with
my heavy worn body it may not become more worse for some time.
At the moment I have to sit on a suitcase with the keyboard on my knees
so I got time for posting while I wait for my furnitures to arrive.

__
wolfgang

Frank Kotler

2009-02-21 17:58:02 UTC

Wolfgang Kern wrote:

...

Post by Wolfgang Kern
as of today I'm back online

db "Welcome back, Wolfgang!", 10, 0

db "Best,", 10, "Frank", 10, 0

Herbert Kleebauer

2009-02-21 19:00:29 UTC

Post by Frank Kotler
...

Post by Wolfgang Kern
as of today I'm back online

db "Welcome back, Wolfgang!", 10, 0
db "Best,", 10, "Frank", 10, 0

^^ ^^
|| ||

Wolfagng doesn't speak Linux, only DOS Windows:

-> s/10/13,10/

Now, what happened to Betov? Is RosAsm still alive after
he resigned from the development team?

Wolfgang Kern

2009-02-22 09:11:12 UTC

Post by Herbert Kleebauer

Post by Frank Kotler
...

Post by Wolfgang Kern
as of today I'm back online

db "Welcome back, Wolfgang!", 10, 0
db "Best,", 10, "Frank", 10, 0

^^ ^^
|| ||

Post by Herbert Kleebauer
-> s/10/13,10/

because I use only 0Dh for LF+CR in my text-format,
(0A moves down w/o CR) it's not a real problem for me.
My conversion takes place during output to screen:
windoze: ignore the 0Ah (if accompanied by 0D)
linux : interprete 0A as it were 0D

Post by Herbert Kleebauer
Now, what happened to Betov? Is RosAsm still alive after
he resigned from the development team?

Don't know if Rene still reads ALA,
but I see my son and recently many of his friends use RosAsm
for all the things which aren't otherwise achievable, like
game-cheating, patches and funny replacements of boring stuff.
So RosAsm is still alive and the kids learn quite fast how to use.

Thanks to Frank and Nate.
__
wolfgang

Frank Kotler

2009-02-22 10:57:00 UTC

Wolfgang Kern wrote:

...

Post by Wolfgang Kern
Don't know if Rene still reads ALA,
but I see my son and recently many of his friends use RosAsm
for all the things which aren't otherwise achievable, like
game-cheating, patches and funny replacements of boring stuff.
So RosAsm is still alive and the kids learn quite fast how to use.

That's good to hear. My first reaction to RosAsm was, "This would be
great for beginners!" Too bad that ReactOS disappointed Betov so badly.
They're still chuggin' along - just released a new version. If they're
in the tank for Microsoft, they don't seem to know it. Maybe if they
keep at it until they have something suitable for beginners to run
RosAsm on, we'll see that "rebirth" after all!

I had occasion to post to the Ubuntu forum, recently. "A guy" was
posting to the Nasm forum... his expectations seemed unrealistic. Nathan
tipped me off that he was posting to Ubuntu, too, so I checked it out. I
didn't reply to his messages, but there were a couple others I thought I
knew the answer to. There's some interest in assembly there - not much,
but some. I told the guy, on the Nasm forum, that he'd probably like
Luxasm, but that it didn't exist... except as a concept. I'm still
thinking about it, but I'll probably never code anything. Too much of
the "meat" of it is the editor. I really have *no* interest in writing
an editor! Pity, for the kiddies that have never seen a command prompt
(Ubuntu apparently makes it possible!), it'd be great.

In other "tales out of school", Jeff Duntemann has been posting to Jeff
Owens' group, about suitable IDEs, libraries, etc. for beginners. Looks
like he's working on a third edition. Looks like it's going to have a
Linux section... Nasm syntax... Yeah!

Good to hear there's some interest around your area!

Best,
Frank

Rod Pemberton

2009-02-22 11:19:20 UTC

Post by Frank Kotler
...

Seems that "Spook" (Remember him?) made some recent comments on RosAsm:
http://www.asmcommunity.net/board/index.php?topic=29272.0

"As for ReactOS itself, I haven't tried it for some time. When I did, it
seemed like they had a long long long way to go. With the virtual loss of
Alex Ionescu, and the mind-numbing pace of Windows development by Microsoft,
I only see the road to ReactOS as drop-in replacement for Windows getting
progressive longer."

That's most of the last sentence is basically what I think is happening to
Linux...

Rod Pemberton

Wolfgang Kern

2009-02-22 19:34:58 UTC

Frank Kotler wrote:

...

Post by Wolfgang Kern
So RosAsm is still alive and the kids learn quite fast how to use.

some years ago the kids laughed at me and my oldfashioned codeing style,
but after they tried just simple things on C-light/C with only minor
success, endless cursing all this illogical syntax needs, they started
to watch how easy and fast I tell my machines what I want it to do.

So I didn't force 'em to use RosAsm nor ASM at all, I even advised
to look at html and other script-sources for easy coding, but to my
surprise they downloaded RosAsm and know meanwhile much more about
windoze than I ever wanted to know.

Post by Frank Kotler
I had occasion to post to the Ubuntu forum, recently. "A guy" was
posting to the Nasm forum... his expectations seemed unrealistic. Nathan
tipped me off that he was posting to Ubuntu, too, so I checked it out. I
didn't reply to his messages, but there were a couple others I thought I
knew the answer to. There's some interest in assembly there - not much,
but some. I told the guy, on the Nasm forum, that he'd probably like
Luxasm, but that it didn't exist... except as a concept. I'm still
thinking about it, but I'll probably never code anything. Too much of
the "meat" of it is the editor. I really have *no* interest in writing
an editor! Pity, for the kiddies that have never seen a command prompt
(Ubuntu apparently makes it possible!), it'd be great.

Luxasm may have gone with Beth, but her ideas of immediate line compiling
and other fine features are just too good for the waste-bin.
An Editor like RosAsm (type and hit run) is a hell of a job of course,
you could try to convince Rene to modify his windoze-only tool ... :)

Post by Frank Kotler
In other "tales out of school", Jeff Duntemann has been posting to Jeff
Owens' group, about suitable IDEs, libraries, etc. for beginners. Looks
like he's working on a third edition. Looks like it's going to have a
Linux section... Nasm syntax... Yeah!

Good news indeed.

Post by Frank Kotler
Good to hear there's some interest around your area!

I do my very best to keep a few fellows in the low-level camp.
(IMHO: only those who are able to should/will remain there)
__
wolfgang

n***@gmail.com

2009-02-21 18:10:03 UTC

Post by Wolfgang Kern
as of today I'm back online and just started to read through several

Welcome back!

Post by Wolfgang Kern
hundred newsletters (almost diagonally yet).

Oh, what misery! I wouldn't wish upon anyone the torture of reading
our 'fine poetry'! :)

Post by Wolfgang Kern
My new residence became finally finished and after some troubles with
my heavy worn body it may not become more worse for some time.

That is good news. Glad to hear that.

Nathan.

Phil Carmody

2009-02-15 08:33:28 UTC

Post by Terence
Anybody got any ideas on bringing this Forum back to dsicussions on
ASM, without the bilge?

Access it using a proper newsreader via a proper news server, and
just set your filters correctly. Filtering out everything from google
groups is a good start.

Phil

--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.

Robert Redelmeier

2009-02-15 16:27:54 UTC

Post by Terence
Anybody got any ideas on bringing this Forum back to
dsicussions on ASM, without the bilge?

No. Whatever you try, it will cause some false-positives
and introduce delay into discussions. All are costs.
Not everyone is as intolerant of bilge as you. Perhaps
you'd be happier reading c.l.a.x86 which is moderated.

-- Robert

WhiteTea

2009-02-20 01:41:19 UTC

Post by Terence
Anybody got any ideas on bringing this Forum back to dsicussions on
ASM, without the bilge?

This group is better in many ways that Rod mentioned.

The "arguement starters/maintainers" have left :-) and unfortunately a
lot of nice helpful coders as well. :-(

Recently I posted on the C.L.A.X. group and never saw my post.

But things are going well for me.

Take care.

Alexei A. Frounze

2009-02-20 07:16:00 UTC

Post by WhiteTea

Post by Terence
Anybody got any ideas on bringing this Forum back to dsicussions on
ASM, without the bilge?

This group is better in many ways that Rod mentioned.
The "arguement starters/maintainers" have left :-) and unfortunately a
lot of nice helpful coders as well. :-(
Recently I posted on the C.L.A.X. group and never saw my post.

I see mine delayed from time to time.

Alex

WhiteTea

2009-02-20 15:06:04 UTC