cpu

[Rosario1903]

Qo {7: 29}
29 Vedi, solo questo ho trovato
Dio ha fatto l�uomo retto,
ma essi cercano tanti fallaci ragionamenti.

all it is easy, it is not difficult or *to complicate*
already asm x86 32bit it is easy and the part easy of C++ to connect
is enought for all...

Buon Giorno e Buona Pasqua

[wolfgang kern]

Rosario said:

> Dio ha fatto l�uomo retto,
> ma essi cercano tanti fallaci ragionamenti.

> all it is easy, it is not difficult or *to complicate*
> already asm x86 32bit it is easy and the part easy of C++ to connect
> is enought for all...

> Buon Giorno e Buona Pasqua

BTW: I wish all believers a happy:
'Remember to a famous Jew's Zombie Day'.

I disagree for the part of "easy understable for Hll-folks".
Assembly (the langauage and the conclusion after understood) is
the only programming language which can talk to the damned holy
hardware without any doubts about shitty restricted OS-tasks.

Programmers freedom is only found in a totally free environment
and in absolutely unstricted behaviour of selected tools(period).

All else will find themselfes in either wierd or in a heavy
restricted programming world.

The only truth is found in LOGIC aside education and believe...
... and for sure nowhere else.

__
wolfgang

[Rosario1903]

On Tue, 2 Apr 2013 22:05:35 +0200, "wolfgang kern" wrote:
>Rosario said:
>> Dio ha fatto l’uomo retto,
>> ma essi cercano tanti fallaci ragionamenti.
>
>> all it is easy, it is not difficult or *to complicate*
>> already asm x86 32bit it is easy and the part easy of C++ to connect
>> is enought for all...
>
>> Buon Giorno e Buona Pasqua
>
>BTW: I wish all believers a happy:
>'Remember to a famous Jew's Zombie Day'.
>
>I disagree for the part of "easy understable for Hll-folks".
>Assembly (the langauage and the conclusion after understood) is
>the only programming language which can talk to the damned holy
>hardware

for me, first of the above, a reduced instruction set of 20-30 simple
operation in a cpu as x86 + a stack as in found in x86 cpu, it is
easier for umans too, better than hll, better than C, for all algo use
arrays, *if all operation can be indented and occupy few space in
txt.asm*

>without any doubts about shitty restricted OS-tasks.
>
>Programmers freedom is only found in a totally free environment
>and in absolutely unstricted behaviour of selected tools(period).

it exist?

>All else will find themselfes in either wierd or in a heavy
>restricted programming world.
>
>The only truth is found in LOGIC aside education and believe...
>... and for sure nowhere else.

It is not "logic", it is the what it is true

>__
>wolfgang

[Rosario1903]

On Thu, 04 Apr 2013 09:59:42 +0200, Rosario1903
<Ros...@invalid.invalid> wrote:

>On Tue, 2 Apr 2013 22:05:35 +0200, "wolfgang kern" wrote:
>>Rosario said:
>>> Dio ha fatto l’uomo retto,
>>> ma essi cercano tanti fallaci ragionamenti.
>>
>>> all it is easy, it is not difficult or *to complicate*
>>> already asm x86 32bit it is easy and the part easy of C++ to connect
>>> is enought for all...
>>
>>> Buon Giorno e Buona Pasqua
>>
>>BTW: I wish all believers a happy:
>>'Remember to a famous Jew's Zombie Day'.
>>
>>I disagree for the part of "easy understable for Hll-folks".
>>Assembly (the langauage and the conclusion after understood) is
>>the only programming language which can talk to the damned holy
>>hardware
>
>for me, first of the above, a reduced instruction set of 20-30 simple
>operation in a cpu as x86 + a stack as in found in x86 cpu, it is
>easier for umans too, better than hll, better than C, for all algo use
>arrays, *if all operation can be indented and occupy few space in
>txt.asm*

in few words, 8 32bit register, one stack, 20-30 easy operation on
these registers, one assembly language that allow indentation, where
each simple instruction is few char in the asm text
for me *it is easier for humans* than C or Hll
for algo that use arrays, if one can use one debugger

[Rosario1903]

On Thu, 04 Apr 2013 10:32:51 +0200, Rosario1903
<Ros...@invalid.invalid> wrote:

