---

HTML 5 er agterudsejlet. Længe inden de får sig snøvlet færdig,
skrivers der til web i maskinkode, f.eks. C ellerC++:

http://newz.dk/chrome-14-kan-afvikle-maskinkode-direkte
--
Venlig hilsen
Kurt Hansen

Søges: En person der kan passe heste, som ikke ryger eller drikker.

---

On 18-08-2011 18:26, Kurt Hansen wrote:
> HTML 5 er agterudsejlet. Længe inden de får sig snøvlet færdig,
> skrivers der til web i maskinkode, f.eks. C ellerC++:
>
> http://newz.dk/chrome-14-kan-afvikle-maskinkode-direkte

Som om folk ikke har problemer nok med html og css.
Skal de nu også være C-programmører?

Næ du, html5 er forældet lang tid før den spådom går i opfyldelse.

Og så fortæl lige Microsoft at IE skal geares til det

Men at det bliver en option er da meget muligt, især på håndholdte.

Karl Erik.

--
http://dmwebdesign.dk - DM i Webdesign
http://twitter.com/kechriste
http://webdesign.ranunkelvej.com - Artikler om webdesign

---

Kurt Hansen sendte dette med sin computer:
> HTML 5 er agterudsejlet. Længe inden de får sig snøvlet færdig,
> skrivers der til web i maskinkode, f.eks. C ellerC++:
>
> http://newz.dk/chrome-14-kan-afvikle-maskinkode-direkte

Det jeg så hæfter mig ved her, er ordet "maskinkode" - og det er der
vist ingen der bruger længere.
Der er for længt fremstillet compilere og oversættere, der kan generere
maskinkoden fra et højere niveau sprog - der er læsbart af mennesker,
til forskel fra maskinkoden.

C og C++ (og PASCAL og BASIC - og hvad de nu hedder alle sammen) kan i
forvejen omsættes til maskinkode, der gemmes i eksekverbare programmer
(.com filer oprindeligt, .exe filer for ikke så længe siden - i dag
kaldes de applikationer).

Og hvorfor i al verden skal vi nu til at have dem til at køre i
browseren?
Jeg kan da godt se nogle muligheder - spændende endda - hvis det
blandes ind i HTML (og hvis ikke, hvad har det så med browseren at
gøre?).
Men jeg kan også se en masse "u-muligheder". Bare
browsercompatibiliteten, til at begynde med.
Før det bliver realistisk at bruge i web-sammenhæng, skal de andre
browsere med - eller Chrome skal vælte dem af banen. Skulle IE falde af
i svinget, er vi mange problemer kvit, så det ville vel ikke gøre så
meget. Men de andre vil jo nok forsøge at følge med, afhængig af hvor
populært dette nye legetøj bliver.
Et andet problem er, at det såvidt jeg kan se, endnu ikke kan køre på
alle CPU'er. Så vi skal ikke kun designe til specifikke browsere med
det - om brugeren kan se noget fornuftigt, er også afhængigt af den
CPU, der sidder i hyns maskine. Og fallback bliver vist lidt af en
umulighed. Til gengæld vil der blive brug for en helt ny meddelelse:
"Du bliver nødt til at investere i en ny PC, hvis du vil være med her".
Og det er noget andet end "Hvis du vil se denne side, skal du bruge en
browser i stedet for IE; de fås gratis _her_ og _her_ og _her_..."

Realistisk, går der nogle år, før application/x-nacl bliver generelt
anvedeligt. Så jeg venter med at vinke farvel til HTML5.

I øvrigt, køres en sådan application i <embed> tag - så der er ikke
tale om at vælge mellem HTML og en applikation, men om at bruge den som
en del af HTML.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 18-08-2011 19:47, Birger Sørensen wrote:

> Det jeg så hæfter mig ved her, er ordet "maskinkode" - og det er der
> vist ingen der bruger længere.
> Der er for længt fremstillet compilere og oversættere, der kan generere
> maskinkoden fra et højere niveau sprog - der er læsbart af mennesker,
> til forskel fra maskinkoden.

> Birger
>

Du får 03, men bevarer retten til at komme igen næste år

Ovenstående viser at du har misforstået opgaven.

Karl Erik.

--
http://dmwebdesign.dk - DM i Webdesign
http://twitter.com/kechriste
http://webdesign.ranunkelvej.com - Artikler om webdesign

---

Karl Erik Christensen skrev:
> On 18-08-2011 19:47, Birger Sørensen wrote:
>
>> Det jeg så hæfter mig ved her, er ordet "maskinkode" - og det er der
>> vist ingen der bruger længere.
>> Der er for længt fremstillet compilere og oversættere, der kan generere
>> maskinkoden fra et højere niveau sprog - der er læsbart af mennesker,
>> til forskel fra maskinkoden.
>
>> Birger
>>
>
> Du får 03, men bevarer retten til at komme igen næste år
>
> Ovenstående viser at du har misforstået opgaven.
>
> Karl Erik.

Eller måske at du ikke har læst resten...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 18 Aug., 19:47, Birger Sørensen <s...@bbsorensen.com> wrote:

> Og hvorfor i al verden skal vi nu til at have dem til at køre i
> browseren?
> Jeg kan da godt se nogle muligheder - spændende endda - hvis det
> blandes ind i HTML (og hvis ikke, hvad har det så med browseren at
> gøre?).

Det er Googles idé, officielt fordi de vil have alt til at køre
pissehurtigt, og det er C++ sådan set også. Men Google har nok også en
anden mening med det, fordi Google Chrome (browseren) udvikles
sideløbende med ChromiumOS (Googles operativsystem), og det OS det er
jo webbaseret, også i applikationerne. Der vil bare være nogle
applikationer (måske spil, men i hvert fald alt med grafik/
lydeditering), hvor en JS-webbaseret applikation er alt for langsom
til, det vil føles brugervenligt, selv med AJAX.

Derfor muligheden for at afvikle C++ i ChromiumOS, og ja C++ skulle
efter sigende være ret tæt på maskinkode i hastighed - og DET er
hurtigt.

Men udføre maskinkode i browseren som standard, hmmmmm. Microsoft
forsøgte med at udføre egentlige applikationer i deres browser via
ActiveX - det førte til et rent helvede at gule "advarselsruder" og
førte senere til StuxNet.

Problemet er nemlig, at hvis man giver browseren samme rettigheder som
egentlige programmer, så kan browseren for så vidt slette hele
systemet, hvis det er det eller installere rootkit. Og en uvidende
bruger er nem at tricke til bare at trykke JA via social engineering.
Det er faktisk nogenslunde hvad der sker nu - bare via Flash, som også
er en slags browserapplikation. Derfor man bør slå Flash fra, alle
steder det ikke bruges.

En browser må aldrig kunne få eller afgive rettigheder ud over
browser"sandkassen". Browseren er (bør være) helt afskærmet fra resten
af OSet. Det var Chrome til at starte med, og det er én af grundene
til, jeg valgte den browser.


PS og interessant nok - i Chromium 15, som er Canary Build af Chrome
browseren, der gør Google det faktisk muligt at lade
browserapplikationer kører også efter at browseren er lukket. Jeg ved
ikke, om jeg kan lide deres nye idéer. I hvert fald håber jeg, de har
gode forklaringer, hvis det bliver til en standard senere i stable
releasen.

"Apps i baggrunden    Continue running background apps when Chromium is
closed"


MVH
Rune Jensen

---

Efter mange tanker skrev runeofdenmark@hotmail.com:
> On 18 Aug., 19:47, Birger Sørensen <s...@bbsorensen.com> wrote:
>
>> Og hvorfor i al verden skal vi nu til at have dem til at køre i
>> browseren?
>> Jeg kan da godt se nogle muligheder - spændende endda - hvis det
>> blandes ind i HTML (og hvis ikke, hvad har det så med browseren at
>> gøre?).
>
> Det er Googles idé, officielt fordi de vil have alt til at køre
> pissehurtigt, og det er C++ sådan set også. Men Google har nok også en
> anden mening med det, fordi Google Chrome (browseren) udvikles
> sideløbende med ChromiumOS (Googles operativsystem), og det OS det er
> jo webbaseret, også i applikationerne. Der vil bare være nogle
> applikationer (måske spil, men i hvert fald alt med grafik/
> lydeditering), hvor en JS-webbaseret applikation er alt for langsom
> til, det vil føles brugervenligt, selv med AJAX.

Hvorfor skal en lydeditor kører over web?
Vi har Java i forvejen. (Og hvis det ikke lige var for ikke-så-N3M_ID,
kunne det sagtens spares væk...). Det er så stadig kildekode, der
oversættes/kompileres, når det skal bruges.
Der er tale om samme principper - blot bruger man kompileret kode, i
stedet for kildekode.

> Derfor muligheden for at afvikle C++ i ChromiumOS, og ja C++ skulle
> efter sigende være ret tæt på maskinkode i hastighed - og DET er
> hurtigt.

Alt hvad der køres er makinkode - det er det *eneste* CPU'en kan
afvikle. *Alt* andet skal enten oversættes eller kompileres. Der er så
forskel på, hvor hurtig kode oversættere/kompilere genrerer.
(Formentlig noget med at jo mere højniveau-sproget ligner maskinkode,
jo hurtigere vil den genererede maskinkode være).
Det gælder også js.
Forskellen består i at ting i browseren (fra web) skal køres i
sandkassen, fordi det er potentielt farligt for OS'et, og det vil
formentlig gøre tingene langsommere.
Så rent principielt, kan de jo "bare" skrive en ordentlig oversætter
fra js til maskinkode - så er der ikke behov for "Native Client". :D

Som jeg ser det, er det nye, at der kan bruges *maskinkode*. Altså
programmer der allerede er kompileret, og derfor ikke skal oversættes
(som de nuværende sccript-sprog skal). Og det kan give en (formentlig
væsentlig) hastighedsforøgelse.
Principielt skulle man så kunne bruge en hvilket som helt maskinkode.
Og hvis man tillod det, ville hele nettet være lagt ned i løbet af en
dags tid.
Derfor sandkassen, og det specielle SDK til kompilering af programmerne
- og begrænsningen til at skrive i C eller C+.
Man skal bemærke, at det der hentes er kompilerede koder (maskinkode) -
*ikke* sourcekode.

