Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #171171 > unrolled thread

how many lines you coded?

Back to article view | Back to comp.lang.c

Contents

  how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-23 10:29 -0700
    Re: how many lines you coded? Bart <bc@freeuk.com> - 2023-07-23 18:44 +0100
      Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-23 11:12 -0700
    Re: how many lines you coded? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 20:32 +0200
      Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-23 11:51 -0700
        Re: how many lines you coded? Bonita Montero <Bonita.Montero@gmail.com> - 2023-07-23 21:18 +0200
          Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 05:10 -0700
            Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 05:19 -0700
              Re: how many lines you coded? Richard Harnden <richard.nospam@gmail.com> - 2023-07-24 13:45 +0100
                Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 05:51 -0700
                  Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 06:44 -0700
                    Re: how many lines you coded? Richard Harnden <richard.nospam@gmail.com> - 2023-07-24 15:36 +0100
                      Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 07:40 -0700
                  Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 07:29 -0700
                    Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 07:39 -0700
                    Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 02:34 -0700
      Re: how many lines you coded? Vir Campestris <vir.campestris@invalid.invalid> - 2023-07-23 20:48 +0100
        Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-23 13:29 -0700
        Re: how many lines you coded? David Brown <david.brown@hesbynett.no> - 2023-07-24 09:02 +0200
          Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 00:27 -0700
            Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 00:35 -0700
              Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 00:45 -0700
                Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 01:18 -0700
                  Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 01:19 -0700
          Re: how many lines you coded? Bart <bc@freeuk.com> - 2023-07-24 11:21 +0100
            Re: how many lines you coded? David Brown <david.brown@hesbynett.no> - 2023-07-24 20:01 +0200
              Re: how many lines you coded? scott@slp53.sl.home (Scott Lurndal) - 2023-07-24 18:20 +0000
                Re: how many lines you coded? Bart <bc@freeuk.com> - 2023-07-24 20:49 +0100
                  Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 13:13 -0700
                    Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-24 13:22 -0700
            Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 08:51 -0700
              Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 09:16 -0700
              Re: how many lines you coded? Bart <bc@freeuk.com> - 2023-07-25 18:48 +0100
                Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 11:13 -0700
                  Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 11:26 -0700
                    Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 11:34 -0700
                      Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 11:46 -0700
                        Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 12:02 -0700
                  Re: how many lines you coded? Bart <bc@freeuk.com> - 2023-07-25 22:14 +0100
                    Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 14:35 -0700
                      Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 15:31 -0700
    Re: how many lines you coded? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-23 12:42 -0700
      Re: how many lines you coded? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-25 20:36 -0700
        Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-26 01:44 -0700
    Re: how many lines you coded? John McCue <jmccue@fuzzball.jmcunx.com> - 2023-07-25 20:26 +0000
      Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-25 14:52 -0700
    Re: how many lines you coded? Ed Prochak <edprochak@gmail.com> - 2023-07-26 08:04 -0700
      Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-27 01:16 -0700
        Re: how many lines you coded? Ed Prochak <edprochak@gmail.com> - 2023-07-30 21:38 -0700
    Re: how many lines you coded? Lynn McGuire <lynnmcguire5@gmail.com> - 2023-07-28 19:53 -0500
      Re: how many lines you coded? Ed Prochak <edprochak@gmail.com> - 2023-07-30 21:40 -0700
        Re: how many lines you coded? scott@slp53.sl.home (Scott Lurndal) - 2023-07-31 14:54 +0000
          Re: how many lines you coded? Lynn McGuire <lynnmcguire5@gmail.com> - 2023-07-31 23:22 -0500
    Re: how many lines you coded? aph@littlepinkcloud.invalid - 2023-07-31 09:29 +0000
      Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-31 05:10 -0700
        Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-31 05:16 -0700
          Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-31 05:36 -0700
            Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-31 07:00 -0700
        Re: how many lines you coded? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-07-31 05:27 -0700
          Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-31 05:41 -0700
            Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-31 05:51 -0700
              Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-07-31 05:59 -0700
          Re: how many lines you coded? aph@littlepinkcloud.invalid - 2023-08-04 17:57 +0000
            Re: how many lines you coded? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 11:05 -0700
              Re: how many lines you coded? scott@slp53.sl.home (Scott Lurndal) - 2023-08-04 19:03 +0000
                Re: how many lines you coded? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-04 12:24 -0700
                  Re: how many lines you coded? gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-04 19:27 +0000
                Was Dijkstra a "lefty" ? (Was: how many lines you coded?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-04 19:26 +0000
                  Re: Was Dijkstra a "lefty" ? (Was: how many lines you coded?) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-04 13:54 -0700
                Re: how many lines you coded? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-04 19:47 -0700
                  Again, OT is OT! (Was: how many lines you coded?) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-05 03:51 +0000
                  Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-08-05 03:39 -0700
              [OT, Sorry] Re: how many lines you coded? aph@littlepinkcloud.invalid - 2023-08-05 03:02 +0000
            Re: how many lines you coded? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-04 19:41 +0000
    Re: how many lines you coded? jak <nospam@please.ty> - 2023-08-01 18:09 +0200
      Re: how many lines you coded? fir <profesor.fir@gmail.com> - 2023-08-01 10:17 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#171193

poniedziałek, 24 lipca 2023 o 09:27:49 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 09:02:40 UTC+2 David Brown napisał(a): 
> > On 23/07/2023 21:48, Vir Campestris wrote: 
> > > On 23/07/2023 19:32, Bonita Montero wrote: 
> > >> For sure in assembly, because that's easier to learn than C. 😉 
> > > 
> > > Yes, but which assembler? 
> > > 
> > > I've used perhaps a dozen. Perhaps because it depends on things like 
> > > whether a '286 counts as different to an 8086. 
> > > 
> > I have also used at least a dozen assembly languages - and that is /not/ 
> > counting variations such as 8086/80286. (I haven't actually written any 
> > x86 assembly.) 
> > 
> > And while some are easy to learn, others are very far from simple - 
> > especially if you want to get efficient results. 
> > > I have no clue how many lines of code I've written. Not even the vaguest 
> > > idea. 
> > >
> code is a tree assembler is good for the 'leafs' but not for the composition of thousands of them (today compiler manages the leafs).. i n fact is better to manage the thin branches (wtwigs) but i 
> think from some time it has a lack of the bigger branches.. 
> im not sure in quite new part of the language wouldnt be needed 
> (to ba able to manage those twigs) 
> 
> one think is the big picture of code in c is not clearly showed, 
> the second is sometimes someone need to write a big doze 
> of switches which is tiring and probbaly it would be better to have some pattern for this

so i could try to see it c is second assembly on higher level (not mnemonics but on level of functions) and need some second c to be able to get away of the procedures assembly (oop is obviously no way for that..it would be rather need of some kind of discovered predefined patterns or a way of composition of them.. i dont get much idea for that though)

[toc] | [prev] | [next] | [standalone]

#171194

poniedziałek, 24 lipca 2023 o 09:35:23 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 09:27:49 UTC+2 fir napisał(a): 
> > poniedziałek, 24 lipca 2023 o 09:02:40 UTC+2 David Brown napisał(a): 
> > > On 23/07/2023 21:48, Vir Campestris wrote: 
> > > > On 23/07/2023 19:32, Bonita Montero wrote: 
> > > >> For sure in assembly, because that's easier to learn than C. 😉 
> > > > 
> > > > Yes, but which assembler? 
> > > > 
> > > > I've used perhaps a dozen. Perhaps because it depends on things like 
> > > > whether a '286 counts as different to an 8086. 
> > > > 
> > > I have also used at least a dozen assembly languages - and that is /not/ 
> > > counting variations such as 8086/80286. (I haven't actually written any 
> > > x86 assembly.) 
> > > 
> > > And while some are easy to learn, others are very far from simple - 
> > > especially if you want to get efficient results. 
> > > > I have no clue how many lines of code I've written. Not even the vaguest 
> > > > idea. 
> > > > 
> > code is a tree assembler is good for the 'leafs' but not for the composition of thousands of them (today compiler manages the leafs).. i n fact is better to manage the thin branches (wtwigs) but i 
> > think from some time it has a lack of the bigger branches.. 
> > im not sure in quite new part of the language wouldnt be needed 
> > (to ba able to manage those twigs) 
> > 
> > one think is the big picture of code in c is not clearly showed, 
> > the second is sometimes someone need to write a big doze 
> > of switches which is tiring and probbaly it would be better to have some pattern for this
> so i could try to see it c is second assembly on higher level (not mnemonics but on level of functions) and need some second c to be able to get away of the procedures assembly (oop is obviously no way for that..it would be rather need of some kind of discovered predefined patterns or a way of composition of them.. i dont get much idea for that though)

agent paradigm could be somewhat for that (model of twigs composition), though probably some other also could be found 

i eventually could rethink it in a context of my game i now write whan i feel the pain of what i was writing : 'distruibuted' code (code that is distributed on 15 places where ading something mekes big slowdowns of finding that places blindly and jumping among them)

[toc] | [prev] | [next] | [standalone]

#171197

poniedziałek, 24 lipca 2023 o 09:45:43 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 09:35:23 UTC+2 fir napisał(a):
> > poniedziałek, 24 lipca 2023 o 09:27:49 UTC+2 fir napisał(a): 
> > > poniedziałek, 24 lipca 2023 o 09:02:40 UTC+2 David Brown napisał(a): 
> > > > On 23/07/2023 21:48, Vir Campestris wrote: 
> > > > > On 23/07/2023 19:32, Bonita Montero wrote: 
> > > > >> For sure in assembly, because that's easier to learn than C. 😉 
> > > > > 
> > > > > Yes, but which assembler? 
> > > > > 
> > > > > I've used perhaps a dozen. Perhaps because it depends on things like 
> > > > > whether a '286 counts as different to an 8086. 
> > > > > 
> > > > I have also used at least a dozen assembly languages - and that is /not/ 
> > > > counting variations such as 8086/80286. (I haven't actually written any 
> > > > x86 assembly.) 
> > > > 
> > > > And while some are easy to learn, others are very far from simple - 
> > > > especially if you want to get efficient results. 
> > > > > I have no clue how many lines of code I've written. Not even the vaguest 
> > > > > idea. 
> > > > > 
> > > code is a tree assembler is good for the 'leafs' but not for the composition of thousands of them (today compiler manages the leafs).. i n fact is better to manage the thin branches (wtwigs) but i 
> > > think from some time it has a lack of the bigger branches.. 
> > > im not sure in quite new part of the language wouldnt be needed 
> > > (to ba able to manage those twigs) 
> > > 
> > > one think is the big picture of code in c is not clearly showed, 
> > > the second is sometimes someone need to write a big doze 
> > > of switches which is tiring and probbaly it would be better to have some pattern for this 
> > so i could try to see it c is second assembly on higher level (not mnemonics but on level of functions) and need some second c to be able to get away of the procedures assembly (oop is obviously no way for that..it would be rather need of some kind of discovered predefined patterns or a way of composition of them.. i dont get much idea for that though)
> agent paradigm could be somewhat for that (model of twigs composition), though probably some other also could be found 
> 
> i eventually could rethink it in a context of my game i now write whan i feel the pain of what i was writing : 'distruibuted' code (code that is distributed on 15 places where ading something mekes big slowdowns of finding that places blindly and jumping among them)

writing a  game i noticed for example this problem:

in game you generally got a window that shows a fragment of space and a lot of agents of various types:
- ai-driven ships of variuos tipes
- your ship
- asteroids of varius types
- bases of varius types
- portals
- bulets/rockets

there is a problem if put it in separate arrays or in common
in fact i think it is better to put this in common, (the reason is the
putting it in common my be good for thsi code distruibution problem,
i mean separate arrays make more branchhes (in some way, at leest it seems so) thus gives more problem with code distribution and code jumping)  but there are 2 problems in my case:
1) player ship has much more fields then rest 
2) bullts may be many as i use some for particle efects for
explosions - they are short living but my temporary rise the sise of an array - becouse code for collision has square complexity it is unfortunate to make say 2000x2000 iteration loop 

