>> This only matters if you're interested in performance.
>
> Why else would you use assembly?

Perhaps because you need to perform specific hardware-level operations 
that C doesn't support. (E.g., selecting a different processor mode or 
something.) There's usually a few bits of the OS written in assembly 
because they do very low-level stuff.

> There are plenty of languages that allow better maintainability.
>
> Assembly isn't portable by its very nature ;)

...which leads us back to my "there are *reasons* why nobody uses 
assembler any more". ;-)

Post a reply to this message

On 2/18/2011 8:22 AM, Invisible wrote:

> Mathematica doesn't work this way. The core implements a transformation
> engine, and arbitrary precision math. Beyond that, the parser, the
> printer, the simplification rules, *everything* is Mathematica source
> code, which can be altered at will (if you're so-inclined).
>
> I have no idea about the architecture of Maxima, but it wouldn't
> surprise me. There are advantages to doing it this way. (The main
> disadvantage is performance...)

Yep :) pretty much how Maxima works. You can define your own operators, 
their associativity (if any), precedence, and a number of other things. 
Rules are defined in much the way you described. They're all written in 
Maxima's language. There are a few intrinsic things: assignment, 
function calls, and some other syntax glue.... But just about anything 
can be defined as just about anything else.

-- 
~Mike

Post a reply to this message

On 2/18/2011 8:56 AM, Invisible wrote:
>>> This only matters if you're interested in performance.
>>
>> Why else would you use assembly?
>
> Perhaps because you need to perform specific hardware-level operations
> that C doesn't support. (E.g., selecting a different processor mode or
> something.) There's usually a few bits of the OS written in assembly
> because they do very low-level stuff.
>

Oh, right ... I forgot about that.

> ...which leads us back to my "there are *reasons* why nobody uses
> assembler any more". ;-)

Well, if you don't want to write portable code... then go for it.

-- 
~Mike

Post a reply to this message

>> Mathematica doesn't work this way. The core implements a transformation
>> engine, and arbitrary precision math. Beyond that, the parser, the
>> printer, the simplification rules, *everything* is Mathematica source
>> code, which can be altered at will (if you're so-inclined).
>
> Yep :) pretty much how Maxima works. You can define your own operators,
> their associativity (if any), precedence, and a number of other things.
> Rules are defined in much the way you described. They're all written in
> Maxima's language. There are a few intrinsic things: assignment,
> function calls, and some other syntax glue.... But just about anything
> can be defined as just about anything else.

I haven't tried this, but I understand that the actual input parser for 
Mathematica is user-defined. You can make it parse, e.g., chemical 
formulas rather than algebra. You can change what function-call syntax 
looks like. And so on.

Then again, you don't buy a £7,000 CAS system in order to modify it into 
something that doesn't do math. ;-)

Post a reply to this message

>>>> This only matters if you're interested in performance.
>>>
>>> Why else would you use assembly?
>>
>> Perhaps because you need to perform specific hardware-level operations
>> that C doesn't support.
>
> Oh, right ... I forgot about that.

Never forget. ;-)

>> ...which leads us back to my "there are *reasons* why nobody uses
>> assembler any more". ;-)
>
> Well, if you don't want to write portable code... then go for it.

I'm sure if you're trying to program a toaster, it might actually be 
worth it. (How complex can it possibly be?)

It's surprising how many Project Euler problems have solutions (plural) 
in assembly...

Post a reply to this message

On 17/02/2011 01:48 PM, Mike the Elder wrote:

> Opinions are like anthills?

Everybody makes mountains out of them?

No, wait, that's molehills...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> This only matters if you're interested in performance.
> >
> > Why else would you use assembly?

> Perhaps because you need to perform specific hardware-level operations 
> that C doesn't support. (E.g., selecting a different processor mode or 
> something.) There's usually a few bits of the OS written in assembly 
> because they do very low-level stuff.

  It's not like you need to write the entire program in assembly just
because you need to execute one asm instruction not supported by the
language. They invented inline asm for a reason.

-- 
                                                          - Warp

Post a reply to this message

On 20/02/2011 04:28 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>>>> This only matters if you're interested in performance.
>>>
>>> Why else would you use assembly?
>
>> Perhaps because you need to perform specific hardware-level operations
>> that C doesn't support. (E.g., selecting a different processor mode or
>> something.) There's usually a few bits of the OS written in assembly
>> because they do very low-level stuff.
>
>    It's not like you need to write the entire program in assembly just
> because you need to execute one asm instruction not supported by the
> language. They invented inline asm for a reason.

Sure. I was just pointing out that "performance" isn't the only possible 
reason for writing assembly. My original point was that "nobody writes 
assembly any more"...

Post a reply to this message

On 2/18/2011 9:59 AM, Invisible wrote:
>>> Mathematica doesn't work this way. The core implements a transformation
>>> engine, and arbitrary precision math. Beyond that, the parser, the
>>> printer, the simplification rules, *everything* is Mathematica source
>>> code, which can be altered at will (if you're so-inclined).
>>
>> Yep :) pretty much how Maxima works. You can define your own operators,
>> their associativity (if any), precedence, and a number of other things.
>> Rules are defined in much the way you described. They're all written in
>> Maxima's language. There are a few intrinsic things: assignment,
>> function calls, and some other syntax glue.... But just about anything
>> can be defined as just about anything else.
>
> I haven't tried this, but I understand that the actual input parser for
> Mathematica is user-defined. You can make it parse, e.g., chemical
> formulas rather than algebra. You can change what function-call syntax
> looks like. And so on.

It can be done with Maxima. It really depends on how far you want to 
push it. What probably cannot be done is really low-level changes to the 
way it handles input. e.g. altering the basic syntax of the system 
without lifting the hood and tweaking the underlying lisp (Though, you 
can do this from inside the workbook.

What you can do within Maxima's language is define new operators, set 
that operator as postfix, infix, prefix, or nofix, and have fine-grained 
control over precedence and associativity. I suppose technically you 
could redefine how a function is called within its language.

I'm actually fooling with getting it to simplify boolean algebra by 
messing with pattern matching and such, but I haven't wrapped my head 
completely around how the matching works, and how to get it to do some 
of the more interesting stuff. It's there, they have packages for all 
kinds of things, including simplifying inequalities, etc all written in 
Maxima's language.

I guess, technically you could do the same thing  (have it manipulate 
chemical equations instead of mathematical equations, it doesn't seem 
like that big of a leap, given the simplifier engine) inside of Maxima.

> Then again, you don't buy a £7,000 CAS system in order to modify it into
> something that doesn't do math. ;-)

Yeah, well ;) Its like someone using 3D-Studio MAX to produce blueprints 
of a mechanical part.

Post a reply to this message

On 2/20/2011 10:28 AM, Warp wrote:

>
>    It's not like you need to write the entire program in assembly just
> because you need to execute one asm instruction not supported by the
> language. They invented inline asm for a reason.
>

Heh. Or that rare time when you're using an API that requires the 
callbacks be naked functions and do ALL of their own handling of the 
stack and everything. (Seriously, this is a requirement of the CLR 
profiling API) Not only that, but the compiler will not form calls to 
either CDECL or STDCall functions from a naked function properly. You 
either have to modify the stack frame to work within the context of the 
function, or know darn good and well how the function you're calling is 
handled. How are arguments passed? who cleans the stack?

Fun stuff. :) Haven't had to break down to pure asm in ages. :D But, 
then it's only a couple of functions to call a stub that delegates the 
real work. it's not like I had to write pages and pages of assembly.

Post a reply to this message