> Men udføre maskinkode i browseren som standard, hmmmmm. Microsoft
> forsøgte med at udføre egentlige applikationer i deres browser via
> ActiveX - det førte til et rent helvede at gule "advarselsruder" og
> førte senere til StuxNet.

M$ er jo ikke kendt for høj sikkerhed. AcitveX bliver ikke tilladt her.
>
> Problemet er nemlig, at hvis man giver browseren samme rettigheder som
> egentlige programmer, så kan browseren for så vidt slette hele
> systemet, hvis det er det eller installere rootkit. Og en uvidende
> bruger er nem at tricke til bare at trykke JA via social engineering.
> Det er faktisk nogenslunde hvad der sker nu - bare via Flash, som også
> er en slags browserapplikation. Derfor man bør slå Flash fra, alle
> steder det ikke bruges.
>
> En browser må aldrig kunne få eller afgive rettigheder ud over
> browser"sandkassen". Browseren er (bør være) helt afskærmet fra resten
> af OSet. Det var Chrome til at starte med, og det er én af grundene
> til, jeg valgte den browser.
>
>
> PS og interessant nok - i Chromium 15, som er Canary Build af Chrome
> browseren, der gør Google det faktisk muligt at lade
> browserapplikationer kører også efter at browseren er lukket. Jeg ved
> ikke, om jeg kan lide deres nye idéer. I hvert fald håber jeg, de har
> gode forklaringer, hvis det bliver til en standard senere i stable
> releasen.
>
> "Apps i baggrunden    Continue running background apps when Chromium is
> closed"

Er helt enig i at der er nogle alvorlige sikkerheds aspekter i det.
Der skal et meget fintmasket filter i sandkassen. Jeg vil tro, det er
derfor der (indtil videre i hvert fald) skal anvendes den specielle SDK
til at generere maskinkoden - den må på en eller anden måde makere
koden, så sandkassen kan arbejde med den.

Baggrunsjob startet af en tilfældig hjemmeside?
Vi skal vel snart til at bede om tilladelse til at slukke vores egen
PC, når alle de andre er færdige med at rode rundt i hvad der findes på
diskene...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

> Søges: En person der kan passe heste, som ikke ryger eller drikker.

-Gælder det egentlig ikke de fleste heste, bortset fra vand?
-Omvendt er det vistnok sjældent at se heste, der både ryger og
drikker..

høhø




--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Den 18-08-2011 18:26, Kurt Hansen skrev:
> HTML 5 er agterudsejlet. Længe inden de får sig snøvlet færdig,
> skrivers der til web i maskinkode, f.eks. C ellerC++:

Det er dog er forfærdelig gang vrøvl!

C eller C++ er *ikke* maskinkode.
Det er programmeringssprog!
Det er først når de bliver oversat, at man kan tale om maskinkode, men
så er det jo ikke længere C, så er det Intel 8086, Intel 80268,
o.s.v.-kode, og det er noget helt andet end C, Fortran, Pascal, Java,
PHP, ...
(Ja så vil nogen måske indvende, at Java kun bliver fortolket i deres
JVM; men der er altså også HW, der kan eksekvere oversat
Java-mellemkode, ligesom der er skrevet virtuelle maskiner, der kan
fortolke Intel 8086-kode)

Hilsen
Allan

---

Allan skrev den 20-08-2011:
> Den 18-08-2011 18:26, Kurt Hansen skrev:
>> HTML 5 er agterudsejlet. Længe inden de får sig snøvlet færdig,
>> skrivers der til web i maskinkode, f.eks. C ellerC++:
>
> Det er dog er forfærdelig gang vrøvl!
>
> C eller C++ er *ikke* maskinkode.
> Det er programmeringssprog!
> Det er først når de bliver oversat, at man kan tale om maskinkode, men så er
> det jo ikke længere C, så er det Intel 8086, Intel 80268, o.s.v.-kode, og det
> er noget helt andet end C, Fortran, Pascal, Java, PHP, ...
> (Ja så vil nogen måske indvende, at Java kun bliver fortolket i deres JVM;
> men der er altså også HW, der kan eksekvere oversat Java-mellemkode, ligesom
> der er skrevet virtuelle maskiner, der kan fortolke Intel 8086-kode)

Ikke desto mindre, er det afvikling af *maskinkode* det handler om,
Makinkode gereret af en speciel SDK, der kan håndtere C og C++

At det så måske er en lidt bastant udtalelse...
For mig at se, er det ikke mere vrøvl end at påstå der findes HW der
kan afvikle nogen som helst anden form for kode end makinkode, og/eller
sætte lighedstegn mellem HW og virtuelle maskiner...

Et er bogstaverne, noget andet meningen bag dem.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

> At det så måske er en lidt bastant udtalelse...
> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
> afvikle nogen som helst anden form for kode end makinkode, og/eller
> sætte lighedstegn mellem HW og virtuelle maskiner...
>
> Et er bogstaverne, noget andet meningen bag dem.
>
Min antagelse var, at forfatten skrev, hvad kan mente.

---

Allan forklarede den 8/21/2011:
>> At det så måske er en lidt bastant udtalelse...
>> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
>> afvikle nogen som helst anden form for kode end makinkode, og/eller
>> sætte lighedstegn mellem HW og virtuelle maskiner...
>>
>> Et er bogstaverne, noget andet meningen bag dem.
>>
> Min antagelse var, at forfatten skrev, hvad kan mente.

Der er mange måder at udtrykke den samme mening på.
Og selv om du ikke er enig med måden eller de ord der bruges til at
udtrykke den, gør det ikke forsøget til noget vrøvl.

Birger.

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 21-08-2011 14:02, Birger Sørensen skrev:
> Allan forklarede den 8/21/2011:
>>> At det så måske er en lidt bastant udtalelse...
>>> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
>>> afvikle nogen som helst anden form for kode end makinkode, og/eller
>>> sætte lighedstegn mellem HW og virtuelle maskiner...
>>>
>>> Et er bogstaverne, noget andet meningen bag dem.
>>>
>> Min antagelse var, at forfatten skrev, hvad kan mente.
>
> Der er mange måder at udtrykke den samme mening på.
> Og selv om du ikke er enig med måden eller de ord der bruges til at
> udtrykke den, gør det ikke forsøget til noget vrøvl.

Jeg er enig i, at det kan være mange måder at udtrykke den samme mening
på, men det bliver det jo altså ikke rigtig af.

Hvis der er en, der påstår at 1 + 1 = 3, så bliver det altså ikke
korrekt, uanset hvordan det udtrykkes.

---

Allan kom med denne ide:

>
> Hvis der er en, der påstår at 1 + 1 = 3, så bliver det altså ikke korrekt,
> uanset hvordan det udtrykkes.

Så er det noget vrøvl

--
Mvh John
www.wordpresstema.dk
www.wordpress.dk/forum

---

On 21-08-2011 20:01, John wrote:
> Allan kom med denne ide:
>
>>
>> Hvis der er en, der påstår at 1 + 1 = 3, så bliver det altså ikke
>> korrekt, uanset hvordan det udtrykkes.
>
> Så er det noget vrøvl
>

Kan du ved af sætte 3 streger, få dette til at være rigtigt?

101+101=201

Karl Erik.

--
http://dmwebdesign.dk - DM i Webdesign
http://twitter.com/kechriste
http://webdesign.ranunkelvej.com - Artikler om webdesign

---

Karl Erik Christensen formulerede spørgsmålet:
> On 21-08-2011 20:01, John wrote:
>> Allan kom med denne ide:
>>
>>>
>>> Hvis der er en, der påstår at 1 + 1 = 3, så bliver det altså ikke
>>> korrekt, uanset hvordan det udtrykkes.
>>
>> Så er det noget vrøvl
>>
>
> Kan du ved af sætte 3 streger, få dette til at være rigtigt?
>
> 101+101=201
>
> Karl Erik.

1Øl+1Øl=2Øl

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Allan kom med denne ide:
> Den 21-08-2011 14:02, Birger Sørensen skrev:
>> Allan forklarede den 8/21/2011:
>>>> At det så måske er en lidt bastant udtalelse...
>>>> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
>>>> afvikle nogen som helst anden form for kode end makinkode, og/eller
>>>> sætte lighedstegn mellem HW og virtuelle maskiner...
>>>>
>>>> Et er bogstaverne, noget andet meningen bag dem.
>>>>
>>> Min antagelse var, at forfatten skrev, hvad kan mente.
>>
>> Der er mange måder at udtrykke den samme mening på.
>> Og selv om du ikke er enig med måden eller de ord der bruges til at
>> udtrykke den, gør det ikke forsøget til noget vrøvl.
>
> Jeg er enig i, at det kan være mange måder at udtrykke den samme mening på,
> men det bliver det jo altså ikke rigtig af.
>
> Hvis der er en, der påstår at 1 + 1 = 3, så bliver det altså ikke korrekt,
> uanset hvordan det udtrykkes.

Åh - det er dig der bestemmer hvilken mening Kurt Hansen skal have,
eller hvordan?
Eller er det bare dig der bestemmer om hans mening er rigtig?

Hvis Kurt Hansen skriver at han mener at NativeClient overhaler HTML5,
tror jeg på at det er det han mener.
Og det tilkommer ikke dig at bedømme om han har lov til at have den
mening, eller udråbe det som crøvl.

1+1 = 11 det ved enhver da. Nogen gange kan det så nøjes med at være
10.


Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

<snip>
> 1+1 = 11 det ved enhver da. Nogen gange kan det så nøjes med at være 10.

Touché

Hilsen
Allan

---

Allan skrev:

>> 1+1 = 11 det ved enhver da. Nogen gange kan
> det så nøjes med at være 10.
> Touché

Det lyder fransk, men hvad betyder det?

--
Allan Vebel
http://vebel.dk/wdg

---

Allan Vebel skrev:

>> Touché

> Det lyder fransk, men hvad betyder det?

Direkte oversat: "ramt", jf. det engelske "touch".

