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.

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.

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.

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

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)

poniedziałek, 24 lipca 2023 o 16:29:21 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 14:51:34 UTC+2 fir napisał(a):
> > poniedziałek, 24 lipca 2023 o 14:45:54 UTC+2 Richard Harnden napisał(a):
> > > On 24/07/2023 13:19, fir wrote:
> > > > poniedziałek, 24 lipca 2023 o 14:10:54 UTC+2 fir napisał(a):
> > > >> i wrote my own assembler (org-asm) you my check it
> > > >>
> > > >> https://fastupload.io/CYnB7m6CLilssjs/file
> > > >>
> > > >> it compiles 3 examples...the attached dll is to run second example and thsi ddl is for opening window which my exampel ina ssembly calls to draw mandelbrot set
> > > >>
> > > >> hovever the resulted exe is simple and has no exception section which may be reason windows defender or other programs can false identify it as malvare it is strictly what you code in asm only
> > > >
> > > > you may se the nice output log from it
> > > >
> > > >
> > > > +----------------------------------------------------------------------------+
> > > > | |
> > > > | Organic Assembler (org-asm) by fir, december of 2020 (;ast update V.22) |
> > > ^
> > > |
> > > You can't even avoid typos in your own readmes --------------+
> > >
> > > Jeez.
> > i dont care that much - note thet logic structure of this log is high,
> > and that cominicates what is not done i will delete if i do what is not done (hovever presently i not work on this assembler hovever i like it,
> > it went well)
> > > > | |
> > > > | note: this is early version with far from elaborate |
> > > > | error messages and not strictly all of the mnemonics implemented, |
> > > > | hovever it does the work and i find it nice and usefull |
> > > > | |
> > > > | right now it is able to assemble win32/x86 exe files (no output as dll |
> > > > | yet) with any possible dll imports, so youre basicaly able to assemble |
> > > > | any win32 app with it |
> > > Also, the shift key is only an inch away. Please learn to spend that
> > > extra fraction of a second.
> i could rather improve the log for example denote the adresses
>
> if end of this code is
> 203 (l. 353) push 20
> 204 (l. 353) push 20
> 205 (l. 354) push title
> 206 (l. 354) call (green.fire.dll->SetupWindow3)
> 207 (l. 355) add esp 20
> 208 (l. 357) mov eax 0
> 209 (l. 358) ret
> and end of binary is
> 401350 00 00 68 80 02 00 00 68 14 00 00 00 68 14 00 00
> 401360 00 68 55 30 40 00 ff 15 80 23 40 00 83 c4 14 b8
> 401370 00 00 00 00 c3
> should mark it some way
> 401350 00 00/68\80 02 00 00/68\14 00 00 00/68\14 00 00
> 401360 00/68\55 30 40 00/ff 15\80 23 40 00/83 c4\14/b8\
> 401370 00 00 00 00/c3
>
> or maybe something more readable...im not sure if the code is compatible to flush this without bigger changes

this log is important coz imo assembly is not just writting in assembly but "totall transparency" clearly seen what is goin on to the bone

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

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

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.)

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

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

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

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

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

fir <profesor.fir@gmail.com> wrote:
> how many lines you coded in your life? if you give an answer try to be real

A gentle push, please learn to format your lines,
you have been posting longer enough to know this :)
http://www.mugsy.org/asa_faq/getting_along/usenet.shtml

<snip>
> are you able to estimate?

I have no idea, as someone else said, I guess around million ?
Most of these programs are lost "like tears in the rain" :)

My first program was written on punch cards, then on to CTR, then
PCs. I was able to avoid any type of to management "promotions".

Regards,
John

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.

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.

wtorek, 25 lipca 2023 o 22:27:00 UTC+2 John McCue napisał(a):
> fir <profes...@gmail.com> wrote:
> > how many lines you coded in your life? if you give an answer try to be real
> A gentle push, please learn to format your lines,
> you have been posting longer enough to know this :)
> http://www.mugsy.org/asa_faq/getting_along/usenet.shtml
>
> <snip>
> > are you able to estimate?
>
> I have no idea, as someone else said, I guess around million ?
> Most of these programs are lost "like tears in the rain" :)
>
> My first program was written on punch cards, then on to CTR, then
> PCs. I was able to avoid any type of to management "promotions".
>

ok, milion is maybe not terribly big amount (o0btainable) if i think but it is rathed for smeone who coded
most of life...

wtorek, 25 lipca 2023 o 23:36:03 UTC+2 fir napisał(a):
> 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.

300 MB/s maybe can be itself to high but maybe something ina a rank 100-300MB/s depending on machine

with the assembler im somewhat satisfied/pleasd by the syntax i chosen,
it is not bad imo
though i wonder what could be imptoved

its alows writing more lines in line with , and mixing data with code and put the data near place of suage with >>

jmp start

//////////////////////////////////////
// >> test: 1b 2b 3b 4b 5b 7b