the rest i put in third array so i got 3: player ship, agents and bullets
(more strict i got 4 as i put portals in separate but it was a mistake i guess but to tired to revrite - though i also maybe not sure as protals
are spreaded on worlds, as i not mention those agents/bullets i got in each world separate, in code i switch pointers to current)

funny is the player ship indeed make big separate branch - contained in few separate .c files , where it this code for this branch is partially same as in agents, becouse player ship colides with things where agents colide too - so now im not sure if this was not a mistake
i probably should put player ship as agent and only give additional structure player_specific this posibly could reduce branch

as to bullets it is probebly less problem to keep it in separate, though it makes soem aditional branching, but the cost of increasing this agents array size is to big i guess

(i know btw what i said is not on topic of new high-level composition but this is on old composition yet)

today new thing come to my mind: maybe i should use two dimensional array (array of arrays, i mena not to two dimensional but two indexed agent[n][i]) - this way i could separate subtypes as n
(speeding some iterations) 
but not making maybe outburst of branching to much

[toc] | [prev] | [next] | [standalone]

#171198

some could comment if also fights with this 1-container or more- containers problem

[toc] | [prev] | [next] | [standalone]

#171201

On 24/07/2023 08:02, David Brown wrote:
 > On 23/07/2023 21:48, Vir Campestris wrote:
 >> On 23/07/2023 19:32, Bonita Montero wrote:
 >>> For sure in assembly, because that's easier to learn than C. 😉
 >>
 >> Yes, but which assembler?
 >>
 >> I've used perhaps a dozen. Perhaps because it depends on things like
 >> whether a '286 counts as different to an 8086.
 >>
 >
 > I have also used at least a dozen assembly languages - and that is /not/
 > counting variations such as 8086/80286.  (I haven't actually written any
 > x86 assembly.)

If you haven't used x86, then the variations don't matter?