Det bruges i fægtekunsten når den ene part får et stød sat ind.
Det bruges i overført betydning når nogen bliver ramt. Det kan
siges både af den der rammer, og af den der bliver ramt.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Den 21/08/11 20.04, Birger Sørensen skrev:
> Allan kom med denne ide:
>
>> Hvis der er en, der påstår at 1 + 1 = 3, så bliver det altså ikke
>> korrekt, uanset hvordan det udtrykkes.
>
> Åh - det er dig der bestemmer hvilken mening Kurt Hansen skal have,
> eller hvordan?
> Eller er det bare dig der bestemmer om hans mening er rigtig?
>
> Hvis Kurt Hansen skriver at han mener at NativeClient overhaler HTML5,
> tror jeg på at det er det han mener.

Nu er jeg jo ikke så klog, at nogen af jer skal frygte at jeg
agterudsejler jer. Det er blot en filosofisk vision om, at når der
bliver lukket op for posen, vil mange føles sig fristet til at erstatte
en traditionel hjemmeside, der virker ved fortløbende tolkning af kode i
simple tags, med et egentligt program - en applikation.

Man ser jo allerede mange sites, hvor store dele kører i Flash, der -
sammenlignet med et fuldt udbygget programmeringssprog - er ret primitivt.

Hvis jeg i fremtiden skulle lave en hjemmeside om f.eks. slægtsforskning
(og hvis jeg havde evnerne til det), ville der ikke være ret mange
HTML-koder. Jeg vil simpelthen afvikle et interaktivt program i
brugerens browser. Der er uanede muligheder.
--
Venlig hilsen
Kurt Hansen

---

On 2011-08-22 06:27, Kurt Hansen wrote:
....
>
> Nu er jeg jo ikke så klog, at nogen af jer skal frygte at jeg agterudsejler jer. Det er
> blot en filosofisk vision om, at når der bliver lukket op for posen, vil mange føles sig
> fristet til at erstatte en traditionel hjemmeside, der virker ved fortløbende tolkning af
> kode i simple tags, med et egentligt program - en applikation.
>
> Man ser jo allerede mange sites, hvor store dele kører i Flash, der - sammenlignet med et
> fuldt udbygget programmeringssprog - er ret primitivt.

Bortset fra flash mv. ikke er "standardiseret".

Flash: laves kun af Adobe, og det er ikke en åben standard, og der
er ikke alternative producenter der tilbyder en brugbar flash-player.
Flash findes kun til de platforme som Adobe syntes de vil lave en reader til.
Flash bruger ofte for meget CPU på små netbooks og laptops mv, og
er ofte den hyppigste grund til min FF crasher.
Man kan ikke linke til indhold indeni Flash sider; og jeg kan ikke klippe klistre,
f.eks. til SydEnergy's gamle kundelogon-side, så kundenumre skal indtastes... ;(
(heldigvis er de gået bort fra dette :)

Flash er egnet til det det var tiltænkt, men ikke til hele hjemmesider
(der er nogle firmaer der har "brændt" fingrene, f.eks. kan man jo ikke
linke til varenumre/varer i flash)

... i Firefox er "flashblock" den addon jeg altid installerer, da der
også er mange reklamer i flash, og der er ingen grund til at spilde
batteritid på disse.


> Hvis jeg i fremtiden skulle lave en hjemmeside om f.eks. slægtsforskning (og hvis jeg
> havde evnerne til det), ville der ikke være ret mange HTML-koder. Jeg vil simpelthen
> afvikle et interaktivt program i brugerens browser. Der er uanede muligheder.

Hvilken platform kører din "bruger" så ?
hvad hvis brugerens platform ikke har flash , active-X eller hvad det nu måtte være ?
Eller brugeren er blind/svagtseende og bruger et braille-tastatur og noget lignende
en tekst-baseret browser ?

Eller kan du leve med at det ikke er alle "brugere" der kan "bruge" din hjemmeside?
Nogen gange hvis det er til en lille afgrænset gruppe på samme platform kan det
jo være helt ok.
Eller måske du skulle lave et program til at løse opgaven (C/C++) ,
til en given platform så du helt slipper for browseren,
f.eks. hvis alle brugere har Mac så laver du en MaxOSX udgave.


Jeg vil betakke mig for mere binær kode der skal afvikles i min browser;
det er slemt nok med flash og java*, og active-X på windows).

HTML og http derimod er godt standardiseret, og bør virke på
browsere der følger standarden.


*PS.
Java findes i en "åben" version , men ofte er det ikke alle java-applets der
virker i alle java-versioner (netbanker er de mest kræsne...)

men det der startede det hele var Chrome og Native Client, og øjensynlig
er det kun til app's til gogle's webstore, og de skal vist oversættes
til en eller flere af tre platforme.
Og så vidt jeg kan se virker det kun i Chrome, ikke Konqueror, Firefox,
IE, Safari,....



PS2
og nu forstår jeg ikke helt hvordan HTML5 skulle være et alternativ til
f.eks. Java/javascript/flash/CC-C++...
Det er helt forskellige ting, HTML5+CSS er til at vise "indhold", og det
andet til "programmer" der evt. skal køre i browser.

---

Den 22/08/11 11.22, Frank Damgaard skrev:
> On 2011-08-22 06:27, Kurt Hansen wrote:
> ....
>>
>> Hvis jeg i fremtiden skulle lave en hjemmeside om f.eks. slægtsforskning (og hvis jeg
>> havde evnerne til det), ville der ikke være ret mange HTML-koder. Jeg vil simpelthen
>> afvikle et interaktivt program i brugerens browser. Der er uanede muligheder.

> Hvilken platform kører din "bruger" så ?

Det er vel ligegyldigt, hvis det er den eksponerende browser der er
indeholder motoren? Jeg forholder mig rent teoretisk og filosofisk til
den artikel jeg henviste til.

I enhver browser er der i dag en HTML-fortolker. I fremtiden bliver den
bare skiftet ud (eller suppleret) med en fortolker/interpreter/compiler
der viser det på skærmen som maskinkoden fortæller den.

> HTML og http derimod er godt standardiseret, og bør virke på
> browsere der følger standarden.

Hele ideen står og falder med at alle browserfabrikanter bliver enige om
en standard, men det er jo ikke forskelligt fra situationen i dag.

Og sikkerhedsproblemer .. jo jo, dem er der helt sikkert mange af, men
det hele er jo på idé- og forsøgsstadiet endnu. Det er endnu for tidligt
at dødsdømme det af den grund.

Men prøv lige at skrælle alle forbeholdene af og abstrahér: For mig at
se vil det betyde en omvæltning i samme størrelsesorden, som da en fandt
på et lægge en grafisk brugerflade på internettet.
--
Venlig hilsen
Kurt Hansen

---

On 2011-08-22 12:34, Kurt Hansen wrote:
> Den 22/08/11 11.22, Frank Damgaard skrev:
>> On 2011-08-22 06:27, Kurt Hansen wrote:
>> ....
>>>
>>> Hvis jeg i fremtiden skulle lave en hjemmeside om f.eks. slægtsforskning (og hvis jeg
>>> havde evnerne til det), ville der ikke være ret mange HTML-koder. Jeg vil simpelthen
>>> afvikle et interaktivt program i brugerens browser. Der er uanede muligheder.
>
>> Hvilken platform kører din "bruger" så ?
>
> Det er vel ligegyldigt, hvis det er den eksponerende browser der er indeholder motoren?
> Jeg forholder mig rent teoretisk og filosofisk til den artikel jeg henviste til.
>
> I enhver browser er der i dag en HTML-fortolker. I fremtiden bliver den bare skiftet ud
> (eller suppleret) med en fortolker/interpreter/compiler der viser det på skærmen som
> maskinkoden fortæller den.
>
>> HTML og http derimod er godt standardiseret, og bør virke på
>> browsere der følger standarden.
>
> Hele ideen står og falder med at alle browserfabrikanter bliver enige om en standard, men
> det er jo ikke forskelligt fra situationen i dag.

det kan tage mange år, indtil videre er det en chrome only og til "apps" der skal sælges
via deres webstore.
og andre browsere skal lige se "fidusen".


>
> Og sikkerhedsproblemer .. jo jo, dem er der helt sikkert mange af, men det hele er jo på
> idé- og forsøgsstadiet endnu. Det er endnu for tidligt at dødsdømme det af den grund.
>
> Men prøv lige at skrælle alle forbeholdene af og abstrahér: For mig at se vil det betyde
> en omvæltning i samme størrelsesorden, som da en fandt på et lægge en grafisk brugerflade
> på internettet.


Ja, hvorfor blev Java så ikke lige det alle bruger?
den er vist allerede 16 år gammel ...
og ideen var jo netop at det skulle være til alle OS, og hardware platforme.

hmm. nå ja, MS jo lavede jo sin ikke helt kompatible virtual machine (java)
som sænkede den oprindelige Java, da den javavewrsion krævede windows og IE....
og nu er de igang med deres egen inkompatible .Net med C# , silverlight mfl.

og så har vi nu google chrome med sin egen C/c++ "bytekompiler" til kun
3 stk OS/platforme. men måske om 15 år er det blevet en standard :)

---

Kurt Hansen forklarede den 8/22/2011:
8X
> I enhver browser er der i dag en HTML-fortolker. I fremtiden bliver den bare
> skiftet ud (eller suppleret) med en fortolker/interpreter/compiler der viser
> det på skærmen som maskinkoden fortæller den.

Der er givetvismange muligheder i fremtiden, også mange, både meget
spændende og anvendelige.
Dette Native Client kører dog i et <embed> element i HTML - altså
stadig "indeni" HTML.
Og hvis det ikke er blandet med HTML, og altså fungerer som en del af
en side, har jeg lidt svært ved at se hvorfor det skal køre i
browseren. Så kan det lige så godt køre som en selvstændig applikation.
Forskellen er vel umiddelbart, at i browseren skal applikationen hentes
hver gang den startes, hvor den som selvstændig applikation, kun skal
hentes een gang.

8X
> Men prøv lige at skrælle alle forbeholdene af og abstrahér: For mig at se vil
> det betyde en omvæltning i samme størrelsesorden, som da en fandt på et lægge
> en grafisk brugerflade på internettet.

Øhhh - den må du gerne uddybe. Hvordan ser den grafiske brugerflade på
internettet ud, og hvor findes den?
B-)

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 22/08/11 14.57, Birger Sørensen skrev:
> Kurt Hansen forklarede den 8/22/2011:
>
>> Men prøv lige at skrælle alle forbeholdene af og abstrahér: For mig at
>> se vil det betyde en omvæltning i samme størrelsesorden, som da en
>> fandt på et lægge en grafisk brugerflade på internettet.

