flat assembler
Message board for the users of flat assembler.

Index > Main > 256 bit SSE aka AVX

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
revolution wrote:
I've only briefly looked at it but looks like you define your own key schedule (or use the helper instruction if you want) and then do a 128bit encryption. That allows you to use any key size as defined in the spec, 256, 224, 192, 160 or 128. Seems quite flexible to me.
Ooooh, then it's no problem Smile - the 128-bit block size is AES standard. I hope you're right, revolution - that'd mean the stuff isn't handicapped.

revolution wrote:
The other thing to watch out for is whether it is really very much faster than an optimised software solution. I still remember the 80386 days when you could write faster single-precision floating point code with the CPU than could be done on the 80387.
True, true. But look at VIA C3/EPIA "Padlock" instruction set benchmarks... I hope intel achives at least the same efficiency.

bitRAKE wrote:
protection will be required until the design is more fault tolerant. For example, if there were 1024 cores then loosing one wouldn't be a problem - it could be restarted. Of course, protection would be needed at a higher level to ensure a large number of cores don't fail. I think of it like cells in the body - if any one cell dies there is no problem.
That's an interesting way to go - but that isn't enough to guard against malware. Doesn't really matter if you have 1023 cores still running, if your system is infected and sending out spam mails Smile
Post 07 Apr 2008, 22:56
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3044
Location: vpcmipstrm
bitRAKE
f0dder wrote:
that isn't enough to guard against malware. Doesn't really matter if you have 1023 cores still running, if your system is infected and sending out spam mails Smile
Presumably, the high level system would be able to shut down the spammer core - like a network can shutdown traffic from a offending terminal, or even reset the machine to a predefined state. I'm not suggesting it would be bullet proof, but that it wouldn't need to be. Compromised cores could be logged for diagnosis before being reset. Maybe, even have some kind of hinting logic to predict future senerios beforehand. Would certainly help trace the problem.

_________________
¯\(°_o)/¯ unlicense.org
Post 07 Apr 2008, 23:14
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
It's an interesting idea, and I'm sure there's a lot research going on about it. But it would need pretty different architecture than just 1024 x86 cores with some self-healing... like, making sure there's no way the malware could spread to additional cores. And we still have the problems of infected system files etc. - that requires re-thinking some OS concepts.

Trusted Computing could be used for some really nice things, too bad the main reason it's being implemented is for DRM restrictions Sad
Post 07 Apr 2008, 23:30
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
one very interresting data type would the analog signals.
make calculations on analog values ( very, very fast ) , use ADC and DAC to work with in digital x86 mechanism too. delta-sigma is a very good type of ADC, i made some prototypes in my early ages in electronics and t show some very interresting properties.

a sort of mix between analog and digital.

about malwares, i repeat, don't do malware, it is exactlly the same principle as bad mentality education. have the same destruction effects.

to kill and detect malwares, a good theory can be not to build antivir, but more build a good meta code; to control the multiple processes and provide some hardware and transparent process control, watch dog flow control is a good start. it can be of any type:
timer, semapkore, checkpoint, boss etc... but the problem is always here... malware coders ( more frustrated childrens or evil based dumbs) shall be stopped and if possible, we shall destroy their machines.

one evidence is that i made a sort of virus cause of anger, and some weeks later, i used it and it did what you know.

the only copy of this "malware?" is on this forum.

it is a simple disk eraser. i made it to verify the ability of the system to localise the sectors reliabily. putting a string on the sectors to tell it's number and then, verify it effectivelly works.


our mission as coders is to fight it, not ot expend it. exactlly as the mission of parents is to make a good education for their childrens.

if i knew benjamin trojan ( or any virus builder), instead to give him a job, i give him a pair of fists in the face. exactlly as i do for all evil personns who wants to make bad actions. Evil or Very Mad

create malwares, ok, it's a part of the knowledge for all coders, but only for tests and defence, and never for bad actions, as in real life about martial arts.

there are some laws, the lengendary 3 laws of the robotics. as code are robots without body, it shall respect them.
sounds like an utopia, but it is like that, remember that the future is ours and we shall create for a better world, not the opposite.
Post 07 Apr 2008, 23:59
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
Remy Vincent wrote:
HELLO revolution, what do you think of this kind of solutions?
- You buy a processor, then you set you're own OPCODES.
- For example, """JE rel8""" has an OPCODE of 0x74 right ?
- What if you buy you're own processor, setting the OPCODE for """JE rel8""" to 0x01,...
- Ans so on for each OPCODE ?

After having changed the OPCODES of each instructions, WHAT ABOUT running you're programs inside a VMWARE window, that is supposed to be SAFE!!

Would say it's stability, or Would say it's just chaos ???

I'm sorry, but i'm feel like i'm not concerned with things like """secure your kernel from errant code""" are you really ?
I think you a describing something similar to an FPGA. Basically is has been done, but the performance is not good because is it a generic system and can't be tuned to give really good results. Also, you still need a host system to run the VM, what processor would that use?

Indeed letting everyone choose their own opcodes would be complete chaos.
Post 08 Apr 2008, 00:34
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3044
Location: vpcmipstrm
bitRAKE
Too bad the stack machine idea didn't stay mainstream. There really isn't any need to have registers to hold data - they should all be memory pointers to stacks. Razz Either circular like the FPU (but larger than 8 values), or linear like (R|E)SP. 16 configurable stacks should be plenty.

_________________
¯\(°_o)/¯ unlicense.org
Post 08 Apr 2008, 09:17
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
bitRAKE wrote:
...Too bad the stack machine idea didn't stay mainstream. ...
Not as far as I am concerned. "Stack" architecture has been obsolete, in my opinion, for four decades already...I despise trying to debug a program on a "stack" based architecture....I am oriented to the opposite direction, everything spelled out, unequivocal, rather than SP - 221.....
revolution wrote:

