On Feb 25, 12:11 am, "Kadaitcha Man" <nntp.n...@gmail.com> wrote:
> > </quote> childish code. No wonder they
> > call it BASIC (read: code for children)

Actually, it's not quiet basic.. See below, as I tear K-man to
shreds

> These days, with .NET there is no fundamental difference between BASIC, C#
> and J#, et al. Real differences lie only in how the code is required to be
> structured by the precompiler. Only a very short copy/paste manoeuvre is
> needed to convert .NET-based C# to Visual Basic or Visual Java, and back
> again.

blah blah. Any developer realizes this.. even you... shrug.
> made with daubed faeces by captive orang-utans bored ****less from nothing
> else to do except swing in the trees and eat an endless supply of bananas.
>
> "That's a simple programming thing tho"http://groups.google.com.au/group/alt.comp.os.windows-xp/msg/616184df...
>
> The emphasis is on simple.

So simple in fact, you missed it.. See below.
> So, on to a really rough and quick but professional critique of the code
> above... I was a professional software developer, now in management, though
> I still cut a lot of code just to keep up with the latest advancements...
>
>
>
> > randomize
> > a=rnd(0)
> > a=a mod 1
> > b=rnd(0)
> > b=b mod 23
> > death=b
> ^^^^^^^^^^
> > b=rnd(0)
> > b=b mod 23
> > runy=b
> > b=rnd(0)
> > b=b mod 23
>
> The variable named "death" indicates that the language is capable of
> supporting variable names other than simple a, b, c. Code should make useof
> extended variable names with the intent of increasing the code's ability to
> self-document.

True, that was sloppy on my part. I think I said the code was sloppy
originally tho..

> As another example of the woefully poor exploitation of variable names...
>
> > ar=local
>
> ar might be short for "AR AR ME 'ARTIES!!!"
>
> Perhaps Dustfart fancies himself as a pirate on the high seas or something.

just lazy...

> > b=rnd(0)
> > b=b mod 23
> > death=b
>
> Three lines of code are used to do what can be done in one line...
>
> death = rnd(0) mod 23

Ahh, but your wrong sir. This is Asic, it cannot be done in one
line.

> The results are the same but the process is not. Dustfart's amateurish and