> Øhhh - den må du gerne uddybe. Hvordan ser den grafiske brugerflade på
> internettet ud, og hvor findes den?
> B-)

Oh well, måske ikke en heldig og forståelig formulering, men jeg
hentyder til 1993, hvor Marc Andreessen søsatte Mosaic (forløberen for
Netscape) med inline-visning af billeder. Før den tid var internet ren
tekst, men frit mig ikke ud om detaljer; dem husker jeg ikke.
--
Venlig hilsen
Kurt Hansen

---

Kurt Hansen kom med denne ide:
> Den 22/08/11 14.57, Birger Sørensen skrev:
>> Kurt Hansen forklarede den 8/22/2011:
> >
>>> Men prøv lige at skrælle alle forbeholdene af og abstrahér: For mig at
>>> se vil det betyde en omvæltning i samme størrelsesorden, som da en
>>> fandt på et lægge en grafisk brugerflade på internettet.
>
>> Øhhh - den må du gerne uddybe. Hvordan ser den grafiske brugerflade på
>> internettet ud, og hvor findes den?
>> B-)
>
> Oh well, måske ikke en heldig og forståelig formulering, men jeg hentyder til
> 1993, hvor Marc Andreessen søsatte Mosaic (forløberen for Netscape) med
> inline-visning af billeder. Før den tid var internet ren tekst, men frit mig
> ikke ud om detaljer; dem husker jeg ikke.

http://www.w3.org/History.html

Den første "browser" hed Nexus (WorlsWideWeb), programmeret i 1990 af
Tim Bernes-Lee, og den kunne godt vise billeder...

http://www.w3.org/People/Berners-Lee/WorldWideWeb.html

Browseren er vel det du mener med "en grafisk brugerflade".
I øvrigt er WWW kun en del af internettet. Det kan bruges - og bliver
brugt - på mange andre måder.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Forskellen er vel umiddelbart, at i browseren skal applikationen hentes
> hver gang den startes, hvor den som selvstændig applikation, kun skal
> hentes een gang.

Forskellen er mere at man bruger browserens grafiske brugerflade.

Det var(er) det samme med ActiveX, hvor en applikation får 'browser-like'
look.

MHT at hente, så kan applikationen caches akkurat som med sider,billeder
m.m.

Mon ikke tiltaget er møntet på mobile devices?

--
Med venlig hilsen
Stig Johansen

---

<snip>
> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
> afvikle nogen som helst anden form for kode end makinkode,

Så er der en artikel her, der sikkert vil interessere dig:
http://en.wikipedia.org/wiki/Java_processor

Hilsen
Allan

---

Allan formulerede Sunday:
> <snip>
>> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
>> afvikle nogen som helst anden form for kode end makinkode,
>
> Så er der en artikel her, der sikkert vil interessere dig:
> http://en.wikipedia.org/wiki/Java_processor
>
> Hilsen
> Allan

"A Java processor is the implementation of the Java Virtual Machine
(JVM) in hardware. In other words the bytecodes that make up the
instruction set of the abstract machine become the instruction set of a
concrete machine."

the bytecodes that make up the instruction set = makinkode

Enhver CPU har et sæt Op-kodes. Den kode der afvikles skal bestå af
disse koder. Det er den aktuelle CPU's makinkode.
At OP-koderne i dette tilfælde er tilpasset noget andet, ændrer ikke på
at det er CPU'ens maskinkode.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 22-08-2011 00:00, Birger Sørensen skrev:
> Allan formulerede Sunday:
>> <snip>
>>> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
>>> afvikle nogen som helst anden form for kode end makinkode,
>>
>> Så er der en artikel her, der sikkert vil interessere dig:
>> http://en.wikipedia.org/wiki/Java_processor
>>
>> Hilsen
>> Allan
>
> "A Java processor is the implementation of the Java Virtual Machine
> (JVM) in hardware. In other words the bytecodes that make up the
> instruction set of the abstract machine become the instruction set of a
> concrete machine."
>
> the bytecodes that make up the instruction set = makinkode
>
> Enhver CPU har et sæt Op-kodes. Den kode der afvikles skal bestå af
> disse koder. Det er den aktuelle CPU's makinkode.
> At OP-koderne i dette tilfælde er tilpasset noget andet, ændrer ikke på
> at det er CPU'ens maskinkode.

Præcis!
Men set fra JVM'en så er det ikke maskinkode, så er det fortolket kode.

