Hello Andrei,

> I think it would be really classy if Walter did /not/ write "Why D
> compiles quickly" for his next installment.
> 

Maybe hold off till the one after that? If he doesn't do it sometime, I'll be bumed.

-- 
... <IXOYE><

Nick Sabalausky wrote:

> "Walter Bright" <newshound2@digitalmars.com> wrote in message news:i4kjdp$2o9f$1@digitalmars.com...
>> Nick Sabalausky wrote:
>>> Yea. If Java's design philosophy were a valid one, there would never have
>>> been any reason to move beyond Altair-style programming (ie, entering
>>> machine code (not asm) in binary, one byte at a time, via physical toggle
>>> switches). You *can* do anything you need like that (It's
>>> Turing-complete!).
>>
>> Yeah, and I've seen OOP done in C, and it works. It's just awful. I've even seen OOP done in assembler (Optlink!).
> 
> I've seen high-precision PI calculation done in MS batch:
> 
> http://thedailywtf.com/Articles/Stupid-Coding-Tricks-A-Batch-of-Pi.aspx
> 
> And Adam Ruppe did cgi in Asm:
> 
> http://www.arsdnet.net/cgi-bin/a.out
> 
> And some massochist did a compile-time raytracer in C++:
> 
> http://ompf.org/forum/viewtopic.php?t=1556
> 
> Yea, I know that had already been done in D, but D's compile-time processing doesn't suck :)

Don't forget the perl regex to check for a prime number:

perl -wle 'print "Prime" if (1 x shift) !~ /^1?$|^(11+?)\1+$/' [number]

http://montreal.pm.org/tech/neil_kandalgaonkar.shtml

bearophile <bearophileHUGS@lycos.com> wrote:

> Andrej Mitrovic:
>> You could do OOP in HLA (of course nobody treats that as a real
>> assembler :p. But the book that comes with it is great.).
>
> I may like to see the built-in asm of D replaced by HLA :-)

But why? Could you not simply drop in and out of assembly and use
D for flow-control and the like?

-- 
Simen

Simen kjaeraas:
> But why? Could you not simply drop in and out of assembly and use D for flow-control and the like?

I don't know. I think that every time you drop in and out of assembly, unless your used naked assembly, the compiler adds some leading and trailing instructions.

In the biological and technological evolution most of the changes happen when a new "species" appear, then later the "species" are almost frozen, changes appear only very slowly. So for example you see many improvements in Java compared to many years of C/C++ evolution. This is part of the Punctuated Equilibria theory by S. J. Gould and others, and it's not specific of biological evolution, it's a property of dynamic systems that are in evolution.

Assembly and assemblers were born many years ago, and even if today we have invented many better ideas to software, those ideas are usually not applied to asm world.

The good thing of HLA is that it tries to break some of that tradition, and to bring a bit of innovation in the world of asm programming, and it does it well enough (despite the innovations it brings are probably mostly 30 years old, about as new as the original Pascal is; there are far more newer ideas that may be applied to asm programming. Some newer ideas can be seen in CorePy: http://www.corepy.org/ that allows to write computational kernels through Python code that are usually faster than D code).

This is why there are moments when I'd like a more modern asm inside D. I've written few hundred lines of asm code inside D programs, this is not a lot, it's just a bit of code, but for me it's a pain to write asm normally, and I can seen tens of ways to improve that work of mine :-)

Bye,
bearophile

Glancing over it really quickly, High Level Assembly is /completely insane/. The whole point of writing assembly language is to see and write exactly what the computer sees and executes. This makes it useful for coding, and also very easy to read (in the small, at least).

The HLA examples on Wikipedia are horribly ugly messes of macros and other weird stuff. It is like a cross of Perl and C++!

The Microsoft assembler used to have a whole bunch of weird macro capabilities and strange syntax. I hated it. This looks like that turned up to 11.


D's assembler is almost perfect... it integrates without hassle, it gives you what you need, and it is very read/writable. The only complaint I have with it is that you have to capitalize register names. Blargh.

Adam Ruppe wrote:
> The Microsoft assembler used to have a whole bunch of weird macro
> capabilities and strange syntax. I hated it.

What I did when faced with such code is assemble it, *disassemble* the output, and paste the output back in the source code and work from that.

== Quote from Walter Bright (newshound2@digitalmars.com)'s article
> Adam Ruppe wrote:
> > The Microsoft assembler used to have a whole bunch of weird macro capabilities and strange syntax. I hated it.
> What I did when faced with such code is assemble it, *disassemble* the output, and paste the output back in the source code and work from that.

How did you do this?  Don't you lose some important stuff like label names in the translation?  Instead of LSomeLabelName you get some raw, inscrutable hexadecimal number in your jump instructions.

On 8/20/10, dsimcha <dsimcha@yahoo.com> wrote:
> How did you do this?  Don't you lose some important stuff like label names in the translation?

Yes, though a lot of label names aren't all that helpful in the first place. "done:" or worse yet, "L1:" don't help much. Those names are obvious from context anyway.

> Instead of LSomeLabelName you get some raw, inscrutable hexadecimal
 number in your jump instructions.

A lot of disassemblers generate a label name instead of giving the hex. obj2asm for example translates most jumps into Lxxx: labels.

dsimcha wrote:
> == Quote from Walter Bright (newshound2@digitalmars.com)'s article
>> Adam Ruppe wrote:
>>> The Microsoft assembler used to have a whole bunch of weird macro
>>> capabilities and strange syntax. I hated it.
>> What I did when faced with such code is assemble it, *disassemble* the output,
>> and paste the output back in the source code and work from that.
> 
> How did you do this?

obj2asm foo.obj >foo.asm

> Don't you lose some important stuff like label names in the
> translation?  Instead of LSomeLabelName you get some raw, inscrutable hexadecimal
> number in your jump instructions.

Sure, it might need a bit of tidying up by hand, but that was a lot easier than trying to spelunk what those macros actually did.

I'm not the only one. I know a team at a large unnamed company that was faced with updating some legacy asm code that the original, long gone, programmers had gone to town with inventing their own high level macro language. Programmer after programmer gave up working on it, until one guy had no problem. He was asked how he worked with that mess, and he said no problem, he assembled it, obj2asm'd it, and that was the new source.

Hello Adam,

>> Instead of LSomeLabelName you get some raw, inscrutable hexadecimal
>> number in your jump instructions.
> 
> A lot of disassemblers generate a label name instead of giving the
> hex. obj2asm for example translates most jumps into Lxxx: labels.
> 

that plus find/replace will get you a long way.

-- 
... <IXOYE><