I can list not quite a dozen varieties, if I include ones where I've 
only written a few lines, but I count the x86 versions separately:

  +  pdp10
     digico m16v
     pdp11       (used once to get some driver working)
     6800        (the only big-endian machine I've used!)
  *+ z80
  *+ 8088/6
  *  80188/6
  *  8035 or 8051
  *+ 80386
  *+ x64
     arm32

* means I either wrote a standalone assembler, or an inline one for a 
HLL, or both. That doesn't rule out using someone else's assembler at 
some point.

+ means I've used it as a compiler target

(80188/6 is an enhanced version of 8088/6 with integrated peripherals 
that have dedicated instructions.)

80386 has a different set of address modes from 8086, and non-segmented 
memory in non-real mode.

x64 has extra GP registers, SIMD etc. My syntax for it differs from 
standard.

(I don't include the ones I've coded only on paper, to see how they 
might work as compiler targets.)

[toc] | [prev] | [next] | [standalone]

#171221

On 24/07/2023 12:21, Bart wrote:
> On 24/07/2023 08:02, David Brown wrote:
>  > On 23/07/2023 21:48, Vir Campestris wrote:
>  >> On 23/07/2023 19:32, Bonita Montero wrote:
>  >>> For sure in assembly, because that's easier to learn than C. 😉
>  >>
>  >> Yes, but which assembler?
>  >>
>  >> I've used perhaps a dozen. Perhaps because it depends on things like
>  >> whether a '286 counts as different to an 8086.
>  >>
>  >
>  > I have also used at least a dozen assembly languages - and that is /not/
>  > counting variations such as 8086/80286.  (I haven't actually written any
>  > x86 assembly.)
> 
> If you haven't used x86, then the variations don't matter?
> 

I meant not counting similar assemblies in the devices I /have/ used. 
For example, the PowerPC assembly on the devices I have used is not 
identical, the two m68k devices I have used had a fair number of 
differences, and so on.

> I can list not quite a dozen varieties, if I include ones where I've 
> only written a few lines, but I count the x86 versions separately:
> 
>   +  pdp10
>      digico m16v
>      pdp11       (used once to get some driver working)
>      6800        (the only big-endian machine I've used!)
>   *+ z80
>   *+ 8088/6
>   *  80188/6
>   *  8035 or 8051
>   *+ 80386
>   *+ x64
>      arm32

A fine selection.

[toc] | [prev] | [next] | [standalone]

#171223

David Brown <david.brown@hesbynett.no> writes:
>On 24/07/2023 12:21, Bart wrote:
>> On 24/07/2023 08:02, David Brown wrote:
>>  > On 23/07/2023 21:48, Vir Campestris wrote:
>>  >> On 23/07/2023 19:32, Bonita Montero wrote:
>>  >>> For sure in assembly, because that's easier to learn than C. 😉
>>  >>
>>  >> Yes, but which assembler?
>>  >>
>>  >> I've used perhaps a dozen. Perhaps because it depends on things like
>>  >> whether a '286 counts as different to an 8086.
>>  >>
>>  >
>>  > I have also used at least a dozen assembly languages - and that is /not/
>>  > counting variations such as 8086/80286.  (I haven't actually written any
>>  > x86 assembly.)
>> 
>> If you haven't used x86, then the variations don't matter?
>> 
>
>I meant not counting similar assemblies in the devices I /have/ used. 
>For example, the PowerPC assembly on the devices I have used is not 
>identical, the two m68k devices I have used had a fair number of 
>differences, and so on.
>
>> I can list not quite a dozen varieties, if I include ones where I've 
>> only written a few lines, but I count the x86 versions separately:
>> 
>>   +  pdp10
>>      digico m16v
>>      pdp11       (used once to get some driver working)
>>      6800        (the only big-endian machine I've used!)
>>   *+ z80
>>   *+ 8088/6
>>   *  80188/6
>>   *  8035 or 8051
>>   *+ 80386
>>   *+ x64
>>      arm32
>
>A fine selection.
>

Although I would qualify the "number of lines of code written" with
the condition that it be code that ran in production, rather than
hobby projects.   I've played with a number of assemblers over time,
but as for code in production only the VAX (Macro32), Burroughs
(SPRASM), x86, x86-64, M88100 and ARM64 would count as production
code.

I get the impression that much of Barts code is personal projects.

[toc] | [prev] | [next] | [standalone]

#171228

On 24/07/2023 19:20, Scott Lurndal wrote:
 > David Brown <david.brown@hesbynett.no> writes:
 >> On 24/07/2023 12:21, Bart wrote:
 >>> On 24/07/2023 08:02, David Brown wrote:
 >>>   > On 23/07/2023 21:48, Vir Campestris wrote:
 >>>   >> On 23/07/2023 19:32, Bonita Montero wrote:
 >>>   >>> For sure in assembly, because that's easier to learn than C. 😉
 >>>   >>
 >>>   >> Yes, but which assembler?
 >>>   >>
 >>>   >> I've used perhaps a dozen. Perhaps because it depends on 
things like
 >>>   >> whether a '286 counts as different to an 8086.
 >>>   >>
 >>>   >
 >>>   > I have also used at least a dozen assembly languages - and that 
is /not/
 >>>   > counting variations such as 8086/80286.  (I haven't actually 
written any
 >>>   > x86 assembly.)
 >>>
 >>> If you haven't used x86, then the variations don't matter?
 >>>
 >>
 >> I meant not counting similar assemblies in the devices I /have/ used.
 >> For example, the PowerPC assembly on the devices I have used is not
 >> identical, the two m68k devices I have used had a fair number of
 >> differences, and so on.
 >>
 >>> I can list not quite a dozen varieties, if I include ones where I've
 >>> only written a few lines, but I count the x86 versions separately:
 >>>
 >>>    +  pdp10
 >>>       digico m16v
 >>>       pdp11       (used once to get some driver working)
 >>>       6800        (the only big-endian machine I've used!)
 >>>    *+ z80
 >>>    *+ 8088/6
 >>>    *  80188/6
 >>>    *  8035 or 8051
 >>>    *+ 80386
 >>>    *+ x64
 >>>       arm32
 >>
 >> A fine selection.
 >>
 >
 > Although I would qualify the "number of lines of code written" with
 > the condition that it be code that ran in production, rather than
 > hobby projects.   I've played with a number of assemblers over time,
 > but as for code in production only the VAX (Macro32), Burroughs
 > (SPRASM), x86, x86-64, M88100 and ARM64 would count as production
 > code.
 >
 > I get the impression that much of Barts code is personal projects.

The first software I did for the IBM PC was either written in assembly 
(it would have used my assembler), or was written in my HLL implemented 
with that assembler, which would still have used considerable amounts of 
inline assembly.

I can't remember exactly nearly 4 decades on (it was also during a 
process of moving development over from Z80 systems).

I do remember we sold around $1m of that product, in mid-1980s terms, 
for an app that took me 2 months to write.

Overall, we probably sold $10m of software written entirely using my 
'hobby' languages, over a period of around 15 years, much to OEMs who 
provided their own added-value additions.

[toc] | [prev] | [next] | [standalone]

#171229

poniedziałek, 24 lipca 2023 o 21:49:24 UTC+2 Bart napisał(a):
> On 24/07/2023 19:20, Scott Lurndal wrote: 
> > David Brown <david...@hesbynett.no> writes: 
> >> On 24/07/2023 12:21, Bart wrote: 
> >>> On 24/07/2023 08:02, David Brown wrote: 
> >>> > On 23/07/2023 21:48, Vir Campestris wrote: 
> >>> >> On 23/07/2023 19:32, Bonita Montero wrote: 
> >>> >>> For sure in assembly, because that's easier to learn than C. 😉 
> >>> >> 
> >>> >> Yes, but which assembler? 
> >>> >> 
> >>> >> I've used perhaps a dozen. Perhaps because it depends on 
> things like 
> >>> >> whether a '286 counts as different to an 8086. 
> >>> >> 
> >>> > 
> >>> > I have also used at least a dozen assembly languages - and that 
> is /not/ 
> >>> > counting variations such as 8086/80286. (I haven't actually 
> written any 
> >>> > x86 assembly.) 
> >>> 
> >>> If you haven't used x86, then the variations don't matter? 
> >>> 
> >> 
> >> I meant not counting similar assemblies in the devices I /have/ used. 
> >> For example, the PowerPC assembly on the devices I have used is not 
> >> identical, the two m68k devices I have used had a fair number of 
> >> differences, and so on. 
> >> 
> >>> I can list not quite a dozen varieties, if I include ones where I've 
> >>> only written a few lines, but I count the x86 versions separately: 
> >>> 
> >>> + pdp10 
> >>> digico m16v 
> >>> pdp11 (used once to get some driver working) 
> >>> 6800 (the only big-endian machine I've used!) 
> >>> *+ z80 
> >>> *+ 8088/6 
> >>> * 80188/6 
> >>> * 8035 or 8051 
> >>> *+ 80386 
> >>> *+ x64 
> >>> arm32 
> >> 
> >> A fine selection. 
> >> 
> > 
> > Although I would qualify the "number of lines of code written" with 
> > the condition that it be code that ran in production, rather than 
> > hobby projects. I've played with a number of assemblers over time, 
> > but as for code in production only the VAX (Macro32), Burroughs 
> > (SPRASM), x86, x86-64, M88100 and ARM64 would count as production 
> > code. 
> > 
> > I get the impression that much of Barts code is personal projects.
> The first software I did for the IBM PC was either written in assembly 
> (it would have used my assembler), or was written in my HLL implemented 
> with that assembler, which would still have used considerable amounts of 
> inline assembly. 
> 
> I can't remember exactly nearly 4 decades on (it was also during a 
> process of moving development over from Z80 systems). 
> 
> I do remember we sold around $1m of that product, in mid-1980s terms, 
> for an app that took me 2 months to write. 
> 
> Overall, we probably sold $10m of software written entirely using my 
> 'hobby' languages, over a period of around 15 years, much to OEMs who 
> provided their own added-value additions.

back then i think it was easier to be a programmer aspaclelly asm/c type of programmer like i am too.. from that respect i would like to have 25 years in 1980s and write code ...now the world is totally diferent the thing i mentioned to bonita plays the role - populity/ market populism, the lot of so called peasants come into domain and flod the world with peasant shit

[toc] | [prev] | [next] | [standalone]

#171230

poniedziałek, 24 lipca 2023 o 22:13:52 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 21:49:24 UTC+2 Bart napisał(a): 
> > On 24/07/2023 19:20, Scott Lurndal wrote: 
> > > David Brown <david...@hesbynett.no> writes: 
> > >> On 24/07/2023 12:21, Bart wrote: 
> > >>> On 24/07/2023 08:02, David Brown wrote: 
> > >>> > On 23/07/2023 21:48, Vir Campestris wrote: 
> > >>> >> On 23/07/2023 19:32, Bonita Montero wrote: 
> > >>> >>> For sure in assembly, because that's easier to learn than C. 😉 
> > >>> >> 
> > >>> >> Yes, but which assembler? 
> > >>> >> 
> > >>> >> I've used perhaps a dozen. Perhaps because it depends on 
> > things like 
> > >>> >> whether a '286 counts as different to an 8086. 
> > >>> >> 
> > >>> > 
> > >>> > I have also used at least a dozen assembly languages - and that 
> > is /not/ 
> > >>> > counting variations such as 8086/80286. (I haven't actually 
> > written any 
> > >>> > x86 assembly.) 
> > >>> 
> > >>> If you haven't used x86, then the variations don't matter? 
> > >>> 
> > >> 
> > >> I meant not counting similar assemblies in the devices I /have/ used. 
> > >> For example, the PowerPC assembly on the devices I have used is not 
> > >> identical, the two m68k devices I have used had a fair number of 
> > >> differences, and so on. 
> > >> 
> > >>> I can list not quite a dozen varieties, if I include ones where I've 
> > >>> only written a few lines, but I count the x86 versions separately: 
> > >>> 
> > >>> + pdp10 
> > >>> digico m16v 
> > >>> pdp11 (used once to get some driver working) 
> > >>> 6800 (the only big-endian machine I've used!) 
> > >>> *+ z80 
> > >>> *+ 8088/6 
> > >>> * 80188/6 
> > >>> * 8035 or 8051 
> > >>> *+ 80386 
> > >>> *+ x64 
> > >>> arm32 
> > >> 
> > >> A fine selection. 
> > >> 
> > > 
> > > Although I would qualify the "number of lines of code written" with 
> > > the condition that it be code that ran in production, rather than 
> > > hobby projects. I've played with a number of assemblers over time, 
> > > but as for code in production only the VAX (Macro32), Burroughs 
> > > (SPRASM), x86, x86-64, M88100 and ARM64 would count as production 
> > > code. 
> > > 
> > > I get the impression that much of Barts code is personal projects. 
> > The first software I did for the IBM PC was either written in assembly 
> > (it would have used my assembler), or was written in my HLL implemented 
> > with that assembler, which would still have used considerable amounts of 
> > inline assembly. 
> > 
> > I can't remember exactly nearly 4 decades on (it was also during a 
> > process of moving development over from Z80 systems). 
> > 
> > I do remember we sold around $1m of that product, in mid-1980s terms, 
> > for an app that took me 2 months to write. 
> > 
> > Overall, we probably sold $10m of software written entirely using my 
> > 'hobby' languages, over a period of around 15 years, much to OEMs who 
> > provided their own added-value additions.
> back then i think it was easier to be a programmer aspaclelly asm/c type of programmer like i am too.. from that respect i would like to have 25 years in 1980s and write code ...now the world is totally diferent the thing i mentioned to bonita plays the role - populity/ market populism, the lot of so called peasants come into domain and flod the world with peasant shit

i myself write 'hobbustically' (i also hobbystically do 'science' (of c language and programming theory, and i find myslelf better scientist then programmer) but this hobbystically is not necessary bad unlike what peasants/ponys (commoners or commonists) think

work in company has terrible and obvious disadvantages.. sometimes you cooperate with terrible stupid people (sometimes not but its random)..the companies dont understand that to work good you need fully manage you resting becouse you know the best..overally also ideas what to code and how may be mighty stupid ...so terrible amount of energy is wasted on side things not core coding

thets sad reality probably many are more or less aware ;c
(generally this world is in terrible state anyway)

[toc] | [prev] | [next] | [standalone]

#171239

poniedziałek, 24 lipca 2023 o 12:21:45 UTC+2 Bart napisał(a):
> On 24/07/2023 08:02, David Brown wrote: 
> > On 23/07/2023 21:48, Vir Campestris wrote: 
> >> On 23/07/2023 19:32, Bonita Montero wrote: 
> >>> For sure in assembly, because that's easier to learn than C. 😉 
> >> 
> >> Yes, but which assembler? 
> >> 
> >> I've used perhaps a dozen. Perhaps because it depends on things like 
> >> whether a '286 counts as different to an 8086. 
> >> 
> > 
> > I have also used at least a dozen assembly languages - and that is /not/ 
> > counting variations such as 8086/80286. (I haven't actually written any 
> > x86 assembly.)
> If you haven't used x86, then the variations don't matter? 
> 
> I can list not quite a dozen varieties, if I include ones where I've 
> only written a few lines, but I count the x86 versions separately: 
> 
> + pdp10 
> digico m16v 
> pdp11 (used once to get some driver working) 
> 6800 (the only big-endian machine I've used!) 
> *+ z80 
> *+ 8088/6 
> * 80188/6 
> * 8035 or 8051 
> *+ 80386 
> *+ x64 
> arm32 
> 
> * means I either wrote a standalone assembler, or an inline one for a 
> HLL, or both. That doesn't rule out using someone else's assembler at 
> some point. 
> 
> + means I've used it as a compiler target 
> 
> (80188/6 is an enhanced version of 8088/6 with integrated peripherals 
> that have dedicated instructions.) 
> 
> 80386 has a different set of address modes from 8086, and non-segmented 
> memory in non-real mode. 
> 
> x64 has extra GP registers, SIMD etc. My syntax for it differs from 
> standard. 
> 
> (I don't include the ones I've coded only on paper, to see how they 
> might work as compiler targets.)

btw you once talked about compilations speed..could you give that numbers? as i dont remember which one thread it was..

i can do basic measuring of assembly speed

[toc] | [prev] | [next] | [standalone]

#171240

wtorek, 25 lipca 2023 o 17:51:10 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 12:21:45 UTC+2 Bart napisał(a): 
> > On 24/07/2023 08:02, David Brown wrote: 
> > > On 23/07/2023 21:48, Vir Campestris wrote: 
> > >> On 23/07/2023 19:32, Bonita Montero wrote: 
> > >>> For sure in assembly, because that's easier to learn than C. 😉 
> > >> 
> > >> Yes, but which assembler? 
> > >> 
> > >> I've used perhaps a dozen. Perhaps because it depends on things like 
> > >> whether a '286 counts as different to an 8086. 
> > >> 
> > > 
> > > I have also used at least a dozen assembly languages - and that is /not/ 
> > > counting variations such as 8086/80286. (I haven't actually written any 
> > > x86 assembly.) 
> > If you haven't used x86, then the variations don't matter? 
> > 
> > I can list not quite a dozen varieties, if I include ones where I've 
> > only written a few lines, but I count the x86 versions separately: 
> > 
> > + pdp10 
> > digico m16v 
> > pdp11 (used once to get some driver working) 
> > 6800 (the only big-endian machine I've used!) 
> > *+ z80 
> > *+ 8088/6 
> > * 80188/6 
> > * 8035 or 8051 
> > *+ 80386 
> > *+ x64 
> > arm32 
> > 
> > * means I either wrote a standalone assembler, or an inline one for a 
> > HLL, or both. That doesn't rule out using someone else's assembler at 
> > some point. 
> > 
> > + means I've used it as a compiler target 
> > 
> > (80188/6 is an enhanced version of 8088/6 with integrated peripherals 
> > that have dedicated instructions.) 
> > 
> > 80386 has a different set of address modes from 8086, and non-segmented 
> > memory in non-real mode. 
> > 
> > x64 has extra GP registers, SIMD etc. My syntax for it differs from 
> > standard. 
> > 
> > (I don't include the ones I've coded only on paper, to see how they 
> > might work as compiler targets.)
> btw you once talked about compilations speed..could you give that numbers? as i dont remember which one thread it was.. 
> 
> i can do basic measuring of assembly speed

i tested for some simple piece of 1.2 MB source and het a result of 166 ms this is 7MB/s (the output exe is 283KB).. this would need
hovver more tests as i dont remember is some parts of thsi assembly (lieke adding new jumps of labels not take more time, here i put mostly raw block) this gives 138 ns per byte so its slow but i thinked it could be like that..buts titally unoptimised and imo can be speeded probably few times - imo something in ranges between 90-200 ns per byte is slow but standable something in a range of 20-25 ns per cycle (or less) is fast and in between is probably average

i gues i probably could speed up this 2-3 times maybe but im not sure how of this time is going to tiem of saving output file.. coz i dont exactly understand this..input file is cached in ram so reading this probably dont add too much ..if this 138 ns per byte is speed of the code not IO then it can be improved

[toc] | [prev] | [next] | [standalone]

#171247

On 25/07/2023 16:51, fir wrote:
> poniedziałek, 24 lipca 2023 o 12:21:45 UTC+2 Bart napisał(a):
>> On 24/07/2023 08:02, David Brown wrote:
>>> On 23/07/2023 21:48, Vir Campestris wrote:
>>>> On 23/07/2023 19:32, Bonita Montero wrote:
>>>>> For sure in assembly, because that's easier to learn than C. 😉
>>>>
>>>> Yes, but which assembler?
>>>>
>>>> I've used perhaps a dozen. Perhaps because it depends on things like
>>>> whether a '286 counts as different to an 8086.
>>>>
>>>
>>> I have also used at least a dozen assembly languages - and that is /not/
>>> counting variations such as 8086/80286. (I haven't actually written any
>>> x86 assembly.)
>> If you haven't used x86, then the variations don't matter?
>>
>> I can list not quite a dozen varieties, if I include ones where I've
>> only written a few lines, but I count the x86 versions separately:
>>
>> + pdp10
>> digico m16v
>> pdp11 (used once to get some driver working)
>> 6800 (the only big-endian machine I've used!)
>> *+ z80
>> *+ 8088/6
>> * 80188/6
>> * 8035 or 8051
>> *+ 80386
>> *+ x64
>> arm32
>>
>> * means I either wrote a standalone assembler, or an inline one for a
>> HLL, or both. That doesn't rule out using someone else's assembler at
>> some point.
>>
>> + means I've used it as a compiler target
>>
>> (80188/6 is an enhanced version of 8088/6 with integrated peripherals
>> that have dedicated instructions.)
>>
>> 80386 has a different set of address modes from 8086, and non-segmented
>> memory in non-real mode.
>>
>> x64 has extra GP registers, SIMD etc. My syntax for it differs from
>> standard.
>>
>> (I don't include the ones I've coded only on paper, to see how they
>> might work as compiler targets.)
> 
> btw you once talked about compilations speed..could you give that numbers? as i dont remember which one thread it was..
> 
> i can do basic measuring of assembly speed

My current static compiler on AMD Ryzen 3, can compile code at 0.5 to 
0.7Mlps (or up to 1Mlps if optimised via C and gcc-O3, but I'd prefer 
not to do that).

Another measure is being able to generate 5 to 10MB of executable code 
per second.

My bytecode compiler for dynamic code can work at up to double those 
speeds (near 2Mlps max).

My x64 assembler I think works at 2 to 3Mlps.

On the same machine, Tiny C can compile C code at up to 1Mlps. (That is 
Tiny C compiled, probably, with gcc-O3; Tiny C compiled with itself 
would be half that speed.)

[toc] | [prev] | [next] | [standalone]

#171248

wtorek, 25 lipca 2023 o 19:48:44 UTC+2 Bart napisał(a):
> On 25/07/2023 16:51, fir wrote: 
> > poniedziałek, 24 lipca 2023 o 12:21:45 UTC+2 Bart napisał(a): 
> >> On 24/07/2023 08:02, David Brown wrote: 
> >>> On 23/07/2023 21:48, Vir Campestris wrote: 
> >>>> On 23/07/2023 19:32, Bonita Montero wrote: 
> >>>>> For sure in assembly, because that's easier to learn than C. 😉 
> >>>> 
> >>>> Yes, but which assembler? 
> >>>> 
> >>>> I've used perhaps a dozen. Perhaps because it depends on things like 
> >>>> whether a '286 counts as different to an 8086. 
> >>>> 
> >>> 
> >>> I have also used at least a dozen assembly languages - and that is /not/ 
> >>> counting variations such as 8086/80286. (I haven't actually written any 
> >>> x86 assembly.) 
> >> If you haven't used x86, then the variations don't matter? 
> >> 
> >> I can list not quite a dozen varieties, if I include ones where I've 
> >> only written a few lines, but I count the x86 versions separately: 
> >> 
> >> + pdp10 
> >> digico m16v 
> >> pdp11 (used once to get some driver working) 
> >> 6800 (the only big-endian machine I've used!) 
> >> *+ z80 
> >> *+ 8088/6 
> >> * 80188/6 
> >> * 8035 or 8051 
> >> *+ 80386 
> >> *+ x64 
> >> arm32 
> >> 
> >> * means I either wrote a standalone assembler, or an inline one for a 
> >> HLL, or both. That doesn't rule out using someone else's assembler at 
> >> some point. 
> >> 
> >> + means I've used it as a compiler target 
> >> 
> >> (80188/6 is an enhanced version of 8088/6 with integrated peripherals 
> >> that have dedicated instructions.) 
> >> 
> >> 80386 has a different set of address modes from 8086, and non-segmented 
> >> memory in non-real mode. 
> >> 
> >> x64 has extra GP registers, SIMD etc. My syntax for it differs from 
> >> standard. 
> >> 
> >> (I don't include the ones I've coded only on paper, to see how they 
> >> might work as compiler targets.) 
> > 
> > btw you once talked about compilations speed..could you give that numbers? as i dont remember which one thread it was.. 
> > 
> > i can do basic measuring of assembly speed
> My current static compiler on AMD Ryzen 3, can compile code at 0.5 to 
> 0.7Mlps (or up to 1Mlps if optimised via C and gcc-O3, but I'd prefer 
> not to do that). 
> 
> Another measure is being able to generate 5 to 10MB of executable code 
> per second. 
> 
> My bytecode compiler for dynamic code can work at up to double those 
> speeds (near 2Mlps max). 
> 
> My x64 assembler I think works at 2 to 3Mlps. 
> 
> On the same machine, Tiny C can compile C code at up to 1Mlps. (That is 
> Tiny C compiled, probably, with gcc-O3; Tiny C compiled with itself 
> would be half that speed.)

by 1MLps you mean 20 MB/s ? better say in megabytes
what you say and my results are coherent to what i see this things..imo this depends on
memory bandwidth and what you can obtain related to this ..if some computer have 10 GB/s it would be hard to obtain 1/10 or  1/30 of it (300MB/s) but something liek 1/90 could be possibly obtainable probably imo (100 MB/s) if hard optimised

yet i assume we talk about rading file from aran and saving file to ram..as im not sure how saving things to file includes to time here (reading input adds somewhet but not terribly much as when someone compiles second time the file is in ram cahe, but im not sure as to saving)

if thsio saving includes much it coud have semse to code in ramdisks, where you could run the output after compiletion before yet it is saved to disk)..im not sure is if i compile it is saved sorta asuynchronically and timer returns tiem before its finished..yet i doubt if i can run it from shel before it is finished this i doubt more

[toc] | [prev] | [next] | [standalone]

#171249

wtorek, 25 lipca 2023 o 20:13:53 UTC+2 fir napisał(a):
> wtorek, 25 lipca 2023 o 19:48:44 UTC+2 Bart napisał(a): 
> > On 25/07/2023 16:51, fir wrote: 
> > > poniedziałek, 24 lipca 2023 o 12:21:45 UTC+2 Bart napisał(a): 
> > >> On 24/07/2023 08:02, David Brown wrote: 
> > >>> On 23/07/2023 21:48, Vir Campestris wrote: 
> > >>>> On 23/07/2023 19:32, Bonita Montero wrote: 
> > >>>>> For sure in assembly, because that's easier to learn than C. 😉 
> > >>>> 
> > >>>> Yes, but which assembler? 
> > >>>> 
> > >>>> I've used perhaps a dozen. Perhaps because it depends on things like 
> > >>>> whether a '286 counts as different to an 8086. 
> > >>>> 
> > >>> 
> > >>> I have also used at least a dozen assembly languages - and that is /not/ 
> > >>> counting variations such as 8086/80286. (I haven't actually written any 
> > >>> x86 assembly.) 
> > >> If you haven't used x86, then the variations don't matter? 
> > >> 
> > >> I can list not quite a dozen varieties, if I include ones where I've 
> > >> only written a few lines, but I count the x86 versions separately: 
> > >> 
> > >> + pdp10 
> > >> digico m16v 
> > >> pdp11 (used once to get some driver working) 
> > >> 6800 (the only big-endian machine I've used!) 
> > >> *+ z80 
> > >> *+ 8088/6 
> > >> * 80188/6 
> > >> * 8035 or 8051 
> > >> *+ 80386 
> > >> *+ x64 
> > >> arm32 
> > >> 
> > >> * means I either wrote a standalone assembler, or an inline one for a 
> > >> HLL, or both. That doesn't rule out using someone else's assembler at 
> > >> some point. 
> > >> 
> > >> + means I've used it as a compiler target 
> > >> 
> > >> (80188/6 is an enhanced version of 8088/6 with integrated peripherals 
> > >> that have dedicated instructions.) 
> > >> 
> > >> 80386 has a different set of address modes from 8086, and non-segmented 
> > >> memory in non-real mode. 
> > >> 
> > >> x64 has extra GP registers, SIMD etc. My syntax for it differs from 
> > >> standard. 
> > >> 
> > >> (I don't include the ones I've coded only on paper, to see how they 
> > >> might work as compiler targets.) 
> > > 
> > > btw you once talked about compilations speed..could you give that numbers? as i dont remember which one thread it was.. 
> > > 
> > > i can do basic measuring of assembly speed 
> > My current static compiler on AMD Ryzen 3, can compile code at 0.5 to 
> > 0.7Mlps (or up to 1Mlps if optimised via C and gcc-O3, but I'd prefer 
> > not to do that). 
> > 
> > Another measure is being able to generate 5 to 10MB of executable code 
> > per second. 
> > 
> > My bytecode compiler for dynamic code can work at up to double those 
> > speeds (near 2Mlps max). 
> > 
> > My x64 assembler I think works at 2 to 3Mlps. 
> > 
> > On the same machine, Tiny C can compile C code at up to 1Mlps. (That is 
> > Tiny C compiled, probably, with gcc-O3; Tiny C compiled with itself 
> > would be half that speed.)
> by 1MLps you mean 20 MB/s ? better say in megabytes 
> what you say and my results are coherent to what i see this things..imo this depends on 
> memory bandwidth and what you can obtain related to this ..if some computer have 10 GB/s it would be hard to obtain 1/10 or 1/30 of it (300MB/s) but something liek 1/90 could be possibly obtainable probably imo (100 MB/s) if hard optimised 
> 
> yet i assume we talk about rading file from aran and saving file to ram..as im not sure how saving things to file includes to time here (reading input adds somewhet but not terribly much as when someone compiles second time the file is in ram cahe, but im not sure as to saving) 
> 
> if thsio saving includes much it coud have semse to code in ramdisks, where you could run the output after compiletion before yet it is saved to disk)..im not sure is if i compile it is saved sorta asuynchronically and timer returns tiem before its finished..yet i doubt if i can run it from shel before it is finished this i doubt more

i made a test now (commenting fwrites tos ave output exe) and there is no differense.. also 165 ms for  1.2 MB input - i dont know how windows caches files that are to be written- maybe it return asynchronously or what

[toc] | [prev] | [next] | [standalone]

#171250

wtorek, 25 lipca 2023 o 20:26:32 UTC+2 fir napisał(a):
> wtorek, 25 lipca 2023 o 20:13:53 UTC+2 fir napisał(a): 
> > wtorek, 25 lipca 2023 o 19:48:44 UTC+2 Bart napisał(a): 
> > > On 25/07/2023 16:51, fir wrote: 
> > > > poniedziałek, 24 lipca 2023 o 12:21:45 UTC+2 Bart napisał(a): 
> > > >> On 24/07/2023 08:02, David Brown wrote: 
> > > >>> On 23/07/2023 21:48, Vir Campestris wrote: 
> > > >>>> On 23/07/2023 19:32, Bonita Montero wrote: 
> > > >>>>> For sure in assembly, because that's easier to learn than C. 😉 
> > > >>>> 
> > > >>>> Yes, but which assembler? 
> > > >>>> 
> > > >>>> I've used perhaps a dozen. Perhaps because it depends on things like 
> > > >>>> whether a '286 counts as different to an 8086. 
> > > >>>> 
> > > >>> 
> > > >>> I have also used at least a dozen assembly languages - and that is /not/ 
> > > >>> counting variations such as 8086/80286. (I haven't actually written any 
> > > >>> x86 assembly.) 
> > > >> If you haven't used x86, then the variations don't matter? 
> > > >> 
> > > >> I can list not quite a dozen varieties, if I include ones where I've 
> > > >> only written a few lines, but I count the x86 versions separately: 
> > > >> 
> > > >> + pdp10 
> > > >> digico m16v 
> > > >> pdp11 (used once to get some driver working) 
> > > >> 6800 (the only big-endian machine I've used!) 
> > > >> *+ z80 
> > > >> *+ 8088/6 
> > > >> * 80188/6 
> > > >> * 8035 or 8051 
> > > >> *+ 80386 
> > > >> *+ x64 
> > > >> arm32 
> > > >> 
> > > >> * means I either wrote a standalone assembler, or an inline one for a 
> > > >> HLL, or both. That doesn't rule out using someone else's assembler at 
> > > >> some point. 
> > > >> 
> > > >> + means I've used it as a compiler target 
> > > >> 
> > > >> (80188/6 is an enhanced version of 8088/6 with integrated peripherals 
> > > >> that have dedicated instructions.) 
> > > >> 
> > > >> 80386 has a different set of address modes from 8086, and non-segmented 
> > > >> memory in non-real mode. 
> > > >> 
> > > >> x64 has extra GP registers, SIMD etc. My syntax for it differs from 
> > > >> standard. 
> > > >> 
> > > >> (I don't include the ones I've coded only on paper, to see how they 
> > > >> might work as compiler targets.) 
> > > > 
> > > > btw you once talked about compilations speed..could you give that numbers? as i dont remember which one thread it was.. 
> > > > 
> > > > i can do basic measuring of assembly speed 
> > > My current static compiler on AMD Ryzen 3, can compile code at 0.5 to 
> > > 0.7Mlps (or up to 1Mlps if optimised via C and gcc-O3, but I'd prefer 
> > > not to do that). 
> > > 
> > > Another measure is being able to generate 5 to 10MB of executable code 
> > > per second. 
> > > 
> > > My bytecode compiler for dynamic code can work at up to double those 
> > > speeds (near 2Mlps max). 
> > > 
> > > My x64 assembler I think works at 2 to 3Mlps. 
> > > 
> > > On the same machine, Tiny C can compile C code at up to 1Mlps. (That is 
> > > Tiny C compiled, probably, with gcc-O3; Tiny C compiled with itself 
> > > would be half that speed.) 
> > by 1MLps you mean 20 MB/s ? better say in megabytes 
> > what you say and my results are coherent to what i see this things..imo this depends on 
> > memory bandwidth and what you can obtain related to this ..if some computer have 10 GB/s it would be hard to obtain 1/10 or 1/30 of it (300MB/s) but something liek 1/90 could be possibly obtainable probably imo (100 MB/s) if hard optimised 
> > 
> > yet i assume we talk about rading file from aran and saving file to ram..as im not sure how saving things to file includes to time here (reading input adds somewhet but not terribly much as when someone compiles second time the file is in ram cahe, but im not sure as to saving) 
> > 
> > if thsio saving includes much it coud have semse to code in ramdisks, where you could run the output after compiletion before yet it is saved to disk)..im not sure is if i compile it is saved sorta asuynchronically and timer returns tiem before its finished..yet i doubt if i can run it from shel before it is finished this i doubt more
> i made a test now (commenting fwrites tos ave output exe) and there is no differense.. also 165 ms for 1.2 MB input - i dont know how windows caches files that are to be written- maybe it return asynchronously or what

gcc - O2  (c code in cpp mode) is slow as hell in turn, (but i test on real old weach pc, i got two PC but for coding liek use that old) it compiles the assembler which is 400 KB in 14 seconds  which is 30 KB/s compared to 7 MB/s

[toc] | [prev] | [next] | [standalone]

#171251

wtorek, 25 lipca 2023 o 20:34:15 UTC+2 fir napisał(a):
> wtorek, 25 lipca 2023 o 20:26:32 UTC+2 fir napisał(a):
> > wtorek, 25 lipca 2023 o 20:13:53 UTC+2 fir napisał(a): 
> > > wtorek, 25 lipca 2023 o 19:48:44 UTC+2 Bart napisał(a): 
> > > > On 25/07/2023 16:51, fir wrote: 
> > > > > poniedziałek, 24 lipca 2023 o 12:21:45 UTC+2 Bart napisał(a): 
> > > > >> On 24/07/2023 08:02, David Brown wrote: 
> > > > >>> On 23/07/2023 21:48, Vir Campestris wrote: 
> > > > >>>> On 23/07/2023 19:32, Bonita Montero wrote: 
> > > > >>>>> For sure in assembly, because that's easier to learn than C. 😉 
> > > > >>>> 
> > > > >>>> Yes, but which assembler? 
> > > > >>>> 
> > > > >>>> I've used perhaps a dozen. Perhaps because it depends on things like 
> > > > >>>> whether a '286 counts as different to an 8086. 
> > > > >>>> 
> > > > >>> 
> > > > >>> I have also used at least a dozen assembly languages - and that is /not/ 
> > > > >>> counting variations such as 8086/80286. (I haven't actually written any 
> > > > >>> x86 assembly.) 
> > > > >> If you haven't used x86, then the variations don't matter? 
> > > > >> 
> > > > >> I can list not quite a dozen varieties, if I include ones where I've 
> > > > >> only written a few lines, but I count the x86 versions separately: 
> > > > >> 
> > > > >> + pdp10 
> > > > >> digico m16v 
> > > > >> pdp11 (used once to get some driver working) 
> > > > >> 6800 (the only big-endian machine I've used!) 
> > > > >> *+ z80 
> > > > >> *+ 8088/6 
> > > > >> * 80188/6 
> > > > >> * 8035 or 8051 
> > > > >> *+ 80386 
> > > > >> *+ x64 
> > > > >> arm32 
> > > > >> 
> > > > >> * means I either wrote a standalone assembler, or an inline one for a 
> > > > >> HLL, or both. That doesn't rule out using someone else's assembler at 
> > > > >> some point. 
> > > > >> 
> > > > >> + means I've used it as a compiler target 
> > > > >> 
> > > > >> (80188/6 is an enhanced version of 8088/6 with integrated peripherals 
> > > > >> that have dedicated instructions.) 
> > > > >> 
> > > > >> 80386 has a different set of address modes from 8086, and non-segmented 
> > > > >> memory in non-real mode. 
> > > > >> 
> > > > >> x64 has extra GP registers, SIMD etc. My syntax for it differs from 
> > > > >> standard. 
> > > > >> 
> > > > >> (I don't include the ones I've coded only on paper, to see how they 
> > > > >> might work as compiler targets.) 
> > > > > 
> > > > > btw you once talked about compilations speed..could you give that numbers? as i dont remember which one thread it was.. 
> > > > > 
> > > > > i can do basic measuring of assembly speed 
> > > > My current static compiler on AMD Ryzen 3, can compile code at 0.5 to 
> > > > 0.7Mlps (or up to 1Mlps if optimised via C and gcc-O3, but I'd prefer 
> > > > not to do that). 
> > > > 
> > > > Another measure is being able to generate 5 to 10MB of executable code 
> > > > per second. 
> > > > 
> > > > My bytecode compiler for dynamic code can work at up to double those 
> > > > speeds (near 2Mlps max). 
> > > > 
> > > > My x64 assembler I think works at 2 to 3Mlps. 
> > > > 
> > > > On the same machine, Tiny C can compile C code at up to 1Mlps. (That is 
> > > > Tiny C compiled, probably, with gcc-O3; Tiny C compiled with itself 
> > > > would be half that speed.) 
> > > by 1MLps you mean 20 MB/s ? better say in megabytes 
> > > what you say and my results are coherent to what i see this things..imo this depends on 
> > > memory bandwidth and what you can obtain related to this ..if some computer have 10 GB/s it would be hard to obtain 1/10 or 1/30 of it (300MB/s) but something liek 1/90 could be possibly obtainable probably imo (100 MB/s) if hard optimised 
> > > 
> > > yet i assume we talk about rading file from aran and saving file to ram..as im not sure how saving things to file includes to time here (reading input adds somewhet but not terribly much as when someone compiles second time the file is in ram cahe, but im not sure as to saving) 
> > > 
> > > if thsio saving includes much it coud have semse to code in ramdisks, where you could run the output after compiletion before yet it is saved to disk)..im not sure is if i compile it is saved sorta asuynchronically and timer returns tiem before its finished..yet i doubt if i can run it from shel before it is finished this i doubt more 
> > i made a test now (commenting fwrites tos ave output exe) and there is no differense.. also 165 ms for 1.2 MB input - i dont know how windows caches files that are to be written- maybe it return asynchronously or what
> gcc - O2 (c code in cpp mode) is slow as hell in turn, (but i test on real old weach pc, i got two PC but for coding liek use that old) it compiles the assembler which is 400 KB in 14 seconds which is 30 KB/s compared to 7 MB/s


well in fact the asembler source also includes clib and windows headers (windows only for timer i guess) so it might be a doze of headers to this

[toc] | [prev] | [next] | [standalone]

#171253

wtorek, 25 lipca 2023 o 20:46:51 UTC+2 fir napisał(a):
> wtorek, 25 lipca 2023 o 20:34:15 UTC+2 fir napisał(a):
> > wtorek, 25 lipca 2023 o 20:26:32 UTC+2 fir napisał(a): 
> > > wtorek, 25 lipca 2023 o 20:13:53 UTC+2 fir napisał(a): 
> > > > wtorek, 25 lipca 2023 o 19:48:44 UTC+2 Bart napisał(a): 
> > > > > On 25/07/2023 16:51, fir wrote: 
> > > > > > poniedziałek, 24 lipca 2023 o 12:21:45 UTC+2 Bart napisał(a): 
> > > > > >> On 24/07/2023 08:02, David Brown wrote: 
> > > > > >>> On 23/07/2023 21:48, Vir Campestris wrote: 
> > > > > >>>> On 23/07/2023 19:32, Bonita Montero wrote: 
> > > > > >>>>> For sure in assembly, because that's easier to learn than C. 😉 
> > > > > >>>> 
> > > > > >>>> Yes, but which assembler? 
> > > > > >>>> 
> > > > > >>>> I've used perhaps a dozen. Perhaps because it depends on things like 
> > > > > >>>> whether a '286 counts as different to an 8086. 
> > > > > >>>> 
> > > > > >>> 
> > > > > >>> I have also used at least a dozen assembly languages - and that is /not/ 
> > > > > >>> counting variations such as 8086/80286. (I haven't actually written any 
> > > > > >>> x86 assembly.) 
> > > > > >> If you haven't used x86, then the variations don't matter? 
> > > > > >> 
> > > > > >> I can list not quite a dozen varieties, if I include ones where I've 
> > > > > >> only written a few lines, but I count the x86 versions separately: 
> > > > > >> 
> > > > > >> + pdp10 
> > > > > >> digico m16v 
> > > > > >> pdp11 (used once to get some driver working) 
> > > > > >> 6800 (the only big-endian machine I've used!) 
> > > > > >> *+ z80 
> > > > > >> *+ 8088/6 
> > > > > >> * 80188/6 
> > > > > >> * 8035 or 8051 
> > > > > >> *+ 80386 
> > > > > >> *+ x64 
> > > > > >> arm32 
> > > > > >> 
> > > > > >> * means I either wrote a standalone assembler, or an inline one for a 
> > > > > >> HLL, or both. That doesn't rule out using someone else's assembler at 
> > > > > >> some point. 
> > > > > >> 
> > > > > >> + means I've used it as a compiler target 
> > > > > >> 
> > > > > >> (80188/6 is an enhanced version of 8088/6 with integrated peripherals 
> > > > > >> that have dedicated instructions.) 
> > > > > >> 
> > > > > >> 80386 has a different set of address modes from 8086, and non-segmented 
> > > > > >> memory in non-real mode. 
> > > > > >> 
> > > > > >> x64 has extra GP registers, SIMD etc. My syntax for it differs from 
> > > > > >> standard. 
> > > > > >> 
> > > > > >> (I don't include the ones I've coded only on paper, to see how they 
> > > > > >> might work as compiler targets.) 
> > > > > > 
> > > > > > btw you once talked about compilations speed..could you give that numbers? as i dont remember which one thread it was.. 
> > > > > > 
> > > > > > i can do basic measuring of assembly speed 
> > > > > My current static compiler on AMD Ryzen 3, can compile code at 0.5 to 
> > > > > 0.7Mlps (or up to 1Mlps if optimised via C and gcc-O3, but I'd prefer 
> > > > > not to do that). 
> > > > > 
> > > > > Another measure is being able to generate 5 to 10MB of executable code 
> > > > > per second. 
> > > > > 
> > > > > My bytecode compiler for dynamic code can work at up to double those 
> > > > > speeds (near 2Mlps max). 
> > > > > 
> > > > > My x64 assembler I think works at 2 to 3Mlps. 
> > > > > 
> > > > > On the same machine, Tiny C can compile C code at up to 1Mlps. (That is 
> > > > > Tiny C compiled, probably, with gcc-O3; Tiny C compiled with itself 
> > > > > would be half that speed.) 
> > > > by 1MLps you mean 20 MB/s ? better say in megabytes 
> > > > what you say and my results are coherent to what i see this things..imo this depends on 
> > > > memory bandwidth and what you can obtain related to this ..if some computer have 10 GB/s it would be hard to obtain 1/10 or 1/30 of it (300MB/s) but something liek 1/90 could be possibly obtainable probably imo (100 MB/s) if hard optimised 
> > > > 
> > > > yet i assume we talk about rading file from aran and saving file to ram..as im not sure how saving things to file includes to time here (reading input adds somewhet but not terribly much as when someone compiles second time the file is in ram cahe, but im not sure as to saving) 
> > > > 
> > > > if thsio saving includes much it coud have semse to code in ramdisks, where you could run the output after compiletion before yet it is saved to disk)..im not sure is if i compile it is saved sorta asuynchronically and timer returns tiem before its finished..yet i doubt if i can run it from shel before it is finished this i doubt more 
> > > i made a test now (commenting fwrites tos ave output exe) and there is no differense.. also 165 ms for 1.2 MB input - i dont know how windows caches files that are to be written- maybe it return asynchronously or what 
> > gcc - O2 (c code in cpp mode) is slow as hell in turn, (but i test on real old weach pc, i got two PC but for coding liek use that old) it compiles the assembler which is 400 KB in 14 seconds which is 30 KB/s compared to 7 MB/s
> well in fact the asembler source also includes clib and windows headers (windows only for timer i guess) so it might be a doze of headers to this

gcc -O1 9 seconds 
gcc -O0 (if yhis is proper flag i dont know)  2 seconds

so i dont kno how big those headers are to check but if headers are 1.5 MB iy makes 1 MB/s so its not much fat but standable

[toc] | [prev] | [next] | [standalone]

#171255

On 25/07/2023 19:13, fir wrote:
 > wtorek, 25 lipca 2023 o 19:48:44 UTC+2 Bart napisał(a):
 >>> btw you once talked about compilations speed..could you give that 
numbers? as i dont remember which one thread it was..
 >>>
 >>> i can do basic measuring of assembly speed
 >> My current static compiler on AMD Ryzen 3, can compile code at 0.5 to
 >> 0.7Mlps (or up to 1Mlps if optimised via C and gcc-O3, but I'd prefer
 >> not to do that).
 >>
 >> Another measure is being able to generate 5 to 10MB of executable code
 >> per second.
 >>
 >> My bytecode compiler for dynamic code can work at up to double those
 >> speeds (near 2Mlps max).
 >>
 >> My x64 assembler I think works at 2 to 3Mlps.
 >>
 >> On the same machine, Tiny C can compile C code at up to 1Mlps. (That is
 >> Tiny C compiled, probably, with gcc-O3; Tiny C compiled with itself
 >> would be half that speed.)
 >
 > by 1MLps you mean 20 MB/s ? better say in megabytes

I don't measure source code in megabytes.

1 Mlps is one million lines of source per second. As MB, it depends on 
language, code density and coding style. But it correspond to roughly 
5-10MB/second.

Also, 1 line of lower-level HLL source code generates roughly 10 bytes 
of x64 machine code. 1 Mlps might be 10MB/s of generated binary code.

So actually, the number of input MB and output MB are roughly 
equivalent, perhap within a factor of 2 for my HLL, code style, and 
compiler.


 > what you say and my results are coherent to what i see this 
things..imo this depends on
 > memory bandwidth and what you can obtain related to this ..if some 
computer have 10 GB/s

If you're just loading and reading files, then sure. But compilation is 
a lot more complicated than that. On my compilers, loading source files 
and writing binaries is 1.5% of overall compile time (using SSD, but 
source code is nearly always already cached).

So that is not the limiting factor in compilation.

As I said, the Tiny C compiler manages nearly 1Mlps, so around 10MB of 
input and output per second, and that is VERY lean: it manages all with 
a single pass. My compiler has 5 or so passes.

I think you suggested once you could manage 10Mlps, well good luck with 
that, if doing it with a real language, and not one contrived for the 
purpose. (Tiny C has to deal with real, brutal C code, and also lots of 
headers that do no contribute to the output binary, but still needs to 
be processed.)



 > it would be hard to obtain 1/10 or  1/30 of it (300MB/s) but 
something liek 1/90 could be possibly obtainable probably imo (100 MB/s) 
if hard optimised
 >
 > yet i assume we talk about rading file from aran and saving file to 
ram..as im not sure how saving things to file includes to time here 
(reading input adds somewhet but not terribly much as when someone 
compiles second time the file is in ram cahe, but im not sure as to saving)
 >
 > if thsio saving includes much it coud have semse to code in ramdisks, 
where you could run the output after compiletion before yet it is saved 
to disk)..im not sure is if i compile it is saved sorta asuynchronically 
and timer returns tiem before its finished..yet i doubt if i can run it 
from shel before it is finished this i doubt more

Are you talking about 300MB/second compile speed? That would be pure 
fantasy unless you are running on a super computer with dozens of cores.

But what would be the purpose? My 0.5Mlps compiler can build my biggest 
application in 0.1 seconds. Your imaginary one might do it in 0.003 
milliseconds, except that Windows process overheads means it will take 
at least 0.02 seconds anyway.

[toc] | [prev] | [next] | [standalone]

#171256

wtorek, 25 lipca 2023 o 23:14:19 UTC+2 Bart napisał(a):
> On 25/07/2023 19:13, fir wrote: 
> > wtorek, 25 lipca 2023 o 19:48:44 UTC+2 Bart napisał(a): 
> >>> btw you once talked about compilations speed..could you give that 
> numbers? as i dont remember which one thread it was.. 
> >>> 
> >>> i can do basic measuring of assembly speed 
> >> My current static compiler on AMD Ryzen 3, can compile code at 0.5 to 
> >> 0.7Mlps (or up to 1Mlps if optimised via C and gcc-O3, but I'd prefer 
> >> not to do that). 
> >> 
> >> Another measure is being able to generate 5 to 10MB of executable code 
> >> per second. 
> >> 
> >> My bytecode compiler for dynamic code can work at up to double those 
> >> speeds (near 2Mlps max). 
> >> 
> >> My x64 assembler I think works at 2 to 3Mlps. 
> >> 
> >> On the same machine, Tiny C can compile C code at up to 1Mlps. (That is 
> >> Tiny C compiled, probably, with gcc-O3; Tiny C compiled with itself 
> >> would be half that speed.) 
> > 
> > by 1MLps you mean 20 MB/s ? better say in megabytes
> I don't measure source code in megabytes. 
> 
> 1 Mlps is one million lines of source per second. As MB, it depends on 
> language, code density and coding style. But it correspond to roughly 
> 5-10MB/second. 
> 
> Also, 1 line of lower-level HLL source code generates roughly 10 bytes 
> of x64 machine code. 1 Mlps might be 10MB/s of generated binary code. 
> 
> So actually, the number of input MB and output MB are roughly 
> equivalent, perhap within a factor of 2 for my HLL, code style, and 
> compiler.
> > what you say and my results are coherent to what i see this 
> things..imo this depends on 
> > memory bandwidth and what you can obtain related to this ..if some 
> computer have 10 GB/s
> If you're just loading and reading files, then sure. But compilation is 
> a lot more complicated than that. On my compilers, loading source files 
> and writing binaries is 1.5% of overall compile time (using SSD, but 
> source code is nearly always already cached). 
> 
> So that is not the limiting factor in compilation. 
> 
> As I said, the Tiny C compiler manages nearly 1Mlps, so around 10MB of 
> input and output per second, and that is VERY lean: it manages all with 
> a single pass. My compiler has 5 or so passes. 
> 
> I think you suggested once you could manage 10Mlps, well good luck with 
> that, if doing it with a real language, and not one contrived for the 
> purpose. (Tiny C has to deal with real, brutal C code, and also lots of 
> headers that do no contribute to the output binary, but still needs to 
> be processed.)

i vaguelly remember that but as i remember i not said that i could manege that
(not saying at this point) and not even im sure it is for syre to be managed but 
was guessing and estimating possible top speeds on hardvare if its titally opyimised
i could say 200MB/s as a goal ..hard to estimate exactly but it would be sorta that
rank possibly 

you better count in MB/s this is becouse if you optimise code its often in just 
thrtuoughput of tam pre seconds ...also im not sure if this sepcial sense of talkin on
output speed, in facyt there is probably sense on talking sum input and output, but maybe more on input

> > it would be hard to obtain 1/10 or 1/30 of it (300MB/s) but 
> something liek 1/90 could be possibly obtainable probably imo (100 MB/s) 
> if hard optimised 
> > 
> > yet i assume we talk about rading file from aran and saving file to 
> ram..as im not sure how saving things to file includes to time here 
> (reading input adds somewhet but not terribly much as when someone 
> compiles second time the file is in ram cahe, but im not sure as to saving) 
> > 
> > if thsio saving includes much it coud have semse to code in ramdisks, 
> where you could run the output after compiletion before yet it is saved 
> to disk)..im not sure is if i compile it is saved sorta asuynchronically 
> and timer returns tiem before its finished..yet i doubt if i can run it 
> from shel before it is finished this i doubt more
> Are you talking about 300MB/second compile speed? That would be pure 
> fantasy unless you are running on a super computer with dozens of cores. 
> 
the main factor is probably memory bandwidth and ifs/branchhing speed..
ite depends on machine bandwidth and those branching speed,
note i talk on good optimisation and strightforward opmpilation..not 
necessary thinking on many cores but typical 2 or 4 could be handy,
but i think with more cores you have chance maybe to beat it when in less 
cores liek 1 core be below of that

> But what would be the purpose? My 0.5Mlps compiler can build my biggest 
> application in 0.1 seconds. Your imaginary one might do it in 0.003 
> milliseconds, except that Windows process overheads means it will take 
> at least 0.02 seconds anyway.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web