[9fans] speaking of kenc - Plan9

This is a discussion on [9fans] speaking of kenc - Plan9 ; > the root of all this evil is the designer of the processor. can we > make them change their ways? not until we start designing our own. This has puzzled me for years. Why are processors designed by engineers ...

+ Reply to Thread
Page 6 of 7 FirstFirst ... 4 5 6 7 LastLast
Results 101 to 120 of 121

Thread: [9fans] speaking of kenc

  1. Re: [9fans] speaking of kenc

    > the root of all this evil is the designer of the processor. can we
    > make them change their ways? not until we start designing our own.


    This has puzzled me for years. Why are processors designed by
    engineers who seem to have no software understanding?

    Is it the same reason that only car manufactures dictate car design?
    And is it auspicious that others are entering the arena with new
    ideas? Or are desktop computers doomed to run Wintel for ever?

    ++L


  2. Re: [9fans] speaking of kenc

    > yes. and is it easier if you build it into the code generator? the
    > designers actually dont give you a choice.


    Not easier, but at least you can escape the constraints laid down by
    the designer, in that only the code generator implementor needs to be
    burdened by them. I'm sure the code generator can be impossibly
    difficult to get right, but you gain the ability to optimise as Plan 9
    C's compiler suite does. You are hardly likely to do so in a straight
    assembler.

    ++L


  3. Re: [9fans] speaking of kenc

    On 5/6/07, Bruce Ellis wrote:
    > yes i don't need imagination. all plan9 C compilers do NOT
    > translate to asm. check it it out and learn something.
    >
    > ken is cleverer than that path.
    >


    i think ken is clever enough to use mnemonics. how different is that
    from assembly?

    can you work with this?

    89 e5 83 ec 08 e8 a9 00 00 00 e8 00 01 00 00 e8 9b 1c 00 00 c9 c3

    believe me i did. debugging a pl/0 code generator.

    ok ken cc is a single pass compiler. there is no assembly anywhere.
    not even in internal buffers.

  4. Re: [9fans] speaking of kenc

    Rogelio Serrano wrote:

    *snip*

    >
    > actually its not hard to create a processor that is generic enough
    > that it does not need assembly and is not locked to any target
    > language.
    >


    Actually it is damned hard to create a processor that *is* 'locked' to any
    language more complex than high/low/tristate tables.

    I'd dare say 'couldn't be done' were it not for Pershing's quote.

    What it *does* with those states, is of course what we have come to call an
    'instruction set', if that is what you really meant by 'language'.

    And there are such - including some x86 compatibles - where portions of that can
    be altered without a major fab change.

    For most use, the trend has been exaclty the other way. Folks prefer a
    guaranteed-stable environment, even if it is a suboptimal one (x86
    'compatibility' again).

    Mostly it is about costs - not 'elegance' or convenience for the coder.

    We've got to 'eat what is on our plate'.

    Bill



  5. Re: [9fans] speaking of kenc

    On 5/6/07, lucio@proxima.alt.za wrote:
    > > yes. and is it easier if you build it into the code generator? the
    > > designers actually dont give you a choice.

    >
    > Not easier, but at least you can escape the constraints laid down by
    > the designer, in that only the code generator implementor needs to be
    > burdened by them. I'm sure the code generator can be impossibly
    > difficult to get right, but you gain the ability to optimise as Plan 9
    > C's compiler suite does. You are hardly likely to do so in a straight
    > assembler.
    >
    > ++L
    >
    >


    assmebler has its place. for a code generator writer it is necessary
    even as an intermediate step. for the rest of us it has no use.

    with the massively parallel processors with high very IPC like the one
    im simulating, assembler is just that. a testing tool.

  6. Re: [9fans] speaking of kenc

    On 5/6/07, W B Hacker wrote:
    > Rogelio Serrano wrote:
    > > On 5/6/07, erik quanstrom wrote:
    > >
    > >>
    > >> this absolutist argument that c is teh bomb. asm suks is silly. it's
    > >> like
    > >> arguing bicycles and ferraris. which one you need (and which one gets
    > >> you there faster) depends on what you're doing.
    > >>

    > >
    > > exactly.
    > >
    > > assembler is there because it is needed. if you are writing or porting
    > > a compiler and you dont have an assembler you will end up writing one
    > > anyway.
    > >

    > ... OR machine-coding the 'primitives' for your own virtual-machine to obviate
    > the need for having to worry about it at all.
    >


    i see. theres a good idea there somewhere. some sort of vm... highly optimised.

    well it can be done. but to abstract all hardware, not possible. it
    will be very complicated and dog slow.

  7. Re: [9fans] speaking of kenc

    > i think this has gone off track. i read brucee's original post as an
    > argument against polluting c with asm()/__asm{}. obviously there is
    > asm in the plan9 distro; try du -a /sys/src| grep '\.s$' . for which
    > it uses /sys/doc/asm.ps


    Brucee slipped, although he did say that the assembler code is in the
    libraries:

    term% du -a /n/sources/plan9/sys/src/cmd | grep '\.s$'
    10 /n/sources/plan9/sys/src/cmd/2a/l.s
    1 /n/sources/plan9/sys/src/cmd/5a/l.s
    1 /n/sources/plan9/sys/src/cmd/5l/l.s
    13 /n/sources/plan9/sys/src/cmd/8a/l.s
    14 /n/sources/plan9/sys/src/cmd/ka/l.s
    1 /n/sources/plan9/sys/src/cmd/unix/drawterm/posix-mips/tas.s
    1 /n/sources/plan9/sys/src/cmd/unix/drawterm/posix-sun4u/tas.s
    13 /n/sources/plan9/sys/src/cmd/va/l.s
    10 /n/sources/plan9/sys/src/cmd/1a/l.s

    That is it.

    ++L


  8. Re: [9fans] speaking of kenc

    Rogelio Serrano wrote:
    > On 5/6/07, W B Hacker wrote:


    *snip*

    >> >

    >> ... OR machine-coding the 'primitives' for your own virtual-machine
    >> to obviate
    >> the need for having to worry about it at all.
    >>

    >
    > i see. theres a good idea there somewhere. some sort of vm... highly
    > optimised.
    >
    > well it can be done. but to abstract all hardware, not possible. it
    > will be very complicated and dog slow.
    >


    Seems otherwise. See Xen, Qemu, VMware, L4 & descendents, Inferno - not to
    mention the long-running won't die revenue king of them all IBM's MV/VM.

    And 'abstract all' needs a virtual dual-ported area of RAM set aside and mapped
    where it has to be, interrupt handlign to go - not too much else.
    Dangerous in the 'wrong hands' but simple enough. or see what DragonFly is doing
    w/r hand offs for so-far-native-DFLY-only virtual kernels. There may be soem
    meat on that bone.

    Only a few of these get at all close to the hardware, yet the speed for the best
    of them (seldom the same answer in every environment) is more than 'good
    enough' to do a great deal of useful thigs - devel at the head of the list.

    I daresay there are few folks here who have not used them or come to appreciate
    them as time-savers vs rebooting 'hardware' native installs.

    Even so - hardware doesn't *necesarily* have to change - multicore and privilege
    separation are fairly recent additions to commodity (x86/AMD) silicon and by no
    means fully utilized by all comers.

    So there *could* be more of these written to run as direct 'native' hosts, and
    probably will be...

    But that doesn't really change the asm / C / whatever 'need set'.

    Just lets it be buried a little deeper under the covers.

    Still no one-size fits all, though.

    Bill



  9. Re: [9fans] speaking of kenc

    On 5/6/07, W B Hacker wrote:
    > Rogelio Serrano wrote:
    > > On 5/6/07, W B Hacker wrote:

    >
    > *snip*
    >
    > >> >
    > >> ... OR machine-coding the 'primitives' for your own virtual-machine
    > >> to obviate
    > >> the need for having to worry about it at all.
    > >>

    > >
    > > i see. theres a good idea there somewhere. some sort of vm... highly
    > > optimised.
    > >
    > > well it can be done. but to abstract all hardware, not possible. it
    > > will be very complicated and dog slow.
    > >

    >
    > Seems otherwise. See Xen, Qemu, VMware, L4 & descendents, Inferno - not to
    > mention the long-running won't die revenue king of them all IBM's MV/VM.
    >
    > And 'abstract all' needs a virtual dual-ported area of RAM set aside and mapped
    > where it has to be, interrupt handlign to go - not too much else.
    > Dangerous in the 'wrong hands' but simple enough. or see what DragonFly is doing
    > w/r hand offs for so-far-native-DFLY-only virtual kernels. There may be soem
    > meat on that bone.
    >


    i see. it does not need to be as big as that actually. just enough to
    avoid writing x86 assembler. and that "blob" can be written using a c
    programmer and then generate object code that can be "linked" to the
    kernel. well what im writing is more of an "event core". there is no
    kernel actually. but the event core without assembly, generated from
    machine definitions is a good idea actually.

  10. Re: [9fans] speaking of kenc

    > well it can be done. but to abstract all hardware, not possible. it
    > will be very complicated and dog slow.


    That's relative. Vista is dog-slow, if what I hear is anything to go
    by. Does that put anyone off?

    I ought to point you to XYwrite II, the first "word processor" I used
    on the PC. I think you need to run it on a 4.7 MHz processor to
    appreciate how fast it was, on modern hardware it would be hard to
    realise that there is plenty untapped performance behind the scenes.

    Speed is there to be consumed, the fashion is to (ab)use it for
    eye-candy and multimedia. Thing is, the decision makers are those
    with the full wallet and they can manipulate the market. The loser is
    the innovation that is the daughter of necessity. But that is another
    subject altogether.

    ++L


  11. Re: [9fans] speaking of kenc

    On 5/6/07, lucio@proxima.alt.za wrote:
    > > well it can be done. but to abstract all hardware, not possible. it
    > > will be very complicated and dog slow.

    >
    > That's relative. Vista is dog-slow, if what I hear is anything to go
    > by. Does that put anyone off?
    >


    slow not really. but complicated yes, that puts me off.

    > I ought to point you to XYwrite II, the first "word processor" I used
    > on the PC. I think you need to run it on a 4.7 MHz processor to
    > appreciate how fast it was, on modern hardware it would be hard to
    > realise that there is plenty untapped performance behind the scenes.


    i understand.

    im not a fan of eye candy either and i like fast low cost systems that
    do what we want them to do.

  12. Re: [9fans] speaking of kenc

    Rogelio Serrano wrote:
    > On 5/6/07, W B Hacker wrote:
    >> Rogelio Serrano wrote:
    >> > On 5/6/07, W B Hacker wrote:

    >>
    >> *snip*
    >>
    >> >> >
    >> >> ... OR machine-coding the 'primitives' for your own virtual-machine
    >> >> to obviate
    >> >> the need for having to worry about it at all.
    >> >>
    >> >
    >> > i see. theres a good idea there somewhere. some sort of vm... highly
    >> > optimised.
    >> >
    >> > well it can be done. but to abstract all hardware, not possible. it
    >> > will be very complicated and dog slow.
    >> >

    >>
    >> Seems otherwise. See Xen, Qemu, VMware, L4 & descendents, Inferno -
    >> not to
    >> mention the long-running won't die revenue king of them all IBM's MV/VM.
    >>
    >> And 'abstract all' needs a virtual dual-ported area of RAM set aside
    >> and mapped
    >> where it has to be, interrupt handlign to go - not too much else.
    >> Dangerous in the 'wrong hands' but simple enough. or see what
    >> DragonFly is doing
    >> w/r hand offs for so-far-native-DFLY-only virtual kernels. There may
    >> be soem
    >> meat on that bone.
    >>

    >
    > i see. it does not need to be as big as that actually. just enough to
    > avoid writing x86 assembler. and that "blob" can be written using a c
    > programmer and then generate object code that can be "linked" to the
    > kernel. well what im writing is more of an "event core". there is no
    > kernel actually. but the event core without assembly, generated from
    > machine definitions is a good idea actually.
    >


    You night also have a look at the latest incarnation of Minix. 4,000 lines of
    code for the kernel?

    May be meat on *that* bone as well...

    Bill



  13. Re: [9fans] speaking of kenc

    lucio@proxima.alt.za wrote:
    >> well it can be done. but to abstract all hardware, not possible. it
    >> will be very complicated and dog slow.

    >
    > That's relative. Vista is dog-slow, if what I hear is anything to go
    > by. Does that put anyone off?
    >
    > I ought to point you to XYwrite II, the first "word processor" I used
    > on the PC.


    I should dig out my copy and try it. Or Vedit or PeachCalc (x80 Visicalc clone).

    RBase for DOS is another one.

    Pretty much lives entirely in the L1 cache of a modern Core-D.
    Work that took 15 miutes on a 386-20 is too fast to bother measuring.

    In the OTHER direction, Netscape for OS/2 used to open in 2 seconds from cold
    SCSI cache, 2/10's of a second from warm on a K6-500, ASUS DA-2100, 20 MB/s SCSI
    drives.

    Now SeaMonkey takes over twice that on Core-D 2.8 GHz, 2G DDR2, SATA 3.

    And OpenOffice? Begone!

    > I think you need to run it on a 4.7 MHz processor to
    > appreciate how fast it was, on modern hardware it would be hard to
    > realise that there is plenty untapped performance behind the scenes.
    >


    See 'Menuet' for a quick desktop. Written in asm, BTW.
    "never say die..."

    > Speed is there to be consumed, the fashion is to (ab)use it for
    > eye-candy and multimedia. Thing is, the decision makers are those
    > with the full wallet and they can manipulate the market. The loser is
    > the innovation that is the daughter of necessity. But that is another
    > subject altogether.
    >
    > ++L
    >
    >


    Ack - we should probably all hit the showers now.

    Been enlightening to get some of these viewpoints aired.
    I'm glad to find that not ALL 9Fans are Luddites, anyway...

    (ducks and waddles off, pun 'inlined'...)

    Bill


  14. Re: [9fans] speaking of kenc

    > slow not really

    I don't know what sort of metric you are using but whatever it is, it's
    wrong.

    My PC has gone from 20,000,000hz to 3,000,000,000hz in 10 years.

    How does Vista boot to GUI compare to Win3.1 ?

    To say Vista/OSX/Lunix are not slow is outrageously naive!

    and for all you asm arguers I say : Windows 3.x, where would we be
    without it's asm goodness !



  15. Re: [9fans] speaking of kenc

    On 5/6/07, matt wrote:
    > > slow not really

    >
    > I don't know what sort of metric you are using but whatever it is, it's
    > wrong.
    >


    i was not saying/claiming that any os is slow.

    > My PC has gone from 20,000,000hz to 3,000,000,000hz in 10 years.
    >
    > How does Vista boot to GUI compare to Win3.1 ?
    >
    > To say Vista/OSX/Lunix are not slow is outrageously naive!
    >


    they are slow. one is even slower than the other but i can live with it.

    > and for all you asm arguers I say : Windows 3.x, where would we be
    > without it's asm goodness !
    >




    --
    the thing i like with my linux pc is that i can sum up my complaints in 5 items

  16. Re: [9fans] speaking of kenc

    have a look at the listed l.s files ... test files!

    On 5/6/07, lucio@proxima.alt.za wrote:
    > > i think this has gone off track. i read brucee's original post as an
    > > argument against polluting c with asm()/__asm{}. obviously there is
    > > asm in the plan9 distro; try du -a /sys/src| grep '\.s$' . for which
    > > it uses /sys/doc/asm.ps

    >
    > Brucee slipped, although he did say that the assembler code is in the
    > libraries:
    >
    > term% du -a /n/sources/plan9/sys/src/cmd | grep '\.s$'
    > 10 /n/sources/plan9/sys/src/cmd/2a/l.s
    > 1 /n/sources/plan9/sys/src/cmd/5a/l.s
    > 1 /n/sources/plan9/sys/src/cmd/5l/l.s
    > 13 /n/sources/plan9/sys/src/cmd/8a/l.s
    > 14 /n/sources/plan9/sys/src/cmd/ka/l.s
    > 1 /n/sources/plan9/sys/src/cmd/unix/drawterm/posix-mips/tas.s
    > 1 /n/sources/plan9/sys/src/cmd/unix/drawterm/posix-sun4u/tas.s
    > 13 /n/sources/plan9/sys/src/cmd/va/l.s
    > 10 /n/sources/plan9/sys/src/cmd/1a/l.s
    >
    > That is it.
    >
    > ++L
    >
    >


  17. Re: [9fans] speaking of kenc

    > The
    > transputer had no assembly.


    Not qute true actually.

    The inmos occam compiler for the transputer did have an inline
    assembly language construct. But this quote from my copy of the
    Transputer Development System manual (1988) shows its use was not
    encouraged. Note the implication that the machine language should
    only be of interest to compiler writers ...

    "The code insertion mechanism enables the user to access the
    instruction set of the transputer directly within the framework of an
    occam program. Symbolic access to occam variable names is supported,
    as is automatic jump sizing. More details on the instruction set may
    be found in the INMOS document 'The transputer instruction set -- a
    compiler writer's guide'.

    "Code insertion may be employed to perform tasks not possible from
    occam, or for particularly time-critical sections of a program. There
    are several reasons, however, which should encourage the user to
    refrain from using code insertion as a solution to problems which may,
    with some thought, be solved using occam. Paramount among these is
    that the validity of a system consisting entirely of occam can be
    checked by the compiler. A compiler can check usage of channels,
    access to variables, communications protocols and range violations. A
    single code insert prevents the compiler from performing these checks
    adequately. A second reason for not using code insertions is that the
    transputer instruction set is suited for use by a high level language,
    particularly occam, and algorithms which are simple to code and easy
    to debug in occam become difficult and obscure when coded in the
    transputer instruction set directly."


  18. Re: [9fans] speaking of kenc

    On Sun, 2007-05-06 at 14:18 +0100, Richard Miller wrote:
    > > The
    > > transputer had no assembly.

    >
    > Not qute true actually.
    >
    > The inmos occam compiler for the transputer did have an inline
    > assembly language construct. But this quote from my copy of the
    > Transputer Development System manual (1988) shows its use was not
    > encouraged. Note the implication that the machine language should
    > only be of interest to compiler writers ...
    >
    > "The code insertion mechanism enables the user to access the
    > instruction set of the transputer directly within the framework of an
    > occam program. Symbolic access to occam variable names is supported,
    > as is automatic jump sizing. More details on the instruction set may
    > be found in the INMOS document 'The transputer instruction set -- a
    > compiler writer's guide'.
    >
    > "Code insertion may be employed to perform tasks not possible from
    > occam, or for particularly time-critical sections of a program. There
    > are several reasons, however, which should encourage the user to
    > refrain from using code insertion as a solution to problems which may,
    > with some thought, be solved using occam. Paramount among these is
    > that the validity of a system consisting entirely of occam can be
    > checked by the compiler. A compiler can check usage of channels,
    > access to variables, communications protocols and range violations. A
    > single code insert prevents the compiler from performing these checks
    > adequately. A second reason for not using code insertions is that the
    > transputer instruction set is suited for use by a high level language,
    > particularly occam, and algorithms which are simple to code and easy
    > to debug in occam become difficult and obscure when coded in the
    > transputer instruction set directly."


    The above sounds very appropriate. Note, that given a proper mechanism
    for creating asm-based intrinsic routines and also a proper mechanism
    for inlining them -- we can have a very attractive solution to the
    asm problem in C language as well. From that vantage point, GNU __asm
    inlines surely seem like an overkill.

    Thanks,
    Roman.


  19. Re: [9fans] speaking of kenc

    On Sun, 2007-05-06 at 00:08 -0400, erik quanstrom wrote:
    > clearly, an assembly is more difficult to wield than c. but you don't
    > use them for the same thing.
    >
    > this absolutist argument that c is teh bomb. asm suks is silly. it's like
    > arguing bicycles and ferraris. which one you need (and which one gets
    > you there faster) depends on what you're doing.


    I think I would like to run with this analogy for a little while
    longer. I happen to like it. You see, what I'm asking for is far
    from passing a final judgment. What I'm asking for is a special
    kind of bike that I can store in my Ferrari somehow and use it
    on those special occasions when I'm really stuck someplace. I happen
    to like the analogy because as much as Ferrari is not the type of
    car that would land itself easily to any kind of roof rails
    or roof racks C language is the same way.

    Thanks,
    Roman.


  20. Re: [9fans] speaking of kenc

    On Sat, 2007-05-05 at 23:04 -0700, Skip Tavakkolian wrote:
    > i think this has gone off track.


    ain't that the fun? ;-)

    > i read brucee's original post as an
    > argument against polluting c with asm()/__asm{}.


    As always -- brucee is articulating a point that reminds me
    of paternalistic, patronizing laws. Look, CPUs are giving me
    a particular language and C doesn't cover all of it. Brucee
    tells us: tough luck -- you can't have that richer vocabulary,
    I say we need to think of something that lets us tap into that
    pool of extra words. And yes some of them can be dirty words,
    but even they are REALLY needed from time to time. I dislike
    potty mouths as much as the next guy (and GCC __asm is way
    too potty for my taste) but I can really appreciate a fine
    use of F2K words(*).

    Thanks,
    Roman.

    (*) there's probably a connection between this statement and
    the fact that Russian is one of the languages where F2K
    vocabulary is REALLY rich ;-)


+ Reply to Thread
Page 6 of 7 FirstFirst ... 4 5 6 7 LastLast