AspergerForum

Ett it-forum bör ha en programmeringstråd.
Öppen diskussion om programmeringsspråk och relaterat.
Det kan vara allt ifrån Design patterns till proof of concepts, exempel, problem, frågor, tankar, tips.
Tänkte ivarjefall ta steget och starta tråden..

GOD is REAL unless declared INTEGER.

implicit typing
DEVIL is also REAL unless declared INTEGER

A=[I..N][(a..z)|(A..Z)|(0..9)|_]* -> INTEGER
^A ->REAL

?

...

10 ?"HELLO WORLD!"
20 GOTO 10

Kod: Markera allt

HELLO WORLD!
HELLO WORLD!
HELLO WORLD!
HELLO WORLD!
HELLO WORLD!

10 ?"HELLO WORLD!",
20 GOTO 10

Kod: Markera allt

HELLO WORLD!            HELLO WORLD!            HELLO WORLD!
HELLO WORLD!            HELLO WORLD!            HELLO WORLD!
HELLO WORLD!            HELLO WORLD!            HELLO WORLD!
HELLO WORLD!            HELLO WORLD!            HELLO WORLD!

10 ?"HELLO WORLD!";
20 GOTO 10

Kod: Markera allt

HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!

10 prunt strunt


? SYNTAX ERROR IN 10
READY.

uniqueNr5: ja, det var FORTRAN jag tänkte på.

Jag har kikat på det bisarra språket Javascript de senaste veckorna. Det går att använda om man fokuserar på en delmängd av språket; mer specifikt lambdafunktioner och prototypbaserade objekt. Exekveringen börjar bli snabb tack vare konkurrensen mellan webbläsarna som Apple, Google och Microsoft investerar i; Chromes V8 kan exempelvis kompilera direkt till maskinkod. Det finns också mer systemorienterade miljöer som node.js för dem som inte vill begränsa sig till manipuleringar av dom/html i en webbläsare.

För övrigt har kommande standard av C++ stöd för lambdafunktioner; likväl verkar det komma till Java. En trevlig utveckling för oss som föredrar mer funktionell stil.

irqmac MACRO nr

msr_irq&nr:
push ds
push es
push fs
pushad
;
EnterInt
sti
;
mov ax,irq_sys_sel
mov es,ax
mov bx,OFFSET irq_arr + nr * SIZE irq_struc
mov eax,es:[bx].user_handler
or eax,eax
jz msr_irq_default_error&nr
;
mov ds,es:[bx].user_data
push cs
push OFFSET msr_irq_handle_done&nr
push es:[bx].user_handler
xor ax,ax
mov es,ax
retf

msr_irq_default_error&nr:
or es:bad_irqs, 1 SHL nr

msr_irq_handle_done&nr:
cli
xor eax,eax
mov ecx,MSR_APIC_EOI
wrmsr
LeaveInt
;
popad
pop fs
pop es
pop ds
iretd

mem_irq&nr:
push ds
push es
push fs
pushad
;
EnterInt
sti
;
mov ax,irq_sys_sel
mov es,ax
mov bx,OFFSET irq_arr + nr * SIZE irq_struc
mov eax,es:[bx].user_handler
or eax,eax
jz mem_irq_default_error&nr
;
mov ds,es:[bx].user_data
push cs
push OFFSET mem_irq_handle_done&nr
push es:[bx].user_handler
xor ax,ax
mov es,ax
retf

mem_irq_default_error&nr:
or es:bad_irqs, 1 SHL nr

mem_irq_handle_done&nr:
cli
;
mov ax,apic_mem_sel
mov ds,ax
xor eax,eax
mov ds:APIC_EOI,eax
LeaveInt
;
popad
pop fs
pop es
pop ds
iretd

ENDM

10 COME FROM 20
20 PRINT "HELLO"

COME FROM implementerades faktiskt i en och annan BASIC, gissningsvis förvärrade det spagetthi-programmeringen en del, men jag kan faktiskt tänka mig enstaka vettiga användningsområden:
* För att emulera return-delen av GOSUB/RETURN om ens BASIC inte har det.
* För att bättre implementera generell felhantering med ON ... GOTO, främst för utskrifter då.
* För att implementera ASSERT, något som jag inte sett i någon BASIC såvitt jag kan påminna mig.

Ja, det har gjorts implementeringar av COME FROM i många olika språk, även om det urpsrungligen bara var avsett som ett skämt. Det har också föreslagits att implementera DON'T i Fortran, som motsats till DO. Jag vet dock inte riktigt vilken semantik man tänkt sig där.

Kvasir skrev:Det har också föreslagits att implementera DON'T i Fortran, som motsats till DO. Jag vet dock inte riktigt vilken semantik man tänkt sig där.

DON'T MESS UP

Bästa kommandot någonsin är nog assemblerkoden NOP

ufo skrev:Bästa kommandot någonsin är nog assemblerkoden NOP