>in few words, 8 32bit register, one stack, 20-30 easy operation on
>these registers, one assembly language that allow indentation, where
>each simple instruction is few char in the asm text
>for me *it is easier for humans* than C or Hll
>for algo that use arrays, if one can use one debugger

i'm the only one that think that?

[Rosario1903]

On Thu, 04 Apr 2013 10:34:08 +0200, Rosario1903
<Ros...@invalid.invalid> wrote:

>On Thu, 04 Apr 2013 10:32:51 +0200, Rosario1903
><Ros...@invalid.invalid> wrote:
>
>>in few words, 8 32bit register, one stack, 20-30 easy operation on
>>these registers, one assembly language that allow indentation,

and multi instructions for one line

>>where
>>each simple instruction is few char in the asm text

as "c=a" for "mov ecx, eax"

[Rosario1903]

On Thu, 04 Apr 2013 10:36:15 +0200, Rosario1903

<Ros...@invalid.invalid> wrote:

>On Thu, 04 Apr 2013 10:34:08 +0200, Rosario1903
><Ros...@invalid.invalid> wrote:
>
>>On Thu, 04 Apr 2013 10:32:51 +0200, Rosario1903
>><Ros...@invalid.invalid> wrote:
>>
>>>in few words, 8 32bit register, one stack, 20-30 easy operation on
>>>these registers, one assembly language that allow indentation,
>
>and multi instructions for one line
>
>>>where
>>>each simple instruction is few char in the asm text
>
>as "c=a" for "mov ecx, eax"
>
>>>for me *it is easier for humans* than C or Hll
>>>for algo that use arrays, if one can use one debugger

this means, all mathematic algo, float point mathematic, big integers
mathematic, quick sort and ordination algos etc
all algo i see in K&R C book, are of this kind good for assembly

[Robert Wessel]

On Thu, 04 Apr 2013 12:25:18 +0200, Rosario1903