//////////////////////////
count_mandelbrot_areafragment_coeficients:
//double man.LY = man.LX * frame_size_y/frame_size_x

// man.start.x = man.OX - man.LX/2
// man.start.y = man.OY - man.LY/2
// man.dx = man.LX/frame_size_x
// man.dy = man.Ly/frame_size_y

mov eax -2
cvt si2ss x2 eax

mov ss x1 (man.lx), >> man.lx: 4.0
div ss x1 x2
add ss x1 (man.ox), >> man.ox: -0.6
mov ss (man.start.x) x1, >> man.start.x: -0.0

mov ss x1 (man.ly), >> man.ly: 3.0
div ss x1 x2
add ss x1 (man.oy), >> man.oy: 0.0
mov ss (man.start.y) x1, >> man.start.y: -0.0

mov eax ("green.fire.dll"->frame_size_x)
mov ebx (eax)
cvt si2ss x2 ebx
mov ss x1 (man.lx)
div ss x1 x2
mov ss (man.dx) x1, >> man.dx: -0.0

mov eax ("green.fire.dll"->frame_size_y)
mov ebx (eax)
cvt si2ss x2 ebx
mov ss x1 (man.ly)
div ss x1 x2
mov ss (man.dy) x1, >> man.dy: -0.0

ret

////////////////////////////////////////////////////////
// double re = cRe;
// double im = cIm;
//
// for(int n=1; n<man.maxiter; n++)
// {
//
// if( re * re + im * im > 4.0 ) return n;
//
// double re_n = re * re - im * im + cRe;
// double im_n = 2 * re * im + cIm;
//
// re = re_n;
// im = im_n;
//
// }
/////////////////////////////////////////////////////

calc_mandelbtot_for_esi_edi:

>> c.re: 0.0 c.im: 0.0 four: 4.0

cvt si2ss x0 esi,
mov ss x1 (man.dx),
mul ss x0 x1,
add ss x0 (man.start.x),
mov ss (c.re) x0

cvt si2ss x0 edi,
mov ss x1 (man.dy),
mul ss x0 x1,
add ss x0 (man.start.y),
mov ss (c.im) x0

//////////////////////
mov ecx 0
mov ss x3 (c.re)
mov ss x4 (c.im)
mov ss x0 x3
mov ss x1 x4
mov ss x2 (four)
mov ss x5 x0 //re
iterations:
mov ss x6 x1 //im
mul ss x5 x5 //re * re
mul ss x6 x6 //im * im
mov ss x7 x5, add ss x7 x6, // re*re + im*im
comi ss x7 x2, jae out
sub ss x5 x6, add ss x5 x3 // re_n = re * re - im * im + cRe;
mul ss x1 x0, add ss x1 x1, add ss x1 x4 // im_n = 2 * re * im + cIm;
mov ss x0 x5
inc ecx, cmp ecx 256, jl iterations
mov ecx 0xff0000, ret
out:
push eax
mov eax ecx
shl eax 8
add eax ecx
shl eax 8
add eax ecx
mov ecx eax
pop eax,
ret

// mov ecx 0xffffff, ret

print_eax:
>> note_eax: "\x0d\x0a eax = %d \x00"

push eax
push note_eax
call (msvcrt.dll->printf)
pop eax
pop eax
ret

ProcessKeyDown:

>> last_key_pressed: 0
>> PAGE_UP: 32

On 7/23/2023 12:42 PM, Chris M. Thomasson wrote:
> On 7/23/2023 10:29 AM, fir wrote:
>> how many lines you coded in your life? if you give an answer try to be
>> real
>
> God damn. Millions? Maybe more? Good question.
>
>
>> (and not count data and duplicates)
>> i myself estimated 200-300k hovever after thinking i think it may be
>> closer to 200k (my newer projects take about 130k or something more
>> but i also got some older i coand count now.. i would say for sure it
>> was no less than 170k but how many above this thios one i can
>> count/memorize now)
>>
>> are you able to estimate?
>

Some of that code was pure experimentation. I treated my some of my code
like it was some sort of god damn lab rat. Nasty!

https://youtu.be/SsAFen9b2Qg

How many lines of hyper experimental code have you created before?
Treating your existing working code like a weird science experiment?

środa, 26 lipca 2023 o 05:36:57 UTC+2 Chris M. Thomasson napisał(a):
> On 7/23/2023 12:42 PM, Chris M. Thomasson wrote:
> > On 7/23/2023 10:29 AM, fir wrote:
> >> how many lines you coded in your life? if you give an answer try to be
> >> real
> >
> > God damn. Millions? Maybe more? Good question.
> >
> >
> >> (and not count data and duplicates)
> >> i myself estimated 200-300k hovever after thinking i think it may be
> >> closer to 200k (my newer projects take about 130k or something more
> >> but i also got some older i coand count now.. i would say for sure it
> >> was no less than 170k but how many above this thios one i can
> >> count/memorize now)
> >>
> >> are you able to estimate?
> >
> Some of that code was pure experimentation. I treated my some of my code
> like it was some sort of god damn lab rat. Nasty!
>
> https://youtu.be/SsAFen9b2Qg
>
> How many lines of hyper experimental code have you created before?
> Treating your existing working code like a weird science experiment?