The results would be the same, If the language supported it in one
statement like that. (It doesn't). It's asic, not quiet basic.

> woefully inefficient code requires values to be moved left, right and
> centre, then all the way back again before a result is obtained. I use the

Ouch, I don't think you realize how close asic really is to
assembler... Your loss.

> word "amateurish" reservedly. I am bereft of sufficient one-word
> superlatives to convey the idea of complete rubbish born of his artless
> bumbling.
>
> > gosub check:
>
> Subroutines should only be used where there is a need to eliminate repeated
> _larger_ segments of code. The subroutine named "check" is called from only
> two places in the entire ...ahem... "program", and it will cause the
> compiler/run environment to beat on the processor; see a little later about

Actually, it won't. The assembler code is referenced via jmp
statements in the executable. It saves codespace, by writing code once
if it's going to be used more than once, it should be a routine. Why
repeat the same code?

> strings. Given what I say a later about strings inside loops, the "check"
> subroutine is not just entirely superfluous, it is detrimental to the
> efficient execution of the code.

Ehhhehh.. Heh, the code is written in asic. I don't think you quiet
understand what asic is.

> > b=b mod 23
> > death=b
> > b=rnd(0)
> > b=b mod 23
> > runy=b
> > b=rnd(0)
> > b=b mod 23
>
> > if death=runy then
> > a=rnd(0)
> > a=a mod 23
>
> Some variable modulus 23 is used 4 times in 10 lines. Setting aside that the
> code segments use 3 lines where one line will do, the whole rnd(x) mod 23
> should have been a candidate for conversion into a subroutine, then
> discarded as a candidate because it would probably require just as many
> processor cycles to jump and return as it would to calculate the modulus of
> two simple numbers inline. I doubt Dustfart's capacity to have ever
> considered that at all. I suppose soon enough we'll see if his hindsight
> is operating at a perfect 20-20.

Pure lazyness on my part. The entire rnd code could have been
converted to a subroutine, but it has to occur in that order. Asic
doesn't understand multiple statements/actions per line.

> > for y=1 to 24
> > a$=a$+"+-"
> > next y
>
> The code is very badly written and grossly inefficient. Any programmer worth
> the designation of "programmer" should know that strings are, more often
> than not, immutable in BASIC, which means that once a value has been
> assigned a string variable the value cannot be extended without moving the
> original to a new place, destroying the original variable then moving the
> new value from its temporary place and into a newly reserved block in
> memory.

You don't actually do much with assembler do you? Well anyways, when
asic compiles the binary, the resulting assembler code assigns
80characters of memory for each string variable I use. Regardless of
whether or not I use all of the space, the location of the variable is
known the whole time my code is running. Nothing need be, moved.
Overwritten as you wish, but moved, not unless you want too. If you
don't like this design, you may wish to take it up with Asics author,
I'm unable to evade this limitation myself.

> In the loop above, the compiler (I assume compiler, surely he's not
daft
> enough to use interpreted BASIC. Is he?), is forced to move the contents of
> the variable into a transient location, free up the formerly reserved memory
> location, create a new reserved location, then move the contents from
> transient storage to the new location no less than 24 times in a row. Each
> of the twenty four executions are repeated for every time the code loops
> through the controlling while/wend construct. It is utter ****e; it is not
> code.

Nope, Nope, Nope Nope, I have more of those. That's not what's
occuring in the resulting assembler binaries generated by the
compiler. If it was a real HLL language, it might do that, but it
doesn't have such capabilities.

STORAGE FORMATS

NORMAL INTEGERS are stored in ASIC as two bytes, with the low
order byte
appearing first (as per Intel conventions).

LONG INTEGERS are stored in ASIC as four bytes, with the least
significant
word first, followed by the most significant word. Within these
two words,
the least significant byte appears first followed by the most
significant
byte.

Page - 140




STRING VARIABLES are stored as FIXED 80 character strings
terminated by an
ASCII null character for a total length of 81 characters.

STRING CONSTANTS are stored with 1 byte per character in the
string
followed by a terminating ASCII null character.

DECIMAL VARIABLES AND CONSTANTS are stored in 8 bytes, from least
significant byte to most significant byte. They are stored as
signed
binary integers, with an implicit decimal point. The integer
values are
adjusted after each multiplication or division to scale the
result to the
proper number of decimal places.

ARRAYS - Each element in an array requires two bytes. (Don't
forget arrays
have an element zero (i.e. DIM A(2) is comprised of A(0), A(1),
and A(2)).

Examples:

Item Data Type Storage Requirements
A Integer Variable 2 bytes
17 Integer Constant 2 bytes
A& Long Integer Variable 4 bytes
55555& Long Integer Constant 4 bytes
A$ String Variable 81 bytes
"ABC" String Constant 4 bytes
"A" String Constant 2 bytes
A@ Decimal Variable 8 bytes
1.23456 Decimal Constant 8 bytes
12345@ Decimal Constant 8 bytes
DIM A(10) Integer Array 22 bytes
DIM A(1) Integer Array 4 bytes
DIM A&(10) Long Int Array 44 bytes
DIM A$(10) String Array 891 bytes
DIM A@(10) Decimal Array 88 bytes

As you can see, string variables are expensive in terms of
storage space.
Since string constants are stored at actual length +1, It is MUCH
more
efficient to store short strings as constants in ASIC in terms of
storage
space. There is no performance advantage to constants over
variables,
however.

In disk files, strings, decimals, and integers are written out in
the above
formats. Note that unlike GWBASIC/BASICA, integer and decimal
values are
NOT expanded into strings when written, and conversely, not
converted from
strings when read. String variables and constants are written
out as ASCII
strings terminated by a null character (however, the null can be
suppressed). Thus, string variables when written to disk, take
the same
space byte for byte as string constants.

The reason behind fixed length string variables was avoidance of
string
"garbage collection". In addition to slight performance
advantages, there
is the added benefit of providing a string memory address which
never


Page - 141



changes. Thus once VARPTR retrieves the address of a variable,
you never
have to worry about it changing.
EXE File Memory Map

The following describes the structure of the ".EXE" file created
by ASIC.
In the COM file format the code, data, and stack are all in the
same memory
segment. In an ASIC EXE format file, the code, data, and stack
each reside
in their own segment. Addresses are given as offsets from the CS
(Code
Segment), DS (Data Segment), or SS (Stack Segment) registers.


Description Address Range
------------------------------ -------------
Program Segment Prefix (PSP) CS: minus 00FF
(Created/Required by DOS, and
immediately precedes the
code segment)
|
|
v
Code Segment (CS
User Program 0000 +
|
|
v
System Subroutines Address Varies
|
|
v
Data Segment (DS
Program Data Area #1 0000 - 0102
String Conversion Buffer 0103 - 0109
Input Buffer 010A - 015B
Screen Width 015C
Color/Attribute Byte 015D
Screen Graphics Mode 015E
Cursor Position 015F - 0160
File Control Table 0161 - 0169
ERROR System Variable 016A - 016B
System Subroutine Vectors 016C - 017F
EXTENDED System Variable 0180 - 0181
RND Seed 0182 - 0185
Math Work Area 0186 - 018D
DEFSEG System Variable 018E - 018F
Start DATA Block Pointer 0190 - 0191
Current DATA Block Pointer 0192 - 0193
Reserved for future use 0194 - 0195
Optional System Sub Vectors 0196+
and Work Areas (decimal math option)
Program Data Area #2 Address Varies
|
|
v
Stack (SS (builds downward) 0000 - 07D0 (0FA0--debug
mode)


Page - 144



NOTE: The format of an EXE file created using the
"B/OBJ" option is essentially the same as the one
produced by the "B/EXE" option, except that the "B/OBJ"
output file may contain additional code or data
segments linked in from other OBJ or LIB files

Read it
0wned k-man. Full documentation for asic as well as the compiler can
be found on my site, if your inclined enough to educate yourself.
follow this link:
http://bughunter.it-mate.co.uk/asic500.zip
and if you dont want to touch the problem, but want to see the docs
alone, go here:
http://bughunter.it-mate.co.uk/asic.txt

There ya go, enjoy!



> It would have been far more efficient to simply declare a variable with...
>
> SomeVar$ = "+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..."
>
> But I suppose that would deny Dustfart the bragging rights on knowing howto
> execute a simple For...Next loop.
>
> > if a$="K" then
> > ...
> > endif
>
> Still on the subject of sloppy, inneficient coding; at compile time, the
> compiler will not be able to work out how or where to allocate a home for
> the simple "K" string literal. The job will therefore be left to runtime,
> where, of course, execution will be slowed while the run environment works
> out what to do with it. A far more efficient and elegant method would be....
>
> SomeVar$ = "K"
> ...
> ...
> If SomeOtherVar$ = SomeVar$ Then
> ...
> EndIf
>
> In fact...
>
> If NOT ((SomeOtherVar$ <> SomeVar$) AND (SomeOtherVar$ <> YetAnotherVar$))
> Then
> ...
> EndIf
>
> ...would be just as quick as, if not actually quicker than, the mess
> Dustfart made; the correct word is wrote but his crap is not worthy of such
> a word. A not equal operation requires less processor cycles than an equal
> operation. With a properly structured If...Then clause, there would be no
> need for the dog's breakfast below:
>
>
>
> > if a$="K" then
> > if local=0 then
> > beep
> > else
> > gosub check:
> > local=local-1
> > locate zone,local
> > print"U";
> > endif
> > endif
> > if a$="M" then
> > if local=23 then
> > beep
> > else
> > gosub check:
> > local=local+1
> > locate zone,local
>
> As an alternative to checking "if a$="K" then", to avoid ****ing about with
> literals entirely...
>
> If SomeOtherVar$ = Chr$(70) Then
> ...
> EndIf
>
> There is no sign in the code whatsoever that Dustfart knows what Boolean
> notation is or does in BASIC. I may have been inclined to be a little ...
>
> read more »