D wrote:

> Russell Borogove <kaleja@estarcion.com> wrote in message
> 
>>That well known brain-damaged CPU architecture called x86 has
>>had hardware bounds-checking available since the 286. Let me
>>ask you, when writing in assembly, do you check the index
>>every time you do an indexed memory access?
>>
> 
>   Segments do not provide adequate bounds checking limits since segmetns are
> typically very large.  So essentially there is no effective bounds checking
> on pointer operations.


I'm speaking of the BOUND instruction (if I'm remembering
rightly), not segmentation.

As for the rest of your response, your mind appears to be
made up, so I see little point in debate.

-Russell B

> >   C/C++ are among the worst languages ever written.
> >
> >   I recommend immediate replacement.

<user@domain.invalid> wrote in message news:3C5FAD72.4030201@domain.invalid...
> So, were is _YOUR_ language and compiler????

I am reluctant to write one, because I don't think I can write a langauge alone that optimizes as well as existing compilers.

The really sad part about this is that C compilers are very poor optimizers and typically produce code that is 2-4 times larger and 2-4 times slower than can be produced by hand.

Truly unfortunate.

Pavel Minayev <evilone@omen.ru> wrote in message news:a3oda2$2lf1$1@digitaldaemon.com...
> Write programs in full-screen text mode. It's the way all true coders do this - and so do I =)

  Sorry that just isn't in the cares with an IDE.  Teletype coding went out
with the virtual abandonment of crap command line operating systems like
Unix and DOS.

  I've done my share of terminal mode programming.  Writing windowing
applications in terminal mode is very much like knitting using boxing
gloves.  You can do it, But no one in thier right mind would consider it.

Russell Borogove <kaleja@estarcion.com> wrote in message news:3C6010F5.2070908@estarcion.com...
> I'm speaking of the BOUND instruction (if I'm remembering
> rightly), not segmentation.
>
> As for the rest of your response, your mind appears to be made up, so I see little point in debate.

Ah, well there is a bound instruction. But the bound instruction is a separate instruction, that must be executed independently of pointer operations.  It is certainly better than performing both upper and lower bounding tests separately, but it does not represent a bounded pointer type.

It can be used to synthasize one a lower than normal level though.

The syntax for the Bound statement is

BOUND OP1,*BoundStruct

If OP1 is a 16 bit register, then

Boundstruct dw lowerlimit
                   dw upperlimit

If Op1 is a 32 bit register, then

Boundstruct dq lowerlimit
                   dq upperlimit

Bound treates OP1 as a "signed" index. so problems arrise if the address resides in the upper half of the 4 GB address space.

A 32 bit bounded pointer could be synthasized as follows

ptra      dq  0
            dq  0
            dq 1000*4


count :  xor     eax,eax                ; Clear sum
            mov   cx,1000                ; Get size of array for loop
            omov  esi, ptra                ; si = ptr to array
cntlop:  lodzx   ebx,[esi]               ; load value to add
            add     eax,ebx                ; add element to sum
            add     esi,2                     ; bump ptr
            bound   ptra+4                ; compare ptr against bounds
            loop     cntlop                 ;  proces entire array
            ret


However for true bounded ptr you would have

count :  xor         eax,eax                ; Clear sum
            mov       cx,1000                ; Get size of array for loop
            omovbp esi, ptra                ; si = ptr to array
cntlop:  lodzx     ebx[esi]                 ; load value to add
            add        eax,ebx                ; add element to sum
            add        esi,2                     ; bump ptr
            loop        cntlop                 ;  proces entire array
            ret

I know this was posted a while ago, but I can't help myself =)

D wrote:

> Consider that C omits block typing.  Those structured languages that don't
> descend from C, typically identify different kinds of blocks with different
> bracketing keywords.  Do/While, If/Endif, Repeat/Until etc.
> 
> When reading a block typed program, if the programmer sees the word "until",
> he/she knows that the statement ends a "repeat" block.
> 
> With C on the other hand the same delimiters are used for all blocks.  The
> bracket that ends a C block could be the end of an if block or any other
> kind of block.  The programmer is forced when reading the code, to search
> back through the program to find which block is being closed.   For
> convenience the strategy to combat this language failing is to progressively
> indent blocks so that the start of a block can easily be identified.  And of
> course sicne C is a free format language, we immediately run into the
> problem of people having different indention styles that typically make
> following code written by another person difficult.
> 
> The indent requirement is utter lunacy.  No language should be able to have
> it's meaning be made essentially human unreadable through a simple loss of
> indentation.
> 
> Insanity!


#define then {
#define endif }

if( i_am_insane ) then
	exit( EXIT_FAILURE );
endif

"Tom Howard" <thoward@tibco.com> wrote in message news:3C6B25BD.7040908@tibco.com...

> #define then {
> #define endif }
>
> if( i_am_insane ) then
> exit( EXIT_FAILURE );
> endif

void (helloWorld) then
  printf("Hello World!\n");
endif

Salutaciones,
                   JCAB
http://www.JCABs-Rumblings.com

A foolish nonsolution since the redefinition is not part of the standard language and has side effects.

Juan Carlos Arevalo Baeza <jcab@JCABs-Rumblings.com> wrote in message news:a4ig8q$1dti$1@digitaldaemon.com...
> "Tom Howard" <thoward@tibco.com> wrote in message news:3C6B25BD.7040908@tibco.com...
>
> > #define then {
> > #define endif }
> >
> > if( i_am_insane ) then
> > exit( EXIT_FAILURE );
> > endif
>
> void (helloWorld) then
>   printf("Hello World!\n");
> endif
>
> Salutaciones,
>                    JCAB
> http://www.JCABs-Rumblings.com
>
>
>

As someone who has had to "port" code through various versions of DOS and Windows -- without of course ever making a deliberate choice to change OS's, I wholeheartedly agree that it's moronic that 'C' defines an 'int' depending on the CPU type.

Something like the following types are the only logical answer:

int8 (unsigned 8 bit)
Sint8 (Signed 8 bit)
int16 (unsigned 16 bit)
sint16 (signed 16 bit)
int32 (unsigned 32 bits)
sint32 (Signed 32 bits)
int64 (unsigned 64 bits)
sint64 (Signed 64 bits)
int128 (Unsigned 128 bits)
sint128 (Signed 128 bits)

The same with floats: float16, float32, float64.

I'm too busy programming to have to remember how many bits are in a 'long double word float'

Clay