Ergo: Den samme kode kan *både* være maskinkode (for CPU'en) og
fortolket kode (for JVM'en).

(Iøvrigt har mange moderne CPU'er en mikrokode i CPU'en, der i
virkeligheden fortolker maskinkoden)

Hilsen
Allan

---

Allan har bragt dette til verden:
> Den 22-08-2011 00:00, Birger Sørensen skrev:
>> Allan formulerede Sunday:
>>> <snip>
>>>> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
>>>> afvikle nogen som helst anden form for kode end makinkode,
>>>
>>> Så er der en artikel her, der sikkert vil interessere dig:
>>> http://en.wikipedia.org/wiki/Java_processor
>>>
>>> Hilsen
>>> Allan
>>
>> "A Java processor is the implementation of the Java Virtual Machine
>> (JVM) in hardware. In other words the bytecodes that make up the
>> instruction set of the abstract machine become the instruction set of a
>> concrete machine."
>>
>> the bytecodes that make up the instruction set = makinkode
>>
>> Enhver CPU har et sæt Op-kodes. Den kode der afvikles skal bestå af
>> disse koder. Det er den aktuelle CPU's makinkode.
>> At OP-koderne i dette tilfælde er tilpasset noget andet, ændrer ikke på
>> at det er CPU'ens maskinkode.
>
> Præcis!
> Men set fra JVM'en så er det ikke maskinkode, så er det fortolket kode.
>
> Ergo: Den samme kode kan *både* være maskinkode (for CPU'en) og fortolket
> kode (for JVM'en).
>
> (Iøvrigt har mange moderne CPU'er en mikrokode i CPU'en, der i virkeligheden
> fortolker maskinkoden)
>
> Hilsen
> Allan

Det CPU'en afvikler, er maskinkode. Hvordan man når frem til
maskinkoden, er CPU'en ganske ligeglad med. Den kan ikke afvikle andet
end maskinkode.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Allan har bragt dette til verden:
>> (Iøvrigt har mange moderne CPU'er en mikrokode i CPU'en, der i
>> virkeligheden fortolker maskinkoden)
>
> Det CPU'en afvikler, er maskinkode. Hvordan man når frem til
> maskinkoden, er CPU'en ganske ligeglad med. Den kan ikke afvikle andet
> end maskinkode.

Vi er nok ude i insekterotikken, hvor spørgsmålet nok nærmere er: "Hvad er
en CPU"?

Nu skriver Allan "moderne CPU'er" men for 25+ år siden havde vores 'kværn'
64KB mikrokode indbygget i 'CPU-en', derudover havde den 2 ALU'er, som var
samlet i een 'CPU'.

Da mikrokoden var programmerbar, gav det så en anderledes boot-sekvens.

Pre-boot: Loading af mikrokode vha en Zilog (Z80) 'CPU'.
Boot: Boot som vi kender det, dog havde vi Cold-,Cool- og Warm- start.

Men tiden går i ring, for dengang var det (CISC) for langsomt, og man (HP)
gik over til RISC i stedet.

--
Med venlig hilsen
Stig Johansen

---

On 20-08-2011 21:58, Allan wrote:

> Det er dog er forfærdelig gang vrøvl!

Gad vist om det er udtalelser som ovenstående, der er med til at afholde
folk fra at bruge disse grupper?

Er det nødvendigt at kategorisere noget som "vrøvl"?

Kunne du ikke bare sige at du er uenig?

Karl Erik.

--
http://dmwebdesign.dk - DM i Webdesign
http://twitter.com/kechriste
http://webdesign.ranunkelvej.com - Artikler om webdesign

---

Karl Erik Christensen wrote:

> Er det nødvendigt at kategorisere noget som "vrøvl"?
>
> Kunne du ikke bare sige at du er uenig?

Det er en helt almindelig udtryksform. Det betyder "jeg er uenig med
dig".

--
Venlig hilsen/Best regards
Erik Olsen

---

On 20-08-2011 22:59, Erik Olsen wrote:
> Karl Erik Christensen wrote:
>
>> Er det nødvendigt at kategorisere noget som "vrøvl"?
>>
>> Kunne du ikke bare sige at du er uenig?
>
> Det er en helt almindelig udtryksform. Det betyder "jeg er uenig med dig".
>

Sådan noget vrøvl

Nej, jeg synes ikke det er almindeligt. På mig ville det virke
fornærmende hvis nogen siger jeg vrøvler.

Man kan sige noget i ubetænksomhed - det gør jeg ofte

Karl Erik.

--
http://dmwebdesign.dk - DM i Webdesign
http://twitter.com/kechriste
http://webdesign.ranunkelvej.com - Artikler om webdesign

---

Karl Erik Christensen wrote:

> Sådan noget vrøvl

Der kan du bare se.

> Nej, jeg synes ikke det er almindeligt. På mig ville det virke
> fornærmende hvis nogen siger jeg vrøvler.

Øh, nå. Det gør du vist undertiden, eller måske er det blot et indtryk
jeg har.

> Man kan sige noget i ubetænksomhed - det gør jeg ofte

Det gør vi vel alle, ligesom vi alle undertiden skriver noget vrøvl.

--
Venlig hilsen/Best regards
Erik Olsen

---

> Er det nødvendigt at kategorisere noget som "vrøvl"?
>
> Kunne du ikke bare sige at du er uenig?

Jo, det kunne jeg godt, men jeg synes, at man skal kalde en spade for en
spade.

Hvis jeg siger noget forfærdelig vrøvl, så håber jeg sandelig også, at
du fortæller mig det og ikke bare siger, at du er "uenig".

Hilsen
Allan

---

On 21-08-2011 12:07, Allan wrote:
>
>> Er det nødvendigt at kategorisere noget som "vrøvl"?
>>
>> Kunne du ikke bare sige at du er uenig?
>
> Jo, det kunne jeg godt, men jeg synes, at man skal kalde en spade for en
> spade.
>
> Hvis jeg siger noget forfærdelig vrøvl, så håber jeg sandelig også, at
> du fortæller mig det og ikke bare siger, at du er "uenig".
>
> Hilsen
> Allan
>

Nu er det jo ikke nødvendigvis din mening jorden roter om.

Karl Erik.

--
http://dmwebdesign.dk - DM i Webdesign
http://twitter.com/kechriste
http://webdesign.ranunkelvej.com - Artikler om webdesign

---

Den 21-08-2011 13:43, Karl Erik Christensen skrev:
> On 21-08-2011 12:07, Allan wrote:
>>
>>> Er det nødvendigt at kategorisere noget som "vrøvl"?
>>>
>>> Kunne du ikke bare sige at du er uenig?
>>
>> Jo, det kunne jeg godt, men jeg synes, at man skal kalde en spade for en
>> spade.
>>
>> Hvis jeg siger noget forfærdelig vrøvl, så håber jeg sandelig også, at
>> du fortæller mig det og ikke bare siger, at du er "uenig".
>>
>> Hilsen
>> Allan
>>
>
> Nu er det jo ikke nødvendigvis din mening jorden roter om.
>
Derom er vi 100% enige.

Hilsen
Allan

---

Den 21/08/11 12.07, Allan skrev:
>
>> Er det nødvendigt at kategorisere noget som "vrøvl"?
>>
>> Kunne du ikke bare sige at du er uenig?
>
> Jo, det kunne jeg godt, men jeg synes, at man skal kalde en spade for en
> spade.

"Den, som kun kan kalde en spade for en spade, burde udstyres med en".
- Oscar Wilde (1854-1900)
--
Venlig hilsen
Kurt Hansen

---

Den 21-08-2011 14:07, Kurt Hansen skrev:
> Den 21/08/11 12.07, Allan skrev:
>>
>>> Er det nødvendigt at kategorisere noget som "vrøvl"?
>>>
>>> Kunne du ikke bare sige at du er uenig?
>>
>> Jo, det kunne jeg godt, men jeg synes, at man skal kalde en spade for en
>> spade.
>
> "Den, som kun kan kalde en spade for en spade, burde udstyres med en".
> - Oscar Wilde (1854-1900)

Ja, spøjs fyr. Læs mere om ham her:
http://da.wikipedia.org/wiki/Oscar_Wilde

Hilsen
Allan

---

Allan har bragt dette til os:
>> Er det nødvendigt at kategorisere noget som "vrøvl"?
>>
>> Kunne du ikke bare sige at du er uenig?
>
> Jo, det kunne jeg godt, men jeg synes, at man skal kalde en spade for en
> spade.
>
> Hvis jeg siger noget forfærdelig vrøvl, så håber jeg sandelig også, at du
> fortæller mig det og ikke bare siger, at du er "uenig".
>
> Hilsen
> Allan

Når du kommer med konkrete udtalelser, som hardware der kan afvikle
ikke færdigkompileret kode, og sidestiller HW med virtuelle maskiner,
så er det noget vrøvl.

At have en mening om hvorvidt et givet projekt, bliver brugbart før
eller efter et andet, kan ikke være vrøvl. En mening kan udtrykkes mere
eller mindre forståeligt for andre - men den kan ikke være vrøvl.

Når du siger, at en andens mening er noget vrøvl, opfattes du som
uartig (for nu at bruge et gammeldags udtryk) eller bedrevidende,
irettesættende.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> At have en mening om hvorvidt et givet projekt, bliver brugbart før
> eller efter et andet, kan ikke være vrøvl. En mening kan udtrykkes
> mere eller mindre forståeligt for andre - men den kan ikke være vrøvl.

Jeg oplever af og til at brugere kan udtrykke sig uforståeligt i en
sådan grad at det som kommer ud af det kun kan karakteriseres som vrøvl.
Nogle gange kan man spørge til detaljer i et sådant udsagn, men det
bliver ofte opfattet på samme måde som havde man skrevet "vrøvl".

> Når du siger, at en andens mening er noget vrøvl, opfattes du som
> uartig (for nu at bruge et gammeldags udtryk) eller bedrevidende,
> irettesættende.

Der gives tilfælde hvor "vrøvl" hverken er uartigt, bedrevidende eller
irettesættende, men en præcis karakterisering.

--
Venlig hilsen/Best regards
Erik Olsen

---

Erik Olsen forklarede:
> Birger Sørensen wrote:
>
>> At have en mening om hvorvidt et givet projekt, bliver brugbart før
>> eller efter et andet, kan ikke være vrøvl. En mening kan udtrykkes
>> mere eller mindre forståeligt for andre - men den kan ikke være vrøvl.
>
> Jeg oplever af og til at brugere kan udtrykke sig uforståeligt i en sådan
> grad at det som kommer ud af det kun kan karakteriseres som vrøvl. Nogle
> gange kan man spørge til detaljer i et sådant udsagn, men det bliver ofte
> opfattet på samme måde som havde man skrevet "vrøvl".

^^
Det skal jeg da ikke modsige.
Jeg vil dog måske nok mene, at i de fleste tilfælde kan man finde en
mening, ved at se bort fra de anvendte ord.

>> Når du siger, at en andens mening er noget vrøvl, opfattes du som
>> uartig (for nu at bruge et gammeldags udtryk) eller bedrevidende,
>> irettesættende.
>
> Der gives tilfælde hvor "vrøvl" hverken er uartigt, bedrevidende eller
> irettesættende, men en præcis karakterisering.

Også her kan jeg være enig.
Bare ikke i det aktuelle tilfælde, hvor det uagtet at der sættes
lighedstegn mellem maskin-kode og mellemniveau sprog, klart er tale om
at det det handler om er at Kurt Hansen mener at det nye Native Client
fra Google vil overhale HTML5 indenom.
Det udbasunerer Allan som "vrøvl".
Og det finder jeg "uartigt" - og faktisk en hel del useriøst, eftersom
han selv forsætter med noget der i mine øjne *er* endnu mere vrøvl end
Kurt Hansens udsagn.

Man kan ikke tillade sig at kalde andres meninger/holdninger for vrøvl.
Man kan være enig eller uenig, eller ikke have en mening selv.
vrøvl og (u)enighed er ord der bruges om forskellige ting.

Måske er jeg fra en tid, hvor ordene havde en anden betydning.
Men det forhindrer mig ikke i at mene at man godt kan tale ordentligt
til hinanden, selv når man er ueninge.

Birger


--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Det skal jeg da ikke modsige.
> Jeg vil dog måske nok mene, at i de fleste tilfælde kan man finde en
> mening, ved at se bort fra de anvendte ord.

En mening, ja, men er det den rigtige mening? Det kræver ofte at man
spørger til detaljer i et udsagn.

> Også her kan jeg være enig.
> Bare ikke i det aktuelle tilfælde, hvor det uagtet at der sættes
> lighedstegn mellem maskin-kode og mellemniveau sprog, klart er tale om
> at det det handler om er at Kurt Hansen mener at det nye Native Client
> fra Google vil overhale HTML5 indenom.
> Det udbasunerer Allan som "vrøvl".
> Og det finder jeg "uartigt" - og faktisk en hel del useriøst, eftersom
> han selv forsætter med noget der i mine øjne *er* endnu mere vrøvl end
> Kurt Hansens udsagn.
>
> Man kan ikke tillade sig at kalde andres meninger/holdninger for
> vrøvl. Man kan være enig eller uenig, eller ikke have en mening selv.
> vrøvl og (u)enighed er ord der bruges om forskellige ting.

Jeg ved ikke tilstrækkeligt om det konkrete indhold i debatten til at
have en mening om det. Sådan lidt underfundigt udtrykt har flere af
udsagnene et indhold som jeg kunne karakterisere som vrøvl fordi jeg
ikke forstår det. Det behøver ikke udelukkende være min fejl hvis det
forholder sig sådan.

Jeg tror du bør erkende at ordet "vrøvl" ikke behøver at implicere noget
man skal tage så alvorligt som du lægger op til.

--
Venlig hilsen/Best regards
Erik Olsen

---

Erik Olsen forklarede den 8/21/2011:
8X
> Jeg tror du bør erkende at ordet "vrøvl" ikke behøver at implicere noget man
> skal tage så alvorligt som du lægger op til.

Nej. Når Kurt Hansen fortæller os at han har en mening (formentlig i
den hensigt at høre andres mening, evt. skabe debat om emnet - eller
måske bare for at gøre os opmærksomme på det), er der ingen der kan
tillade sig at karakterisere den som vrøvl.

Det er da klart at tingene skal ses i sammenhæng.
Og det skal man måske gøre, inden man karakteriserer andres meninger
som vrøvl.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Det er da klart at tingene skal ses i sammenhæng.

Netop, og det glemmer du fuldstændigt når du ser ordet "vrøvl".

--
Venlig hilsen/Best regards
Erik Olsen

---

Erik Olsen udtrykte præcist:
> Birger Sørensen wrote:
>
>> Det er da klart at tingene skal ses i sammenhæng.
>
> Netop, og det glemmer du fuldstændigt når du ser ordet "vrøvl".

Nej.
Men det gør den der skriver at Kurt Hansens menng er vrøvl...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:
> Nej.
> Men det gør den der skriver at Kurt Hansens menng er vrøvl...

Nu vrøvler du.

--
Venlig hilsen/Best regards
Erik Olsen

---

> Bare ikke i det aktuelle tilfælde, hvor det uagtet at der sættes
> lighedstegn mellem maskin-kode og mellemniveau sprog, klart er tale om
> at det det handler om er at Kurt Hansen mener at det nye Native Client
> fra Google vil overhale HTML5 indenom.
> Det udbasunerer Allan som "vrøvl".

Jeg har ingen mening om hvorvidt det nye Native Client fra Google vil
overhale HTML5 indenom eller ej. Det har jeg ingen forudsætninger for at
udtale mig om.

Det, jeg konstaterede var vrøvl, var udsagnet om, at C/C++ er
maskinkode. Nu har jeg skrevet flere oversættere, herunder også en
C-oversætter, så lige præcis den del ved jeg noget om.

> Og det finder jeg "uartigt" - og faktisk en hel del useriøst, eftersom
> han selv forsætter med noget der i mine øjne *er* endnu mere vrøvl end
> Kurt Hansens udsagn.
>
> Man kan ikke tillade sig at kalde andres meninger/holdninger for vrøvl.
> Man kan være enig eller uenig, eller ikke have en mening selv.
> vrøvl og (u)enighed er ord der bruges om forskellige ting.
>
> Måske er jeg fra en tid, hvor ordene havde en anden betydning.
> Men det forhindrer mig ikke i at mene at man godt kan tale ordentligt
> til hinanden, selv når man er ueninge.

Man kan ikke have en mening om, hvorvidt C/C++ er maskinkode eller ej -
ligesom man ikke kan have en mening om, hvorvidt 1+1=2 eller ej.

Hvis nogen mener(!), at 1+1=3 (eller at C/C++ er maskinkode), så vil jeg
til enhver tid påstå, at de vrøvler. Det kan godt være, at du finder
denne karakteriseringen uartigt; det skal du selvfølgelig have lov til.

Hilsen
Allan

---

Allan har bragt dette til os:
>> Bare ikke i det aktuelle tilfælde, hvor det uagtet at der sættes
>> lighedstegn mellem maskin-kode og mellemniveau sprog, klart er tale om
>> at det det handler om er at Kurt Hansen mener at det nye Native Client
>> fra Google vil overhale HTML5 indenom.
>> Det udbasunerer Allan som "vrøvl".
>
> Jeg har ingen mening om hvorvidt det nye Native Client fra Google vil
> overhale HTML5 indenom eller ej. Det har jeg ingen forudsætninger for at
> udtale mig om.

Det var det, indlægget handlede om.
Hvis du ikke har en mening eller viden om det selv, hvordan kan du så
skrive at Kurts mening er noget vrøvl?

> Det, jeg konstaterede var vrøvl, var udsagnet om, at C/C++ er maskinkode. Nu
> har jeg skrevet flere oversættere, herunder også en C-oversætter, så lige
> præcis den del ved jeg noget om.

Det var *ikke* det indlægget handlede om, og er i sammenhængen ganske
underordnet.

Du har kommenteret det sidste komma i den sidste sætning, og antaget at
det var indholdet.
Eller set en fejl, og glemt hvad det egentlig handler om.

Native Client, er et embedded element til Chrome, som kan afvikle
maskinkode der er compileret fra C eller C++ af en speciel Native
Client SDK.
Det er måske ikke udtrykt så klart af Kurt. Men hvis man ellers gider
forsøge på at finde ud af hvad det handler om, inden man beskylder
manden for at vrøvle, er det faktisk meget klart.

I øvrigt har flere andre allerede påtalt at C/C++ ikke er maskinkode -
i meget pænere vendinger, end dem du bruger.

Deraf må vi konkludere, at du ikke alene ikke læser de indlæg du svarer
på - du læser heller ikke de øvrige svar.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

>> Jeg har ingen mening om hvorvidt det nye Native Client fra Google vil
>> overhale HTML5 indenom eller ej. Det har jeg ingen forudsætninger for
>> at udtale mig om.
>
> Det var det, indlægget handlede om.
> Hvis du ikke har en mening eller viden om det selv, hvordan kan du så
> skrive at Kurts mening er noget vrøvl?

Prøv venligst at læse min oprindelige kommentar igen.
Min kommentar angående vrøvl handler udelukkende om sammenligningen af
C/C++ og maskinkode.

>> Det, jeg konstaterede var vrøvl, var udsagnet om, at C/C++ er
>> maskinkode. Nu har jeg skrevet flere oversættere, herunder også en
>> C-oversætter, så lige præcis den del ved jeg noget om.
>
> Det var *ikke* det indlægget handlede om

Jeg er fuldt klar over, at det ikke var hovedpointen i hans indlæg.

, og er i sammenhængen ganske
> underordnet.

Nej, det blev brugt som et eksempel.

>
> Du har kommenteret det sidste komma i den sidste sætning,

Som var omkring en fjerdedel af indlægget, ja.

> og antaget at det var indholdet.

Nej!

> Eller set en fejl,

Ja!

> og glemt hvad det egentlig handler om.

Nej!

> Native Client, er et embedded element til Chrome, som kan afvikle
> maskinkode der er compileret fra C eller C++ af en speciel Native Client
> SDK.
> Det er måske ikke udtrykt så klart af Kurt. Men hvis man ellers gider
> forsøge på at finde ud af hvad det handler om, inden man beskylder
> manden for at vrøvle, er det faktisk meget klart.
>
> I øvrigt har flere andre allerede påtalt at C/C++ ikke er maskinkode - i
> meget pænere vendinger, end dem du bruger.
>
> Deraf må vi konkludere, at du ikke alene ikke læser de indlæg du svarer
> på

Forkert konklussion.

- du læser heller ikke de øvrige svar.

Ja, jeg er nogle gange lidt hurtig.

Hilsen
Allan

---

On 21 Aug., 21:27, Kurt Hansen <k...@ugyldig.invalid> wrote:

> Hvis jeg i fremtiden skulle lave en hjemmeside om f.eks. slægtsforskning
> (og hvis jeg havde evnerne til det), ville der ikke være ret mange
> HTML-koder. Jeg vil simpelthen afvikle et interaktivt program i
> brugerens browser. Der er uanede muligheder.

Ja - og min og vidst også Birgers indvendinger/overvejelser er så, at
flere muligheder for webmasteren også giver flere muligheder for
udnyttelse af sårbarheder (bl.a. fordi disse programmer vil få samme
rettigheder som operativsystemet).

Jeg er helt på det rene med, og langt henad vejen også ivrig fortaler
for - teknologisk udvikling, som kan få tingene til at skride
hurtigere, for intet var værre end da MS havde monopol og alting stod
stille. Men eftersom det her også kan påvirke sikkerheden, så skal man
måske lige stå et skridt tilbage og så tænke sig om først. Sikkerhed
skal netop ikke paces igennem, hvilket man har set af JAVA, Flash og
ActiveX.

Idéen er interessant nok hvis det sikkerhedsmæssigt kan forsvares,
bliver spændende at se, hvad sikkerhedsfolk mener om det... men jeg
tænker nok, at det tiltag i overskuelig fremtid vil få størst
betydning, hvis man bruger GoogleOS, ikke så meget Chrome browseren.
De andre browsere skal jo være med på idéen, før det kan blive til en
standard.


MVH
Rune Jensen

---

On 23 Aug., 00:19, Stig Johansen <wopr...@gmail.com> wrote:

> Mon ikke tiltaget er møntet på mobile devices?

Et udmærket bud. Under alle omstændigheder har Google vel taget som
udgangspunkt, at ikke alle (Microsoft i hvert fald pga. ActiveX-
erfaringer) vil være med, så de må have en begrundelse mere for det
end bare desktop browseren.

Idfb. og OT er jeg lidt ærgerlig over, at Google - tilsyneladende(?) -
tager lidt lettere på sikkerheden på Android end på Googles browser/
OS. Jeg synes virkelig de satte helt nye standarder på sikkerheden med
Chrome.


MVH
Rune Jensen

---

On 23 Aug., 23:52, Birger Sørensen <s...@bbsorensen.com> wrote:
> Allan har bragt dette til verden:
>
>
>
>
>
> > Den 22-08-2011 00:00, Birger Sørensen skrev:
> >> Allan formulerede Sunday:
> >>> <snip>
> >>>> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
> >>>> afvikle nogen som helst anden form for kode end makinkode,
>
> >>> Så er der en artikel her, der sikkert vil interessere dig:
> >>>http://en.wikipedia.org/wiki/Java_processor
>
> >>> Hilsen
> >>> Allan
>
> >> "A Java processor is the implementation of the Java Virtual Machine
> >> (JVM) in hardware. In other words the bytecodes that make up the
> >> instruction set of the abstract machine become the instruction set of a
> >> concrete machine."
>
> >> the bytecodes that make up the instruction set = makinkode
>
> >> Enhver CPU har et sæt Op-kodes. Den kode der afvikles skal bestå af
> >> disse koder. Det er den aktuelle CPU's makinkode.
> >> At OP-koderne i dette tilfælde er tilpasset noget andet, ændrer ikke på
> >> at det er CPU'ens maskinkode.
>
> > Præcis!
> > Men set fra JVM'en så er det ikke maskinkode, så er det fortolket kode.
>
> > Ergo: Den samme kode kan *både* være maskinkode (for CPU'en) og fortolket
> > kode (for JVM'en).
>
> > (Iøvrigt har mange moderne CPU'er en mikrokode i CPU'en, der i virkeligheden
> > fortolker maskinkoden)
>
> > Hilsen
> > Allan
>
> Det CPU'en afvikler, er maskinkode. Hvordan man når frem til
> maskinkoden, er CPU'en ganske ligeglad med. Den kan ikke afvikle andet
> end maskinkode.

Hvis man overhovedet skal diskutere det med hasitghed, er man nødt til
at blive enige om, hvorfor noget maskinkode afvikles langsommere end
andet.

Et JS-framework er stadig JS er stadig maskinkode, men fame nogle
omveje det skal (hver maskinkodedel skal udføre mere arbejde), og
derfor det er langsommere end direkte HEX-editering.

Sidder man i en HEX-editor, laver man direkte maskinkode, f.eks.: LDA
0 STA 033 180 RTS, som kan oversættes direkte til tal som
169,0,141,33,180,96 (6502 maskinokde er det eneste jeg kender) og
dette kan ikke optimeres mere, det er som at snakke spansk til en
spanier, uden man behøver putte det igennem Google Translate først -
det gør man trods alt ikke med hverken scripting eller JS, hvor
tingene oversættes, fordi menneskesprog != maskinsprog. Det er alt det
ekstra arbejde med oversættelse som kræver hastighed, og derfor at
noget kodesprog laver mere bloated (maskin)kode.



MVH
Rune Jensen

---

Rune Jensen skrev:

> Sidder man i en HEX-editor, laver man direkte maskinkode, f.eks.: LDA
> 0 STA 033 180 RTS,

Det hedder ikke maskinkode. Det hedder symbolsk maskinkode eller
bedre: assembler.

> som kan oversættes direkte til tal

Det er maskinkode.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Efter mange tanker skrev Rune Jensen:
> On 23 Aug., 23:52, Birger Sørensen <s...@bbsorensen.com> wrote:
>> Allan har bragt dette til verden:
>>
>>
>>
>>
>>
>>> Den 22-08-2011 00:00, Birger Sørensen skrev:
>>>> Allan formulerede Sunday:
>>>>> <snip>
>>>>>> For mig at se, er det ikke mere vrøvl end at påstå der findes HW der kan
>>>>>> afvikle nogen som helst anden form for kode end makinkode,
>>>>> Så er der en artikel her, der sikkert vil interessere dig:
>>>>> http://en.wikipedia.org/wiki/Java_processor
>>>>> Hilsen
>>>>> Allan
>>
>>>> "A Java processor is the implementation of the Java Virtual Machine
>>>> (JVM) in hardware. In other words the bytecodes that make up the
>>>> instruction set of the abstract machine become the instruction set of a
>>>> concrete machine."
>>
>>>> the bytecodes that make up the instruction set = makinkode
>>>> Enhver CPU har et sæt Op-kodes. Den kode der afvikles skal bestå af
>>>> disse koder. Det er den aktuelle CPU's makinkode.
>>>> At OP-koderne i dette tilfælde er tilpasset noget andet, ændrer ikke på
>>>> at det er CPU'ens maskinkode.
>>
>>> Præcis!
>>> Men set fra JVM'en så er det ikke maskinkode, så er det fortolket kode.
>>> Ergo: Den samme kode kan *både* være maskinkode (for CPU'en) og fortolket
>>> kode (for JVM'en).
>>
>>> (Iøvrigt har mange moderne CPU'er en mikrokode i CPU'en, der i
>>> virkeligheden fortolker maskinkoden)
>>
>>> Hilsen
>>> Allan
>>
>> Det CPU'en afvikler, er maskinkode. Hvordan man når frem til
>> maskinkoden, er CPU'en ganske ligeglad med. Den kan ikke afvikle andet
>> end maskinkode.
>
> Hvis man overhovedet skal diskutere det med hasitghed, er man nødt til
> at blive enige om, hvorfor noget maskinkode afvikles langsommere end
> andet.
>
> Et JS-framework er stadig JS er stadig maskinkode, men fame nogle
> omveje det skal (hver maskinkodedel skal udføre mere arbejde), og
> derfor det er langsommere end direkte HEX-editering.
>
> Sidder man i en HEX-editor, laver man direkte maskinkode, f.eks.: LDA
> 0 STA 033 180 RTS, som kan oversættes direkte til tal som
> 169,0,141,33,180,96 (6502 maskinokde er det eneste jeg kender) og
> dette kan ikke optimeres mere, det er som at snakke spansk til en
> spanier, uden man behøver putte det igennem Google Translate først -
> det gør man trods alt ikke med hverken scripting eller JS, hvor
> tingene oversættes, fordi menneskesprog != maskinsprog. Det er alt det
> ekstra arbejde med oversættelse som kræver hastighed, og derfor at
> noget kodesprog laver mere bloated (maskin)kode.
>
>
>
> MVH
> Rune Jensen

TIlføjer så lige til Bertels, at en god del af forskellen på
hastigheden, ligger i hvor god compiler/fortolker faktisk er til at
gennemskue, hvad der egentlig skal foregå.
Den samme opgave kan programmeres på mange måder - men det er ikke dem
alle der kører lige hurtigt, for det ikke ender med samme maskinkode -
selvom det er samme opgave der løses.

Scripting skal gennem en fortolker, hver gang et script køres.
Programmer der bliver kompileret, omsættes til maskinkod, som kan køres
direkte.
Det er her Googles nye plugin kan hente maskinkoden, i stedet for
script/sourcekode, og derfor kan afvikle hurtigere.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 24/08/11 17.37, Rune Jensen skrev:

> Hvis man overhovedet skal diskutere det med hasitghed, er man nødt til
> at blive enige om, hvorfor noget maskinkode afvikles langsommere end
> andet.

Hvad med et lægge 1-tallerne ned, så de kan smutten igennem 0-erne?
--
Venlig hilsen
Kurt Hansen

---

On 24 Aug., 10:19, Bertel Lund Hansen
<splitteminebrams...@lundhansen.dk> wrote:
> Rune Jensen skrev:
>
> > Sidder man i en HEX-editor, laver man direkte maskinkode, f.eks.: LDA
> > 0 STA 033 180 RTS,
>
> Det hedder ikke maskinkode. Det hedder symbolsk maskinkode eller
> bedre: assembler.
>
> > som kan oversættes direkte til tal
>
> Det er maskinkode.

Klart nok - men assembler bliver oversat 1:1 sådan at om du skriver
STA 0,180 eller 141,0,180 bliver det det samme. Forskellen ligger i
editoren, fordi hver opkode har en tilhørende decimal værdi som
direkte kan oversættes, f.eks. Store A absolute = 141 = STX). Jeg har
lavet masser af maskinkodeprogrammer alene ved manuelt at oversætte
opkoden og lægge de decimale værdier ind i på hinanden følgende
adresser og altså udenom HEX-editorer. Rent faktisk har jeg aldrig
brugt HEX-editor - det er for tøsedrenge (rigtige mænd kan huske alle
opkodes i decimal i hovedet) :)

Lad os sige, du i stedet laver et script i forståeligt BASIC-sprog. Så
vil den kode skulle igennem minimum 2 processer for at kunne lave det
endelige arbejde (som her er det samme som poke 0+180*256,0). Du kan
jo f.eks. lave en lille subrutine til det i BASIC og udbygge det
lidt.

2000 for I=0 to 255
2010 poke 1024+i,i
2020 Next I
2010 RETURN

Så¨vil det først skulle igennem BASIC-fortolkeren, den skal fortolke
"for", "poke" og "next" mv., den skal opbygge og indlægge variable
osv, før den endelige "poke" kan udføres, og ja det er maskinkode i
sidste ende, men ærkelangsomt i forhold til at skrive sys49152, og
derfra udføres det med ren maskinhastighed.

BASIC-programmet i ren assembler/maskinkode

#ADDR 49152
LDX 255 STX 0 4 DEX CPX BNC -7

eller (decimalt)

162,255,157,0,4,202,203,250,96

Her udføres maskinkode kun for det "bestilte" arbejde, og kan derfor
ikke optimeres mere, men assembler er også meget lidt forståeligt.
Hvis man tager BASIC-koden, så udføres der masser udenoms maskinkode
for at fortolke hver BASIC-linje, derfor er den herrelangsom, til
gengæld mere forståelig for mennesker.

Jeg ved ikke, hvor C++ ligger i forhold til, men alle script-sprog og
inkl. javascript er i princippet ærkelangsomme af samme grund som
BASIC-programmet er langsomt. Jo mere maskinnært kode man kan skrive,
des hurtigere vil man kunne få det udført. Hvis man på et tidspunkt
kan skrive og udføre ren assembler i browseren (a la 64'erens sys-
kommando) - så kan man ikke få højere hastighed.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Klart nok - men assembler bliver oversat 1:1 sådan at om du skriver
> STA 0,180 eller 141,0,180 bliver det det samme.

Korrekt, men det er alligevel bedst at kalde tingene ved deres
rette navn.

> Jeg har lavet masser af maskinkodeprogrammer alene ved manuelt
> at oversætte opkoden og lægge de decimale værdier ind i på
> hinanden følgende adresser og altså udenom HEX-editorer.

Og jeg har skrevet programmer direkte i hukommelsen med hexkoder.

> (rigtige mænd kan huske alle opkodes i decimal i hovedet) :)

Computere opererer binært, så naturligvis husker man opcodes på
hexform.

> Lad os sige, du i stedet laver et script i forståeligt BASIC-sprog.

Du behøver ikke forklare alle detaljerne for mig.

> Jeg ved ikke, hvor C++ ligger i forhold til,

C++ og C giver nok den hurtigste kode der kan laves med et
kompileret program. Jeg ved ikke hvorfor du nævner det sammen med
et scriptsprog.

Python er et ret stærkt sprog. Man regner med at det i snit kun
er 10 % langsommere end C som det er bygget på. Det er heftigt
for et scriptsprog, og dets syntaks og udbyggede moduler gør det
til et effektivt værktøj hvor man ikke skal sidde og bitpille.
Det er ikke tilfældigt at Google kræver grundigt kendskab til
Python som forudsætning for ansættelse.

Også firmaer der ikke laver slutprodukter i Python, bruger det i
udviklingsfasen fordi det er så hurtigt at arbejde med. Når
skidtet fungerer, bliver det så lagt om, formodentlig til C(++).

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:

> C++ og C giver nok den hurtigste kode der kan laves med et
> kompileret program. Jeg ved ikke hvorfor du nævner det sammen med
> et scriptsprog.

Næst efter Delphi

I snakker kun compiler, men glemmer optimizeren.

For et par år siden havde 'vi' en lille konkurrence (fastcoders), hvor
compiler/optimizer/linker rent faktisk genererede bedre kode en
assember-'fyrenes' håndkode.

Snakker vi overall performance, så er en god memorymanager kombineret med
referencecounting nogle af de ting, der gør Delphi hurtigere end f.eks. C.

--
Med venlig hilsen
Stig Johansen

---

On 26 Aug., 09:45, Stig Johansen <wopr...@gmail.com> wrote:
> Bertel Lund Hansen wrote:
> > C++ og C giver nok den hurtigste kode der kan laves med et
> > kompileret program. Jeg ved ikke hvorfor du nævner det sammen med
> > et scriptsprog.
>
> Næst efter Delphi
>
> I snakker kun compiler, men glemmer optimizeren.
>
> For et par år siden havde 'vi' en lille konkurrence (fastcoders), hvor
> compiler/optimizer/linker rent faktisk genererede bedre kode en
> assember-'fyrenes' håndkode.
>
> Snakker vi overall performance, så er en god memorymanager kombineret med
> referencecounting nogle af de ting, der gør Delphi hurtigere end f.eks. C.

Jeg kan godt se, hvordan det kan lade sig gøre. Det må være noget med,
at hvis man håndkoder maskinkode, er chancen for fejl stor, hvor et
lidt mere "maskin-fjernt" sprog har noget automatisk error-correction
indbygget, og måske iøvrigt også nemmere at få overblik over end
maskinkode.

Stadig - hvis man er en suveræn dygtig maskinkodekoder, så er det vel
stadig det som giver den hurtigste performance? At der så ikke er så
mange suverænt dygtige maskinkodekodere tilbage tror jeg godt på.
Håndkodning af maskinkode (eller bare HEX-editering) må ligge i
udbredelse på linje med hulkort-programmering i dag.

Eller snakker du om noget andet?


PS - The "Which programming language is the fastest comparison chart"
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=gpp

Sammenligner JavaScript og C++ på en Linux-bænk. Javascript er alt fra
2 til 150 gange langsommere alt efter formål. OG Javascript fylder ad
H til i hukommelsen - det er klart, der skal jo fortolkes en del i
forhold til C++
.... ved ikke med Delphi, kunne ikke finde den som valgmulighed.



MVH
Rune Jensen

---

Rune Jensen skrev:

> At der så ikke er så mange suverænt dygtige maskinkodekodere
> tilbage tror jeg godt på. Håndkodning af maskinkode (eller
> bare HEX-editering) må ligge i udbredelse på linje med
> hulkort-programmering i dag.

Jeg tror ikke at man nogensinde kan undvære maskinkodehajer. Jeg
har ladet mig fortælle at de oftest udførte, tidskritiske rutiner
i f.eks. spil er kodet i assembler.

Og hvordan skulle man dog kunne optimere en compiler hvis ingen
kendte maskinkoden til bunds?

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:

> Jeg tror ikke at man nogensinde kan undvære maskinkodehajer. Jeg
> har ladet mig fortælle at de oftest udførte, tidskritiske rutiner
> i f.eks. spil er kodet i assembler.

Lige præcis.
I førnævnte tilfælde var det noget så 'simpelt' som at finde min og max i et
array.

Spørgeren havde en applikation for disse funktioner var tidskritiske.

I forhold til de indbyggede funktioner opnåede han en performanceforbedring
på vistnok 10 gange.

Men så er vi derude hvor koden er specialdesignet til netop hans applikation
(og CPU).

Et andet eksempel er FastMM (Delphi's nuværende memorymanager), der er
kommet til i 'fastcoders' gruppen, hvor man gennem flere år har optimeret
memorymanageren.

Da det viste sig den performede _meget_ bedre end den indbyggede, blev det
en del af produktet.

> Og hvordan skulle man dog kunne optimere en compiler hvis ingen
> kendte maskinkoden til bunds?

Netop .

Og i forhold til Runes kommentar, så er CPU'erne *meget* mere udbygget end i
'hans tid'.

Der er et væld af registre osv. og alene den omtalte min/max funktion kan
skrives på mange måder.

Hvis man lader være med at bruge 'høkertricks'[1], så var min funktion
faktisk den hurtigste - SELVOM den var lavet i Pascal.

Derfor vores (Q's og min) overraskelse, for det viste sig at optimizeren var
langt bedre end vi havde troet.

[1] Der var en CPU-haj, der lavede en hurtigere rutine, men han baserede det
på kendskab til kode og lokationer, og fremprovokerede en prefetch fra
cachen, men så er man _virkelig_ bundet til den aktuelle HW.

--
Med venlig hilsen
Stig Johansen

---

On 29 Aug., 08:33, Stig Johansen <wopr...@gmail.com> wrote:

> Og i forhold til Runes kommentar, så er CPU'erne *meget* mere udbygget end i
> 'hans tid'.

Jojo, 6502 var en ren 8 bit, kunne adressere 65536 adresser, dvs. 16
bit (men ikke native, dvs. 16 bit sendt af to bytes). 2 tælle-registre
(X og Y), samt en akkumulator (A-register). Selvfølgelig er der sket
meget mere siden da - selv om det vel i virkeligheden mere er en
udbygning, end det er egentlige fornyelser. Som du skriver, er der
flere registre i nyere CPUer, fair nok, men metoderne lyder til at
være del samme. Det er jo stadig bygget på Bool, og man har bare
udvidet fra 8 bit til 64 bit.


PS og off-topic. Men tænk lidt over det - på C64'eren der styrede man
jo alt selv. Man lavede selv sin lyd-driver, og havde fuld kontrol
over grafikken (og skærmen!) helt ned på hardware-niveau. Kan man også
det med moderne PC'er?


MVH
Rune Jensen

---

Rune Jensen wrote:

> Selvfølgelig er der sket
> meget mere siden da - selv om det vel i virkeligheden mere er en
> udbygning, end det er egentlige fornyelser. Som du skriver, er der
> flere registre i nyere CPUer, fair nok, men metoderne lyder til at
> være del samme. Det er jo stadig bygget på Bool, og man har bare
> udvidet fra 8 bit til 64 bit.

Det vil føre alt alt for vidt at kigge på nuværende processorer.

Men i forhold til dit eksempel, så har CPU'er i mange år haft 128 bit
registre og operationer, selvom man definerer dem som 32-bit.

Så 128 bit's operationer har været 'wired' ind i CPU'erne i laang tid.

Snakker vi ASM optimering, så har nogle CPU'er mulighed for at 'flække' de
128 bit's op i 4*32-bits (single) floating points.

DVS. at man kan (ved at bruge single) udføre 4 *samtidige* operationer.

Det er alle disse finurligheder, der er indbygget i diverse optimizere -
eller sagt på en anden måde - 'vidensopsamling'.

--
Med venlig hilsen
Stig Johansen

---

On 30 Aug., 01:30, Stig Johansen <wopr...@gmail.com> wrote:

> Så 128 bit's operationer har været 'wired' ind i CPU'erne i laang tid..
>
> Snakker vi ASM optimering, så har nogle CPU'er mulighed for at 'flække' de
> 128 bit's op i 4*32-bits (single) floating points.

Det var nu også et historisk indspark. Jeg synes da det er imponerende
hvad man kan med 3 registre, hvor man iøvrigt kun kan manipulere på
bitniveau på det ene, og regningsmuligheder strækker sig til addition,
subtraction og ROR og ROL (nåhjah - og en overflow-flag). Prøv at
overveje hvordan man dividerer med 40 når man kun har disse
muligheder. 16kb godt og vel var hvad jeg brugte på at lave et space
invaders i ren MC, og SVJH omkring 4kb til Tetris.

Nogle gange, så vil begrænsninger faktisk give modsatte effekt af hvad
man tror, nemlig større kreativitet.

> DVS. at man kan (ved at bruge single) udføre 4 *samtidige* operationer.
>
> Det er alle disse finurligheder, der er indbygget i diverse optimizere -
> eller sagt på en anden måde - 'vidensopsamling'.

....joh - men jeg forsøgte faktisk at finde Delphi til Linux, det
eksisterer ikke, så jeg kan ikke rigtigt tjekke hastigheden selv :)


MVH
Rune Jensen

---

Rune Jensen wrote:

> Prøv at
> overveje hvordan man dividerer med 40 når man kun har disse
> muligheder. 16kb godt og vel var hvad jeg brugte på at lave et space
> invaders i ren MC, og SVJH omkring 4kb til Tetris.

'Os', der blev nødt til[1] at kode assembler mod BIOS på originale IBM/XT
*ved* hvad det drejer sig om

[1] Da det det 'DOS' ikke kunne bruges til bla. skærmhåndtering, seriel
kommunikation, og ikke havde multitasking.

> ...joh - men jeg forsøgte faktisk at finde Delphi til Linux, det
> eksisterer ikke, så jeg kan ikke rigtigt tjekke hastigheden selv :)

Det kommer lidt an på ;)

De lavede faktisk en Delphi til Linux (aka Kylix), som jeg selv har købt
V1,V2 samt V3 af.

Men 'man' forbinder Linux med gratis, så det blev droppet, for der var ingen
indtjening i det.

Nuværende status er:
Delphi (RAD tool) vil kun køre på WinX.
I stedet indfører man cross-compiling til andre platforme, og focus er på
Mac, samt crosscompiling til ARM processoren, så man også kan lave target
til mobile devices.

Det interessante er ikke så meget at lave en crosscompiler, men _genbrug_ af
de milliarder af kodelinier, der ligger hos millioner af udviklere.

Skype f.eks. er lavet i Delphi.

Desværre er det også pga. sin styrke blevet brugt til malware, hvilket
gjorde (på et tidspunkt), at samtlige Delphi applikationer blev flagget som
malware.

Hvis du havde læst alle disse indlæg om hvorfor h... _min_ applikation blev
flagget som 'bad' vil du kende omfanget

(Vi taler om professionelle applikationer til store virksomheder, der fik
'virusadvarsler' overnight som følge af en 'automagisk' opdatering).

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> 'Os', der blev nødt til[1] at kode assembler mod BIOS på originale IBM/XT
> *ved* hvad det drejer sig om

Det var da barnemad. CPU'en havde indbygget multiplikation og
division. Næ, os der har programmeret en 8080'er, vi ved hvad det
drejer sig om.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:

> Stig Johansen skrev:
>
>> 'Os', der blev nødt til[1] at kode assembler mod BIOS på originale IBM/XT
>> *ved* hvad det drejer sig om
>
> Det var da barnemad. CPU'en havde indbygget multiplikation og
> division. Næ, os der har programmeret en 8080'er, vi ved hvad det
> drejer sig om.

In 'blær-mode' we are..

På IBM/XT var DOS ubrugeligt, så man måtte selv skrive sine 'skærmrutiner'.

Ja, squ også keyboard rutiner.

Det var selve oprindelsen til det man kalder 'IBM kompatibel', for man skrev
til hardwaren (monokrom skærm B000:0000 og CGA B800:0000 og
keyboardbufferen lå i 0040:0017 osv.

Man kunne ikke lave (læs sælge) et anstændigt program, der opførte sig som
en Telex maskine nå skærmen skulle opdateres.

Multitasking fandtes heller ikke, så måtte også lave nogle TSR[1]
programmer, og det er ikke for amatører[2];)

[1] Terminate Stay Resident

[2] Preservation af stack/registre

--
Med venlig hilsen
Stig Johansen