Kan finnas en del roliga odokumenterade instruktioner också. Motorola hade HCF (Halt and catch fire) på en del processorer. Den var inte så farlig som den låter dock, utan var en debuginstruktion som gjorde att processorn började "vifta" med signalerna på alla pinnar på något förutbestämt sätt. Tror de huvudsakligen körde räknare och lade ut på bussarna etc.

Jag mindes visst maskinkoden - 0x90, kontrollerat.

Trolsk skrev:Jag mindes visst maskinkoden - 0x90, kontrollerat.

T.o.m. operationskoden för nop har man numera använt hos Intel. 0xF3 och 0x90 i kombination betyder "pause" i Intel-världen och betyder att processorn exekverar en spinlock, och därför inte utför något vettigt i egentlig mening förrän något hänt i minnet.

Fast om man ska vara petig så betyder instruktionskoden 0x90 xchg ax,ax. Den har ingen effekt. 0xF3 är egentlig rep. Intel-koden för pause bli då egentligen: rep xchg ax,ax.

Intressant test!

Hur många kan komma på rätt svar (utan att faktiskt använda programmen)?

Den här siten, http://thedailywtf.com/Default.aspx, innehåller ofta roliga programmeringsexempel från verkligheten.

Lite tankeväckande artikel som driver med alla de där Dummies- och Teach Yourself in 21 Days-böckerna...

<a target="_blank" href="http://norvig.com/21-days.html">Teach Yourself Programming in Ten Years</a>

barracuber skrev:Lite tankeväckande artikel som driver med alla de där Dummies- och Teach Yourself in 21 Days-böckerna...

<a target="_blank" href="http://norvig.com/21-days.html">Teach Yourself Programming in Ten Years</a>

Jag har verkligen snöat in lite på en av de där idéerna som framförs i länken, och även påmånga andra ställen:

för att bli en "mästare" (va e de´?) så måste man lägga ned 10.000 timmar på ett område. Alltså drygt 2 år om man ägnar nästan all vaken tid till att lära sig Java, Python, reguljära uttryck...

Risken med ett uppehåll är för min del att jag hinner glömma något och får börja om. Jag har en väldigt vältummad "Mastering regular expressions" som är otroligt jobbig att ta sig igenom...

Miche skrev:

Kvasir skrev:Det har också föreslagits att implementera DON'T i Fortran, som motsats till DO. Jag vet dock inte riktigt vilken semantik man tänkt sig där.

DON'T MESS UP

Under en Cobol -kurs (länge sedan) så fastnade vi för en lösning med "IF NOT NOT-PRESSED-KEY ...".

Vi lyckades senare koda "fast" oss med denna fula lösning.

I Assembler -övning så hade vi även kod som skrev om annan, redan passerad kod så att den gick att anropa igen! Som ursäkt hade vi att koden var tvungen att rymmas inom 256 bytes.

Det är väl inte bara jag som tyckte att Motorola 68000 -arkitekturen var överlägsen Intel 80xx vad gällde assemblerprogrammeringen?

Jag lyckades aldrig riktigt begripa hur minnessegmenteringen fungerade på Intelprocessorerna. Motorola hade en mycket mer lättförståelig kontruktion vilket gjorde assemblerkoden mer logisk.

När jag nu förtiden läser om Intelprocessorer så känns det som att det sitter en dinosauriehjärna från slutet av 70-talet någonstans där inne, även i en Sandy Bridge -processor...

Eller gör man numera en total bypass av 808xx -assemblerteknik, och bara kör med en mer modern assemblerdialekt ?

National Semiconductor var snyggast rent designmässigt, men den verkar numera nästan helt bortglömd... Vi programmerade mot den på högskolan därför att designen var så ren och välgenomtänkt.

lar66 skrev:Det är väl inte bara jag som tyckte att Motorola 68000 -arkitekturen var överlägsen Intel 80xx vad gällde assemblerprogrammeringen?

Vet inte då jag inte programmerat Motorola.

lar66 skrev:Jag lyckades aldrig riktigt begripa hur minnessegmenteringen fungerade på Intelprocessorerna. Motorola hade en mycket mer lättförståelig kontruktion vilket gjorde assemblerkoden mer logisk.

Håller inte med. Intels 32-bitars arkitektur är den bästa som någonsin gjorts. Synd bara att såväl Intel själva (Itanium) som AMD (x86-64) skulle sabba alltsammans i 64-bitsvärlden.

lar66 skrev:När jag nu förtiden läser om Intelprocessorer så känns det som att det sitter en dinosauriehjärna från slutet av 70-talet någonstans där inne, även i en Sandy Bridge -processor...

Känns snarare som att moderna processorer är dinosaurierna, vilket i grunden är ett problem med C-kompilatorer som inte klarar av avancerad minneshantering. Detta gör att moderna operativsystem är dinosaurier ifrån 70-talet med högvis av buggar p.g.a. obefintliga skydd i processorn.