not so much as i dont write so much experimental code it just to be dleted,
its ratcher simple unfinished projects, but not finished becouse lack of time
(sad becouse many of them would be good but im avare i got no 2 years on each)

i uploaded somewhat newer version of assembler

https://fastupload.io/zU29wbmaRh2o3et/file

thouch not much changed i added this marking opcodes in log and
terat things like 0 1 2 200 as ints in data section (before they were treated as chars but
ints probebly better)

On Sunday, July 23, 2023 at 1:29:49 PM UTC-4, fir wrote:
> how many lines you coded in your life? if you give an answer try to be real
> (and not count data and duplicates)
> i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)
>
> are you able to estimate?

Context: software development for a little over 40 years
Initial estimate:
One of 3 original developers at a startup company.
At working prototype stage we counted 6 million lines
of C & C# code. I estimate I produced about 1 million of that.
That took 4 years of work with a team growing to 12.
I also developed code there for build and install scripts,
custom controller languages and more.

So I also have noted that the number of lines of design
and other documentation I produced exceeds the code
by a factor of 5 or so.

Other places I produced much less code, but I think
I can claim a couple million lines over 40 years.

Ed

środa, 26 lipca 2023 o 17:04:09 UTC+2 Ed Prochak napisał(a):
> On Sunday, July 23, 2023 at 1:29:49 PM UTC-4, fir wrote:
> > how many lines you coded in your life? if you give an answer try to be real
> > (and not count data and duplicates)
> > i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)
> >
> > are you able to estimate?
> Context: software development for a little over 40 years
> Initial estimate:
> One of 3 original developers at a startup company.
> At working prototype stage we counted 6 million lines
> of C & C# code. I estimate I produced about 1 million of that.
> That took 4 years of work with a team growing to 12.
> I also developed code there for build and install scripts,
> custom controller languages and more.
>
> So I also have noted that the number of lines of design
> and other documentation I produced exceeds the code
> by a factor of 5 or so.
>
> Other places I produced much less code, but I think
> I can claim a couple million lines over 40 years.
>

saying couple milion i think is inprecise as imo it would be reallu nlike to
write more than 2 milions

saying realistically one writes 50k a year x40 years = 2 milions

*i would be able writing 50k a year (very intensive month is 10k but need to rest)
but i not code year by year... also not sure if not beoin 45+ people not code slower

On 7/23/2023 12:29 PM, fir wrote:
> how many lines you coded in your life? if you give an answer try to be real
> (and not count data and duplicates)
> i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)
>
> are you able to estimate?

That is a very hard number to quantify. And in just C code or all codes
? At least a half million LOC since 1975 in Fortran 66, Fortran 77, IBM
370 Assembler, Basic, Pascal, C, C++, HTML, Perl.

I am the chief shepherd for 730,000 lines of Fortran 77 code and 600,000
lines of C and mostly C++ code for a Windows desktop engineering
software product sold commercially.

Lynn

On Thursday, July 27, 2023 at 4:16:24 AM UTC-4, fir wrote:
> środa, 26 lipca 2023 o 17:04:09 UTC+2 Ed Prochak napisał(a):
> > On Sunday, July 23, 2023 at 1:29:49 PM UTC-4, fir wrote:
> > > how many lines you coded in your life? if you give an answer try to be real
> > > (and not count data and duplicates)
[]
> > >
> > > are you able to estimate?
> >
> > Context: software development for a little over 40 years
> > Initial estimate:
> > One of 3 original developers at a startup company.
> > At working prototype stage we counted 6 million lines
> > of C & C# code. I estimate I produced about 1 million of that.
> > That took 4 years of work with a team growing to 12.
> > I also developed code there for build and install scripts,
> > custom controller languages and more.
> >
> > So I also have noted that the number of lines of design
> > and other documentation I produced exceeds the code
> > by a factor of 5 or so.
> >
> > Other places I produced much less code, but I think
> > I can claim a couple million lines over 40 years.
> >
> saying couple milion i think is inprecise as imo it would be reallu nlike to
> write more than 2 milions

Just a matter of grammar, and I prefer to be conservative.
>
> saying realistically one writes 50k a year x40 years = 2 milions

yes that could be right. Some years more some years less.
Years with less code are likely occupied with design or other
documentation required.
>
> *i would be able writing 50k a year (very intensive month is 10k but need to rest)
> but i not code year by year... also not sure if not beoin 45+ people not code slower

And how well is your code documented? Both design and operation?
Ed