If I'm understanding you, no, almost nobody thinks that. Assembler
requires a great deal of bookkeeping work to be done manually, leaving
the details of the algorithm obscured in a sea of implementation
details. Certain simple algorithms, when implemented on a machine
with sufficient, and easy to use, resources, are only moderately more
complex in assembler than in an HLL. Basic quicksort, for example,
where the partitioning operation is a minimal amount of address
adjustment and comparison. OTOH, that's invariably a bad
implementation of quicksort, and doing quicksort properly (at a
minimum, eliminating tail recursion, shortest partition first,
median-of-three - and that's still not really adequate, IMO), you end
up with a great deal more complexity.

And obviously assembler may make something easier than a HLL. For
example, detecting overflow, or doing integer multiplication with
double width results, may be easier in assembler because those
facilities are not well exposed in the HLL, but those are rather less
common cases.

And the examples in a book like K&R2 are not really good examples of
the effect you're describing - those example are generally chosen to
be simple, and to illustrate points of the language. Heck, most of
the K&R2 samples don't even involve subroutine calls.

But in all these things the biggest factor is familiarity. A program
in any language will be hard to understand if you're not well versed
in that language.

[Rosario1903]

On Thu, 04 Apr 2013 12:25:18 +0200, Rosario1903

<Ros...@invalid.invalid> wrote:
>>>>in few words, 8 32bit register, one stack, 20-30 easy operation on
>>>>these registers, one assembly language that allow indentation,
>>
>>and multi instructions for one line
>>
>>>>where
>>>>each simple instruction is few char in the asm text
>>
>>as "c=a" for "mov ecx, eax"
>>
>>>>for me *it is easier for humans* than C or Hll
>>>>for algo that use arrays, if one can use one debugger
>
>this means, all mathematic algo, float point mathematic,

^^^^^^^^^^^^^^^^^^^^
i mean fixed point mathematic [in array of integers... ]

[Rosario1903]

On Thu, 04 Apr 2013 17:35:17 -0500, Robert Wessel wrote:
>On Thu, 04 Apr 2013 12:25:18 +0200, Rosario1903
><Ros...@invalid.invalid> wrote:

>>>>>in few words, 8 32bit register, one stack, 20-30 easy operation on
>>>>>these registers, one assembly language that allow indentation,
>>>
>>>and multi instructions for one line
>>>
>>>>>where
>>>>>each simple instruction is few char in the asm text
>>>
>>>as "c=a" for "mov ecx, eax"
>>>
>>>>>for me *it is easier for humans* than C or Hll
>>>>>for algo that use arrays, if one can use one debugger
>>
>>this means, all mathematic algo, float point mathematic, big integers
>>mathematic, quick sort and ordination algos etc
>>all algo i see in K&R C book, are of this kind good for assembly
>>
>>>>i'm the only one that think that?
>
>
>If I'm understanding you, no, almost nobody thinks that. Assembler
>requires a great deal of bookkeeping work to be done manually,

can you show one example i not understand

>leaving
>the details of the algorithm obscured in a sea of implementation
>details.

i not find what you say. one consider only one cpu with fixed
registers and fixed operation on them

>Certain simple algorithms, when implemented on a machine
>with sufficient, and easy to use, resources, are only moderately more
>complex in assembler than in an HLL.

i'm not agree

>Basic quicksort, for example,
>where the partitioning operation is a minimal amount of address
>adjustment and comparison. OTOH, that's invariably a bad
>implementation of quicksort, and doing quicksort properly (at a
>minimum, eliminating tail recursion, shortest partition first,
>median-of-three - and that's still not really adequate, IMO), you end
>up with a great deal more complexity.

in quick sort, one recursive call can be better because the stack
should be load in the right memory of the cpu
memory in the near stack could be always load because the stack memory
is reused each function one call

>And obviously assembler may make something easier than a HLL. For
>example, detecting overflow, or doing integer multiplication with
>double width results, may be easier in assembler because those
>facilities are not well exposed in the HLL, but those are rather less
>common cases.
>
>And the examples in a book like K&R2 are not really good examples of
>the effect you're describing - those example are generally chosen to
>be simple, and to illustrate points of the language. Heck, most of
>the K&R2 samples don't even involve subroutine calls.

it is full of functions...

>But in all these things the biggest factor is familiarity. A program
>in any language will be hard to understand if you're not well versed
>in that language.

i disagree

[Rosario1903]

i disagree there is something objectivly easy there

>>A program
>>in any language will be hard to understand if you're not well versed
>>in that language.
>
>i disagree

^^^^^^^^^^^^^^^^

i agree

[wolfgang kern]

"Rosario" asked:
...

>>Programmers freedom is only found in a totally free environment
>>and in absolutely unstricted behaviour of selected tools(period).
>
> it exist?

Yeah, if you write your own tools for a non-restrictive OS like
DOS 6.00 once were or much better work within your self written OS.

>>All else will find themselfes in either wierd or in a heavy
>>restricted programming world.

>>The only truth is found in LOGIC aside education and believe...
>>... and for sure nowhere else.

> It is not "logic", it is the what it is true

I may accept your believe in god, but in terms of programming issues,
the only real acceptable truth is found in how hardware is designed
to work and what's the best way to use it (just math and LOGIC).

So no guessing and no believe are required to write good code.
__
wolfgang

[wolfgang kern]

Rosario in discussion with himself :)

>>>>>in few words, 8 32bit register, one stack, 20-30 easy operation on
>>>>>these registers, one assembly language that allow indentation,

>>>and multi instructions for one line

>>>>>where
>>>>>each simple instruction is few char in the asm text

>>>as "c=a" for "mov ecx, eax"

sure right, my very own syntax decision would even call your example
above just R01=R00 (in accordance to fit other CPU-families as well).

>>>>>for me *it is easier for humans* than C or Hll
>>>>>for algo that use arrays, if one can use one debugger

>>this means, all mathematic algo, float point mathematic,
^^^^^^^^^^^^^^^^^^^^
> i mean fixed point mathematic [in array of integers... ]

>>big integers
>>mathematic, quick sort and ordination algos etc
>>all algo i see in K&R C book, are of this kind good for assembly

>>>>i'm the only one that think that?

Not at all Rosario,
sometimes your ideas were just a bit too much 'italian'-styled and
not all of the readers here and elsewhere may be able to translate
the means into working code-solutions, especially if you post your
code=snippets in your personal used syntax. (like Herbert btw.)

If I would show my preferred syntax on the net, I can bet for sure
to never see a reply to it. It's a mix of math-symbols and gipsy-
glyphs beside that it's much too terse for common mortibles :)

__
wolfgang

[Bill Leary]

"wolfgang kern" wrote in message news:kk1nsq$ihl$1...@newsreader2.utanet.at...
> ((..omitted..))
> ... but in terms of programming issues, the only real acceptable truth

> is found in how hardware is designed to work and what's the best way
> to use it (just math and LOGIC).

I've encountered cases where the way the hardware was designed to work
turned out not to be the way it actually did work. The "best" way to use it
then became a search for how to get it to work in a way which satisfied our
needs despite the fact that it didn't work as designed.

> So no guessing and no believe are required to write good code.

There was considerable guessing (but no "faith") and testing required, along
with help from the hardware vendor, to sort out what was going on.

- Bill

[Rosario1903]

if you use only few instructions 20 - 30 and not something >= 60-100
if use a terse way of represent instructions as text file
as for example "ac" -> "mov eax, ecx"
if you use one instruction separator eg "|"
if you use some form of goto or jump in instructions and
indentation and multi instruction for line
you have my reply... it is ok for me :)
Buon Giorno

