Re: The War On HLA
From: The Half A Wannabee (ShakainZulu_at_hotmail.com)
Date: 10/31/03
- Next message: The Half A Wannabee: "Re: The War On HLA"
- Previous message: Davor Grguric: "Re: Transfering control from 32bit to 16bit application"
- In reply to: Randall Hyde: "Re: The War On HLA"
- Next in thread: The Half A Wannabee: "Re: The War On HLA"
- Reply: The Half A Wannabee: "Re: The War On HLA"
- Reply: Randall Hyde: "Re: The War On HLA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 31 Oct 2003 05:49:45 +0100
"Randall Hyde" <randyhyde@earthlink.net> wrote in message
news:gxbob.8360$Px2.7300@newsread4.news.pas.earthlink.net...
>
> "The Half A Wannabee" <ShakainZulu@hotmail.com> wrote in message
news:3fa0fa7c$1@news.broadpark.no...
First of all, thanks for the reply. You take the effort, and that s fine
with me.
> >
> > >
> > > No macro facilities, for example.
> >
> > I guess not. I never had any need for it either. You know, its the same
as
> > inserting code into the place you place the macro name. You dont need
to
> > jump. It makes the code longer and thus the compiler cannot optimize as
> > well. Best code in delphi is a few lines at most. It helps the optimizer
> > makeing better use of registers.
>
> As macros expand in-line and are the same as simply writing the code
> in-place, clearly the use of macros has no impact whatsoever on
optimization.
I thought macros wore invented earlier (last century) to avoid emptying the
cache.
They may have gotten a lot of other features too and I must admit, I dont
really know them like you
seem to do. Judging from betovs Spasm, macros there seem to have the same
purpose that you refrase here.
They can extend the language. They DO have more power than simply inline. I
was dead wrong there. But they do not add any *functionality* to the Object
Pascal language. As you can do the same with a function, or about the same.
the only diffrence would be the call. Wouldnt it ?
> If you're assuming that macros' only purpose is for "in-line" functions, I
> can understand why you might come to this conclusion. However, macros
> do have other purposes. The macro facilities in the Dylan, Lisp, and
Haskell
> languages demonstrate the ability of using macros to extend the language.
> Oh, I forgot, the macro system in HLA *also* demonstrates how to extend
> the language with macros :-).
I guess. For an assembler to be able to build highlevel like syntax macros
would be neat, but I mean, a call would do about the same there too. A
powerful macrosystem may be neat and clean, but its more a matter of
preference than it adds real power to a language. What is their real
diffrence in what they can do ?
Delphi supports most stackframes, and also procedures without any
stackframe, write them in basm, and they are what ? Macros, no less. The
call thats whats the diffrence ? IMO macros doesnt allways make for better
reading. They are unneeded spesial cases.
>
> > In sections of code where you need real raw speed, you dont need macros
> > either, you need hands on optimizations, no time to waste on macros
there.
>
> In sections of code where you need raw speed, you need to be careful
> about using black boxes (e.g., macros). However, if speed is that
important,
> I would ask why you're using Delphi in the first place.
If you have to ask, you shouldnt. It shows that you havent spent enough time
with it.
> Delphi's okay, but the
> optimizer is *far* from great. Macros in Delphi would be nice because they
> would allow you to *extend* the language to produce shorter (lines of
source
> code) programs and, if done carefully, easier to read programs.
Oh common Randall. Allows you to extend the language ? This is *very* weak
argument. Are you saying that functions and procedure does NOT allow you to
extend the language ? What are you saying then ? Cause that statement is
just hillerious.
If the optimizer is *far* from great, explain how its not so great. Do you
just have to debate everything, even when you're on thin ice ? the optimzer
works pretty well, when given a little help. Its the same with all
compilers, they need a litle inside information help. If you make call to
properties of objects inside a loop, it suck, yes, but there are ways to
write godd HLL and bad HLL. Good HLL is optimized pretty decent. Good pascal
programmers write ASM comparable speed when put to the test. I have seen
this in the basm group about 5 years ago. Or was it here in fact ?
>
> > You need MAbrash, patience, willingness to rewrite, and rewrite and
rewrite
> > and do it over again and over again. Macros is not a big loss. Hardware
(New
> > CPUs) have made jumps far less expensive than previously.
>
> Again, the desire for macros has nothing to do with in-line functions.
I get that now. But have you gotten the point yet that they arent strictly
needed ?
>
> > > The only facility for initialized static variables is via structure
> > constants (a
> > > bit of a kludge).
> >
> > const
> > ListOfSomeUnsignedIntegers = array[0..2] of Longint = (100, 30000,
> > MaxLongint);
> >
> > That was hard. Const are writeable in Delphi (optional).
>
> Therein lies the kludge.
> Writeable constants :-) Just as bad as the use of the const keyword in
C++.
No Randy. You are too much of a proffessor. Any ability in a language, any
feature is left to the programmer to invent his own uses for. You can
declare a constant data, and a variable, point the variable to the const
data and do what you want. Its just data anyway. An OOP programmer doesnt
have MUCH need for static variables in any case, he converts dynamic memory
to "static" memory when he needs it. Its just the same memory.
A pascal programmer has many types of data he can declear, the memory are
just memory, he can access it any way he wants to, you dont (yet) get a
warning from M$ for accessing you data a little diffrently. If the memory
section is writeable, you can write to it.
>
> > Also. Real
> > programmers use code to initialize variables. It saves time, and its
much
> > easier to produse diffrent initializations.
>
> ?????
> What on earth makes you say this?
> Ignoring languages, like C, that let you initialize static objects at
compile-time,
> just consider assembly language programmers (i.e., the people who
> frequent this group). They statically initialize data all the time. Are
you saying
> that assembly language programmers "aren't real programmers"?
No of course not. Maybe that was a bit of a mouthful, my appologies for all
the broken hearts :-)
What I meant is that when you write huge programs meant to accomplish a
great deal, you dont hardcode everything in the program. in fact the less
the better.You can do it of course, but its much easier to NOT hardcode
things. It makes for better possibilities for user interaction. And
modifications. "No stupid user, you cannot change this bitmap, its hard
coded in the application source.". "What do you want to rotate that spere
180 degreess in realtime ? You want it to be half the size, wait for the
next release, it will feature a sphere rotated exactly as you want it, and
shruken too."
Oh Randy no need to save my word documents anymore, just hardcode them in
Office. (Hell is it that the reason they come out so often and are using so
much diskspace) ?
>
> Note that if you initialize "constant" objects with code, you pay for
> that initializing three times: 1: the memory that holds the actual object,
> 2: the embedded constants in the instructions (or other section of
> memory) that holds the data you're copying to the memory object, and
> 3: the machine instructions needed to copy the data.
>
> If you've got a table of strings, records, whatever, initializing this
> by code is very expensive, space-wise.
>
> I would really like to see your justification that code is easier to
> maintain.
Oh, this is getting boring. Can you leave that stupid constants now? Its
just data Randy. They dont issue a certificate yet on how to access it. And
we hardly use them anyway.
>
> > But for a class of student
> > learing HLA it might be more suitable to hardcode. But it Never is in
real
> > life.What you need in real life is a 3d editor to edit your data.
>
> And it would be nice to have the loader preinitialize that data so you
> don't have to waste code and time doing it once the program starts up.
> As the stuff is not "constant" data, it doesn't seem write to declare
> such variables in Pascal's "const" section.
A program need some constants. I prefer to have as litle as possible. My
table object for example, can contains so rediculously many items and
columns that I prefere to make the MaxItems a variable. Its a 64bit integer
variable and has an implisit MAX. Maxint64 is predefined in delphi and no
need to declare it again. Its utterly dynamic, containing one item or an
insane not even imageable amount, on an int64 count of pages for the insane
harddisk listing. I truely never have to tough that code again. I try to
write low level code to never do it again.
But some things are unavoidable to decleare as contants. Predeclaring all my
5000 mp3 songs inside a program is on the otherhand just weird. And somehow
I think that you know this pretty well. I stopped writing hello world
applications many years ago.
> > >It would also be *really* nice if it supported thunks or
> >
> > What are thunks ? Abilty to talk to 16 bit code ? thats supported by the
> > API, and thus by Delphi, am I wrong ?
>
> Microsoft's "thunks" are a small category of the general concept of
> a thunk. A thunk is a piece of code and its execution environment
> rolled into a variable. One way to think of a thunk is as a variable that
> can hold a statement (or sequence of statements) for later execution.
> This allows you to treat statements as "first-class" objects in a
> programming language (i.e., you can assign them to variables,
> return them as function results, do various operations on them, etc.).
> Note that a procedure does not qualify because it doesn't carry
> the execution environment around from where the thunk was
> created.
I am not sure what you are talking about.
Objects/classes/encapsulation/overloading ?
Cout and stuff like that (C). If thats the case there is nothing new about
it, and it certainly has nothing to offer in terms of functionality, but for
a programmer yes, it hides information. Which can be bad. The programmer is
not perfect and he will die or quit. The code will reveal shortcommings and
or bugs. The really good thing about OOP is not implementation hideing, but
scope and modularity. Many of the other features, like the so once popular
polymorfism and inheritance is mostly the emperors clothing. The real
strength of OOP is that it allows a single programmer to create huge
applications given time and effort, and to slowly build a house with
patience and persistens. But if he doesnt do it ALL himself, he will run
into problems one day. And it will be something created by some other
person. That might be dead, or left, or just not available. So he might just
save himself the effort and do it asm from the start, cause soon he gonna
hide things even from himself. Thats why I like Betovs approach. And I
belive he knows all this from experience, and that is why he is so strict
about it. I belive his on the right track.
Your are not up to date on Delphi. Delphi is the mother of OOP. Not the true
mother, but the language that made it clear that it had something to offer.
Borland C++ was created in parallell. They are now virtually identical in
terms of OOP and interfaces, COM support.(Which I by the way hate like the
plague)
>
>
> > Why would anyone would want to do that is beyond me, but I see there
would
> > be a need 10 years ago. But its a bad idea, and very lazy. I reworte my
code
> > for 32 bit rather than using the thunk mechanism. Many years ago. The
code
> > got cleaner for it too. You dont need 16-bit code in windows, you need a
> > service.
>
> This has nothing to do with 16-bit vs. 32-bit code.
> It has to do with deferred (eager vs. lazy) execution which is *very*
> important in AI and in certain algorithms.
>
Yes I understood it the first time :-) Maybe I sound a litle harsh in my
writing ? I am not. I am in a hell of nice mode cause I just got a 2Mbit
24/7 internett connection and can stay online to irritate you as much as I
want. For the first time in my life. And no meter running ! Im not really
allways such a smart ass. Its just so cool to be talking to you like
this...... :-) I am the wannabee remember ? We're just having a little fun
at each other, dont you think ?
>
> > > pass by name parameters.
> >
> > Pass by name parameters? I dont even know what you are talking about.
Pass
> > by name parameters? If I knew what it was I could show you the code.
What is
> > it that you want to pass by name in parameters. And how would it not be
> > supported ?
>
> Take a look at the following chapters in the on-line version of AoA
> at http://webster.cs.ucr.edu/Page_AoAWin/PDFs/0_PDFIndexWin.html
>
Okey Randall. I will read it. I will anyway. And as I recall I have allready
read it, but it was a long long time ago. Theres been some applications in
the making between then and now. And my brain is just not big enough to hold
on to all that information. You must have a really big head.
> Vol 5, Ch1: thunks,
> Vol 5, Ch2: Iterators,
> Vol 5, Ch3: Coroutines
> Vol 5, Ch4: Low Level Parameter Implementation
>
> These chapters nicely cover topics like thunks, pass by name,
> iterators, coroutines, and other nice features that would be
> nice to have in Delphi.
>
>
> > >32-bit unsigned integers would be nice, too.
> >
> > ???
>
> Delphi currently supports only 31-bit unsigned integers.
>
> >
> > > Iterators and a foreach loop would be great.
> >
> > This was supported earlier, but was removed from the RTL. Thats because
> > there are much better ways to handle such situations. I write my own
foreach
> > loops quite easily.
>
> No, you don't. Unless you're calling assembly code from Delphi.
> See the aforementioned chapter on Iterators in AoA. The things
> that Delphi and C++ users call "iterators" are not truly iterators.
> They are better known as "cursors". To learn more about what
> a real iterator is, check out the CLU programming language
> (which is the first place I'm aware of where iterators were
> created). Also look at iterators in HLA.
Yes iterators. I read about them later.
>
>
> > Procedure TSZSkinTable.ForEach(AProcedure : TItemProcedure);
> >
> > var
> >
> > j : integer;
> >
> > begin
> >
> > for j := 0 to MaxLines -1 do
> >
> > AProcedure(self, j);
> >
> > //We call one more time to tell that we are done
> >
> > AProcedure(self, -1);
> >
> > end;
>
I knew it was not an iterator. Is it a cursor. hm. Whats this thing that I
point an click with then ? A foreach loop ?
> This is a cursor, not an iterator. Check out the
> chapter on Iterators in AoA to see the difference.
>
>
> >
> > > The list could go on and on.
> >
> > No it couldnt. Thats a very poor statement from a man like you.
>
> Really?
Yes. For any man. "The list could go on an on."? Seems like its endless. Do
you really mean that it is endless ?
Not even figuratively speaking could you say that it is endless.
> I've taught programming language design for the better part of
> a decade at UC Riverside. Perhaps it's not unreasonable for me
> to claim that I could come up with a lot of language features that
> Delphi should have, but doesn't?
It has ALL the features that a language needs, but not all that you need.
You need a "truck to carry a stawberry". Just like betov says.
>The truth is, no matter how long
> the list gets, I can still make this claim.
So if the list has to items, it could still go on and on ?
>Delphi is far from perfect
> (from a language design point of view); I just chose to cut the list
> short for space reasons.
Sure. you have a real hard time making yourself verbose :-)
> If you believe that Delphi is the be-all,
> end-all, of programming languages, I strongly suggest that you
> take a course on programming language design.
I dont belive that. I belive that all languages, except from thoose I dont
know, can be the be-all in the right hands.the person who loves his toy will
find a way. I take that course every day since I new what a computer was.
And I dont intend to quit, and I have "knowing ignorance". Just pretend
sometimes, that I dont. For fun.
> There's quite
> a bit more that could be added to Delphi. For example, I haven't
> even discussed dynamic language features, advanced data structures,
> non-imperative programming facilities, and so on.
And you shouldnt since its all there. What the freaking jonson is
non-imperative programming facilities ?
You really are the the PDF jedi. The Obi wan PDF. Lol.
> I'm sorry I don't have the time to write you a 500 page book
> explaining all the nice language features Delphi *could* have but
> doesn't. However, such books already exist (not to mention lots
> of journal papers), so there really is no need to repeat that information
> here. Go grab one of those books and read about it for yourself
> if you're interested. Making statements like "No, it couldn't" is a very
> weak statement, even from someone like you :-)
:-) Cool. Can you help me out with a title. It seems better to ask you.
You'll know.
>
>
> > > Then, of course (bringing this discussion back on-topic), Delphi's
support
> > > for linking with external assembly code is asbysmal.
> >
> > I stopped linking in .obj code i wrote in tasm, when I saw how easy I
could
> > avoid the pain by just pasting it into the editor and rewriting it
pascal
> > style syntax in BASM. So I couldnt say. I dont complain about support
for
> > something that isnt needed anymore.
>
> The fact that *you* don't use it doesn't mean it isn't needed.
No. The fact that Basm can perform the actions for me does.
>
> > BASM is pretty good
> > > for a built-in assembler, but it's nothing compared with MASM or HLA.
> >
> > How so. It support ALL contructs in the Object Pascal language. It
supports
> > accessing types like this :
> > asm
> > mov eax, [ebx].TPoint.X
> > mov edx, [ebx].TPoint.Y
> > end;
> >
> > This kind of asm, doesnt even need an explanation for an HLL programmer,
> > familiar with windows, to understand what is going on. Can you do this
in
> > HLA ? I guess you could. Only it would look like this :
> >
> > mov (([(ebx)].TPoint).(X)(eax), )
> > mov (([(ebx)].TPoint).(X)(eax), )
> >
> > Sorry if that was wrong, but I got confused by all the extra padded
> > parantesis :-) Lol
>
> If all you need is MOV instructions, BASM is fine :-)
> I hate to be condescending here
Hey. I dont mind. You have earned it. Dont hate yourself for it.
>(something I get accused of
> frequently),
I cant for the life of me spot it anywhere.
>but if you think that BASM is just great -- stick with it.
> Those of us that do a bit more advanced work in assembly find BASM
> a little, well, limiting.
ROFLOL. No you are not condescending, you are the PDF master of
"condescending".
>
> BTW, in HLA you'd probably use statements like the following:
>
> mov( thePoint.X, eax );
> mov( thePoint.Y, ebx );
>
So you just embed the EBX register in the "thePoint" is that the point ?
My point was that basm code can entail a register like EBX, pointing to a
structure with
the Structure syntax and . Member.
e,g mov edi, [eax].TPDFStudents.Name
now edi points to a string inside the TpdfStudents record/(STRUCT = C).
Furthermore it goes a long way on commenting the code at the same time.
Your code above doesnt do the same, but close. You seem to access a (local)
variable
instead of a pointer in a register. Basm do that too of course. And I never
claimed HLA
couldnt do it. I asked if it could.
When I translated the first line to quasi HLA i found it so easy just to
copy it to the next line, and forgot to
correct the code to "relect" the code I landed. But you could only read the
one with the parantesis ?
> If you were actually using these two statements all over the place.
> You'd set up a text object to do the coercion for you. If you were
> only using these two MOV instructions, then you'd probably just
> stick with BASM -- That's what it's good for. I thought I made it
> clear that BASM is great for simple stuff, you need a better assembler
> for advanced assembly code. You didn't give an example of advanced
> assembly code, I'm afraid. So your example doesn't do a good job
> of demonstrating where BASM fails.
Smile. True, not much of code there. I guess you dump edge scanning code on
your students ?
I have written 100K lines of half crap/half good code in Delphi. But it
works. I have only did very few pieces in asm. I have only one section of
code that I really am proud of. It was a great feeling. Like if you made
your own sneakers , and wore proud to wear them and show them of. *
I have made crap asm code to. Asm is not hard in itself (surpricingly simple
infact). As I have said before, any language is but a tool. There are
secrets, you only learn by doing it, and that sets aside the weak asm
programmer (moi) from the really strong one. Like Betov or perhaps Beth or
Annie. But syntactically/symbolic asm is the easiest of all languages to
learn.
But to make something useful of it is of course a hard work, and needs lots
of thinking to get it really good. So in that sence its the hardest laguage,
but to repeat, its syntax is simple, and many intructions you can just skip
to learn, since the more simple instructions can take you a long way.
*
(However in 1997 I made the first desision to delete all my code. But after
a few weeks I regrettet my dessision. I crawled under the bed, and in all my
closets to find a set of disks with a more up todate backup. I lost half a
year of work. In that work was the code I developed with a friend of mine
together on the phone we kept telling each other times it took to run. Like
this we continued for hours. The result was staggering. 37 hours no less
into 18 seconds for a 486 DX2. But after the code was done, the main change
was not in the asm transition, but in thinking diffrently. When we focues on
that code, and made a competition out of it, we saw new solutions. We used
all the triks available in asm books of those days, but still the asm could
only push the code two-tree times faster than pascal. And that was because
in the final step, we shuffled instructions to utilize the U/V pipes
simulataniously. Like MAbash wrote a book about. A lookuptable was also a
part of the final solution and we really proved that MA book on optimizing
was worth its every penny. It was very fun.
The leson of the deleted code taught the value of refactoring as it is
populary called theese days. I made it much better the second time. And the
6 month of work took no more than a few days, maybe a couple of weeks to
rewrite. One day I hope to have the currage to delete all my code. Cause its
holding me back. In many ways. There is more to life than programming after
all - or perhaps there isnt. Is it ?).
>
>
> >
> > > The ability to only really work with TASM-assembled code is somewhat
> > > sad. Also, it would be really nice if you could produce object files
you
> > could
> > > link with other languages.
> >
> > Never did that so cant tell. I bet its supported if you look deep
enough, at
> > least in one of the former versions. Like the former BP7.0 which as far
as I
> > remember supported lots of nice stuff like that, but this I cannot
really be
> > sure of at the moment. But the current version supports interfaces, and
> > writing of comservers to let C++ and VB user use you code is easy. A bit
> > pain with the bloated interface editor, but not at all difficult to
> > accomplish with the tougue kept straight in mouth.
> > >
> > > This is not to say that Delphi is a bad language. It is one of my
favorite
> > > HLLs out there. But every HLL is crippled in one way or another.
> >
> > This is such a strange thing to say. EVERY HLL is crippled. Its like
saying
> > everyone but me is stupid. I say that a lot when I am frustrated, but I
know
> > it isnt true.
>
> Let me rephrase that. *EVERY* language (HLL or LLL) is crippled in
> one way or another. If this weren't the case, we'd all be using the one
> perfect language out there.
You get the final words Randy. I owe you that much. Keep writing thoose
PDFs, the world needs them after all.
>
> Cheers,
> Randy Hyde
>
>
- Next message: The Half A Wannabee: "Re: The War On HLA"
- Previous message: Davor Grguric: "Re: Transfering control from 32bit to 16bit application"
- In reply to: Randall Hyde: "Re: The War On HLA"
- Next in thread: The Half A Wannabee: "Re: The War On HLA"
- Reply: The Half A Wannabee: "Re: The War On HLA"
- Reply: Randall Hyde: "Re: The War On HLA"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