Indeed letting everyone choose their own opcodes would be complete chaos.
Well, I agree, and would go a step further. The best design is one which ELIMINATES 90% of all instructions, hence, almost all opcodes would be eliminated as well...
I think it is very important to offer the user the opportuntity, NO, the obligation, to define many of the operations now performed by intel's architecture. I believe we need at most a dozen native cpu instructions, from which all of the others can be derived, as needed, in each application. What would be useful is a list of the absolute minimum necessary instructions for the cpu to possess.... any thoughts?
Smile
Post 09 Apr 2008, 17:50
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
tom tobias: if you want a machine just for browsing the web and writing emails, "getting rid of instructions" might be doable. But in the real world where we want to do image and sound processing, video compression, and all that - we need fancy stuff like SSE for the performance.
Post 09 Apr 2008, 18:01
View user's profile Send private message Visit poster's website Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
Tom,

It is also my intention to make my own more simple CPU.
Maybe we could join efforts.
Post 09 Apr 2008, 18:21
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
bogdanontanu, you that have writen solar os, and have a network dirver, can you lead me to the right datas or tutorials. i need to understand and write them in less than 1 month for the FEEBLE.

this would be the first step to the machine that tom wants still exist and is a old Pentium 100MHz with vesa compliant card like sis6215.

then, it would be very possible to have a dedicated machine to internet without any system else than a browser and a client/server.

me too i want to build my own simple µP, but i see it is endless as there is an existing X86 platform that is not so hard to use. but it needs a lot of experience, as building a µP need more experience, and not only in assembly or C. create a digital chip is not an easy task. you should consider a lot of physical laws.

the time you can make a simpler and as powerfull µP than x86 will be a waste of time that can be used to learn more about the existing.

but yes, making a new µP family is not a bad idea. they shall have the same opcodes as x86.
Wink


Last edited by edfed on 09 Apr 2008, 23:23; edited 1 time in total
Post 09 Apr 2008, 18:40
View user's profile Send private message Visit poster's website Reply with quote
sakeniwefu



Joined: 23 Mar 2008
Posts: 29
sakeniwefu
In the end, all opcodes turn into a handful of uops in current Intels and AMDs, don't they? If we could program in uops directly, performance wouldn't get any worse. Although I heard RISC cpus are a PITA for assembly programmers.
Post 09 Apr 2008, 21:00
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
sakeniwefu wrote:
In the end, all opcodes turn into a handful of uops in current Intels and AMDs, don't they? If we could program in uops directly, performance wouldn't get any worse.
The uop coding would expand the code size a great deal. It is a very expanded form of the instructions. Memory overhead would be large.
sakeniwefu wrote:
Although I heard RISC cpus are a PITA for assembly programmers.
I recommend you have a look at ARM. I don't find ARM to be a PITA. Indeed the opposite, a very rewarding experience. But compared to the PIC, that is also RISC and is definitely a PITA. It is not the RISC thing that makes it ugly, it is the resources (or lack of resources) available that determine whether a particular CPU will be a PITA to write assembly.
Post 10 Apr 2008, 00:13
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4242
Location: 2018
edfed
Quote:
It is not the RISC thing that makes it ugly, it is the resources (or lack of resources) available that determine whether a particular CPU will be a PITA to write assembly.

totaly true.
and as said the teacher who maked me discover assembly,
Quote:
if you want a big amount of memory, a fast and powerfull envirronment to program big electronic applications, don't use an embeded µC, but a PC.

PC and computer in general are the better way to have power in digital electronics.
Post 10 Apr 2008, 00:34
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
If you want a TV remote control that won't drain your batteries with a small amount of memory in a small electronic application don't use a PC, but an embeded µC.
Post 10 Apr 2008, 08:39
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Touring taught you about "The Minimal Machine", but is that optimal?
I sometimes love the NOT operator, while I still have the XOR. With boolean you can derive all ANDs from ORs etc., but the shortcuts make your code compact.

Same goes for ADD/SUB or MUL/DIV and Signed/Unsigned...
Post 13 Apr 2008, 09:41
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3044
Location: vpcmipstrm
bitRAKE
Does Intel perform simulations to better understand how new instructions will effect software? Or, is this sort of thing more a marketing decision? I find it difficult to believe the later has much influence on such an important decision, but I really don't know.

_________________
¯\(°_o)/¯ unlicense.org
Post 13 Apr 2008, 19:11
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
bitRAKE wrote:
Does Intel perform simulations to better understand how new instructions will effect software? Or, is this sort of thing more a marketing decision? I find it difficult to believe the later has much influence on such an important decision, but I really don't know.
I would imagine they do studies on what would be good instructions to include. I doubt they would spend millions developing them only to find people can't use them.
Post 14 Apr 2008, 01:03
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP
:0 Just watch, they're going to spend so much time on the new instructions that at the end of the process, someone's going to go "Hey, wasn't there supposed to be an add instruction in these tables?!"
Post 14 Apr 2008, 02:18
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
revolution wrote:
bitRAKE wrote:
Does Intel perform simulations to better understand how new instructions will effect software? Or, is this sort of thing more a marketing decision? I find it difficult to believe the later has much influence on such an important decision, but I really don't know.
I would imagine they do studies on what would be good instructions to include. I doubt they would spend millions developing them only to find people can't use them.

Good question. I always wondered why Intel keeps supporting NEVER documented SETALC instruction. There must be some good reason, but what is the reason?
Post 14 Apr 2008, 07:41
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
MazeGen wrote:
I always wondered why Intel keeps supporting NEVER documented SETALC instruction. There must be some good reason, but what is the reason?
This may be something we will never find out. Sad
Post 14 Apr 2008, 09:04
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.