[wolfgang kern]

Bill Leary replied:

>> ((..omitted..))
>> ... but in terms of programming issues, the only real acceptable truth
>> is found in how hardware is designed to work and what's the best way
>> to use it (just math and LOGIC).

> I've encountered cases where the way the hardware was designed to work
> turned out not to be the way it actually did work. The "best" way to use
> it then became a search for how to get it to work in a way which satisfied
> our needs despite the fact that it didn't work as designed.

Yes, hardware design often start with good ideas and were performed by
really good engineers, but then the merchants come along with their red
pen and strip off what could be sold apart in any future release...

>> So no guessing and no believe are required to write good code.

> There was considerable guessing (but no "faith") and testing required,
> along with help from the hardware vendor, to sort out what was going on.

Hardware design bugs are pretty rare due to CAD-support, but what we
encounter quite often (almost on a regular base) are poor/incomplete
technical documentation which lead to misinterpretation and guessing.

To create fully detailed and daubtfree manuals is for sure not easy.

__
wolfgang

[Bill Leary]

"wolfgang kern" wrote in message news:kk39rh$37u$1...@newsreader2.utanet.at...
> Bill Leary replied:

>> There was considerable guessing (but no "faith") and testing required,
>> along with help from the hardware vendor, to sort out what was going on.
>
> Hardware design bugs are pretty rare due to CAD-support, but what we
> encounter quite often (almost on a regular base) are poor/incomplete
> technical documentation which lead to misinterpretation and guessing.

Yes, but in the instances I have in mind the documentation matched the
design. That is, matched the intentions of the designers. The hardware was
screwed up. But not sufficiently screwed up to spin the silicon again.

> To create fully detailed and daubtfree manuals is for sure not easy.

At one of my previous jobs I was the one who wrote the programmers manuals /
models for each of the new chips. The hardware guys wrote the hardware
oriented manual. Registers, addressing, voltages, loads, cycle times, etc.
I wrote the software and firmware oriented manual. Registers and addressing
from the programmers point of view, objective operational characteristics,
that sort of thing. And the .h files used with the devices. It was
interesting, and let the SW guys with no HW background work with the chips.
And more than few times uncovered issues with the designs before they were
committed to silicon.

- Bill

[Tony]

In article <cmeql8d1b27v6lbvu...@4ax.com>, Ros...@invalid.invalid
says...

Yes, you are the only one. You are either being facetious or are at an extremely
elementary level of knowledge about programming. Assembly language doesn't
scale, practically, beyond small programs. It has its place, but general purpose
software development (whatever that is) is not it, in most cases. I say that
without even considering that assembly language is hardware-specific, which is
many times not a good thing.

[Rosario1903]

On Fri, 19 Apr 2013 01:08:59 -0500, Tony <a...@some.org> wrote:

>In article <cmeql8d1b27v6lbvu...@4ax.com>, Ros...@invalid.invalid
>says...
>>
>> On Thu, 04 Apr 2013 10:32:51 +0200, Rosario1903
>> <Ros...@invalid.invalid> wrote:
>>
>> >in few words, 8 32bit register, one stack, 20-30 easy operation on
>> >these registers, one assembly language that allow indentation, where
>> >each simple instruction is few char in the asm text
>> >for me *it is easier for humans* than C or Hll
>> >for algo that use arrays, if one can use one debugger
>>
>> i'm the only one that think that?
>
>Yes, you are the only one. You are either being facetious or are at an extremely
>elementary level of knowledge about programming.

> Assembly language doesn't
>scale, practically, beyond small programs.

i not agree

[Robert Wessel]

On Sat, 20 Apr 2013 11:27:58 +0200, Rosario1903
<Ros...@invalid.invalid> wrote:

>On Fri, 19 Apr 2013 01:08:59 -0500, Tony <a...@some.org> wrote:
>
>>In article <cmeql8d1b27v6lbvu...@4ax.com>, Ros...@invalid.invalid
>>says...
>>>
>>> On Thu, 04 Apr 2013 10:32:51 +0200, Rosario1903
>>> <Ros...@invalid.invalid> wrote:
>>>
>>> >in few words, 8 32bit register, one stack, 20-30 easy operation on
>>> >these registers, one assembly language that allow indentation, where
>>> >each simple instruction is few char in the asm text
>>> >for me *it is easier for humans* than C or Hll
>>> >for algo that use arrays, if one can use one debugger
>>>
>>> i'm the only one that think that?
>>
>>Yes, you are the only one. You are either being facetious or are at an extremely
>>elementary level of knowledge about programming.
>
>> Assembly language doesn't
>>scale, practically, beyond small programs.
>
>i not agree

Fine. Perhaps you'd care to actually put some substance in your
argument.

The major reason that assembler is not used for large scale projects
is productivity. It's been known since the sixties that programmers
show a roughly consistent level of productivity in terms in LOCs/time,
*independent* of language*. If a HLL allows you to build a program
with a quarter as many lines as the same project in assembler, the
reduction in (expensive) programmer hours is dramatic.

IOW, as a first-order approximation, the most productive language is
the one that allows the programmer to write the fewest LOCs.

And there are other considerations, too, of course, portability, long
term maintainability, tool chains, etc., many of which favor HLLs too.


*Sure there are exceptions, particularly for highly domain-focused
languages.

[Rosario1903]

On Fri, 19 Apr 2013 01:08:59 -0500, Tony <a...@some.org> wrote:

>In article <cmeql8d1b27v6lbvu...@4ax.com>, Ros...@invalid.invalid
>says...
>>
>> On Thu, 04 Apr 2013 10:32:51 +0200, Rosario1903
>> <Ros...@invalid.invalid> wrote:
>>
>> >in few words, 8 32bit register, one stack, 20-30 easy operation on
>> >these registers, one assembly language that allow indentation, where
>> >each simple instruction is few char in the asm text
>> >for me *it is easier for humans* than C or Hll
>> >for algo that use arrays, if one can use one debugger
>>
>> i'm the only one that think that?
>
>Yes, you are the only one.

no, someone think that too, or said that

>You are either being facetious or are at an extremely
>elementary level of knowledge about programming.

i think not

>Assembly language doesn't
>scale, practically, beyond small programs.

this is false

[Rosario1903]

On Wed, 24 Apr 2013 18:21:45 +0200, Rosario1903
<Ros...@invalid.invalid> wrote:

>On Fri, 19 Apr 2013 01:08:59 -0500, Tony <a...@some.org> wrote:
>
>>In article <cmeql8d1b27v6lbvu...@4ax.com>, Ros...@invalid.invalid
>>says...
>>>
>>> On Thu, 04 Apr 2013 10:32:51 +0200, Rosario1903
>>> <Ros...@invalid.invalid> wrote:
>>>
>>> >in few words, 8 32bit register, one stack, 20-30 easy operation on
>>> >these registers, one assembly language that allow indentation, where
>>> >each simple instruction is few char in the asm text
>>> >for me *it is easier for humans* than C or Hll
>>> >for algo that use arrays, if one can use one debugger
>>>
>>> i'm the only one that think that?
>>
>>Yes, you are the only one.
>
>no, someone think that too, or said that

Betov

[Melzzzzz]

On Fri, 19 Apr 2013 01:08:59 -0500

Tony <a...@some.org> wrote:

> Assembly language doesn't scale, practically, beyond small programs.

What you mean by this?